Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS 10 Security White Paper [pdf]

apple.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: iOS 10 Security White Paper [pdf]

#11

Post by CalChris »

AsyncAwait wrote: post #9
CalChris wrote: post #5

Its previous edition was required reading for CS 161 at Berkeley. Would that it were required reading in Mountain View. http://www-inst.cs.berkeley.edu/~cs161/fa16/ (Yeah, it says optional on the syllabus but Weaver said required in lecture.)

Do they don't know/care about security, or is it simply the case that it is hard to have something like the secure enclave across all Android devices? Genuine question.

Yes, IMHO they know. Their Chrome security model was required reading in CS 261.

https://people.eecs.berkeley.edu/~raluca/cs261-f15/

But to me, they seem to be trying to find a moderate level of security with a profitable cost of goods. It doesn't seem that their heart is in it the way Apple's is with the Enclave. iOS is still breakable at the nation state level but well that's quite a high bar. Nation states are breakable at the nation state level.

Re: iOS 10 Security White Paper [pdf]

#12

Post by chatmasta »

zaytoun wrote: post #8

I really do respect Apple's attention to security and privacy, however I was a little disappointed when I came across an Apple ID leak from their login form [0] last week. They patched a fix a couple days after I reported it, but still haven't responded to my initial report. It's quite concerning given how easy this simple flaw could have been used for malicious purposes to potentially collect millions of Apple ID's.…

That looks like extremely irresponsible disclosure? Publishing to GitHub and then "edit: I contacted apple"

????

Re: iOS 10 Security White Paper [pdf]

#13

Post by izacus »

AsyncAwait wrote: post #9
CalChris wrote: post #5

Its previous edition was required reading for CS 161 at Berkeley. Would that it were required reading in Mountain View. http://www-inst.cs.berkeley.edu/~cs161/fa16/ (Yeah, it says optional on the syllabus but Weaver said required in lecture.)

Do they don't know/care about security, or is it simply the case that it is hard to have something like the secure enclave across all Android devices? Genuine question.

Mmm? Secure enclave is present on most Android devices and is mandatory since Android 6.0.

(It's just called something else.)

Historically Android has been lagging behind a bit from iOS devices when it comes to security, but Pixels and their software have a very similar security model and design (with some exceptions - less granularity with file-based encryption and some other mostly minor details).

Non Google devices however are usually significantly less secure - not so much due to Android design, as due to manufacturers deliberately disabling Android's security featuers (e.g. only Pixel actually uses dm-verity at this moment if I remember correctly), refusing to update them, building devices with bad trustzone drivers... etc.

If you keep to the 1st party (Google-branded) devices like in iOS world, you're mostly ok.

Re: iOS 10 Security White Paper [pdf]

#14

Post by SamReidHughes »

zaytoun wrote: post #8

I really do respect Apple's attention to security and privacy, however I was a little disappointed when I came across an Apple ID leak from their login form [0] last week. They patched a fix a couple days after I reported it, but still haven't responded to my initial report. It's quite concerning given how easy this simple flaw could have been used for malicious purposes to potentially collect millions of Apple ID's.…

A list of Apple ID's isn't exactly a big deal. I've got mine listed in my HN profile.

Re: iOS 10 Security White Paper [pdf]

#15

Post by eridius »

zaytoun wrote: post #8

I really do respect Apple's attention to security and privacy, however I was a little disappointed when I came across an Apple ID leak from their login form [0] last week. They patched a fix a couple days after I reported it, but still haven't responded to my initial report. It's quite concerning given how easy this simple flaw could have been used for malicious purposes to potentially collect millions of Apple ID's.…

And what exactly would you do with those Apple IDs? Just knowing the email address doesn't really get you very far.

Re: iOS 10 Security White Paper [pdf]

#16

Post by obstinate »

zaytoun wrote: post #8

I really do respect Apple's attention to security and privacy, however I was a little disappointed when I came across an Apple ID leak from their login form [0] last week. They patched a fix a couple days after I reported it, but still haven't responded to my initial report. It's quite concerning given how easy this simple flaw could have been used for malicious purposes to potentially collect millions of Apple ID's.…

Literally every company is going to have some non-zero number of security leaks. I don't think it's reasonable to be disappointed in an entire company because of a bug written by (likely) one engineer. God knows I've written my share, but none of my software is on routes easily accessible to the public. Unless it's part of a larger pattern, this reaction is going to lead to you being disappointed with 100% of producers of software, past, present, and future, which doesn't seem like a useful state.

Incidentally, in the list of IDs you published, are those real? If they are: that's BS that you are publishing real people's IDs, and I'm also surprised by the number of numeric qq.com accounts.

Re: iOS 10 Security White Paper [pdf]

#17

Post by [deleted] »

chatmasta wrote: post #12
zaytoun wrote: post #8

I really do respect Apple's attention to security and privacy, however I was a little disappointed when I came across an Apple ID leak from their login form [0] last week. They patched a fix a couple days after I reported it, but still haven't responded to my initial report. It's quite concerning given how easy this simple flaw could have been used for malicious purposes to potentially collect millions of Apple ID's.…

That looks like extremely irresponsible disclosure? Publishing to GitHub and then "edit: I contacted apple" ????

[deleted]

Re: iOS 10 Security White Paper [pdf]

#18

Post by CalChris »

izacus wrote: post #13
AsyncAwait wrote: post #9

Earlier quoted context omitted.

Do they don't know/care about security, or is it simply the case that it is hard to have something like the secure enclave across all Android devices? Genuine question.

Mmm? Secure enclave is present on most Android devices and is mandatory since Android 6.0. (It's just called something else.) Historically Android has been lagging behind a bit from iOS devices when it comes to security, but Pixels and their software have a very similar security model and design (with some exceptions - less granularity with file-based encryption and some other mostly minor details). Non Google device…

Yes, they're using the ARM Trusted Execution Environment rather than a separate Enclave chip with its separate OS (L4). Apple is an ARM architecture licensee, designing their own compatible chips. So the TEE would have been an available path (compatibility is still required, no?) but they instead went the extra yard with a separate Enclave chip. As their white paper details, they also go to insane levels with that chip and moreover with its communications rather than just trust the TEE within an ARM chip and call it a day.

Re: iOS 10 Security White Paper [pdf]

#20

Post by izacus »

CalChris wrote: post #18
izacus wrote: post #13

Earlier quoted context omitted.

Mmm? Secure enclave is present on most Android devices and is mandatory since Android 6.0. (It's just called something else.) Historically Android has been lagging behind a bit from iOS devices when it comes to security, but Pixels and their software have a very similar security model and design (with some exceptions - less granularity with file-based encryption and some other mostly minor details). Non Google device…

Yes, they're using the ARM Trusted Execution Environment rather than a separate Enclave chip with its separate OS (L4). Apple is an ARM architecture licensee, designing their own compatible chips. So the TEE would have been an available path (compatibility is still required, no?) but they instead went the extra yard with a separate Enclave chip. As their white paper details, they also go to insane levels with that ch…

Yes, indeed they went above and beyond - probably because they also need to defend not only against external threats, but against the user of the device himself to keep the walled garden intact.
Post reply on HN