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

41–50 of 99 posts

Re: iOS 10 Security White Paper [pdf]

#41

Post by bryanbuckley »

floatboth wrote: post #27

This is really cool: > Securely erasing saved keys is just as important as generating them. It’s especially challenging to do so on flash storage, where wear-leveling might mean multiple copies of data need to be erased. To address this issue, iOS devices include a feature dedicated to secure data erasure called Effaceable Storage. This feature accesses the underlying storage technology (for example, NAND) to directl…

It's cool but note that you would never be saving secrets in cleartext to disk.

Re: iOS 10 Security White Paper [pdf]

#42

Post by bryanbuckley »

FT_intern wrote: post #23
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.

I would guess that it is tougher to secure the OS when you don't own the hardware, although I don't know enough about this to comment

Agreed. Apple's vertical integration is really nice here. As an Android OEM it's tough to have to consider all the trade-offs between different HW vendors (best HW for battery/performance may not be so great for security or software support, etc) versus being a consumer of some internal group.

Re: iOS 10 Security White Paper [pdf]

#43

Post by Cyph0n »

bryanbuckley wrote: post #40
Cyph0n wrote: post #35

Earlier quoted context omitted.

More recent ARM chips (A9+) come bundled with ARM TrustZone[1]. In a nutshell, the processor has two (hardware) isolated execution environments each running a different OS and different software. By default, the secure environment of TrustZone runs an L4 kernel (edit: this is incorrect, see reply below). Could it be the case that Apple is leveraging TrustZone but with a customized L4 kernel? Or is it confirmed that t…

> By default, the secure environment of TrustZone runs an L4 kernel. By default no SW runs on HW. "Mobicore" (now called "Kinibi" from Trustonic) is based on L4.

I know that mate, no need to get snarky. What I meant is that it was bundled with the core by default, but thanks for the correction. I thought I read it somewhere, but judging by a quick search, it seems I'm mistaken.

Re: iOS 10 Security White Paper [pdf]

#44

Post by Cyph0n »

CalChris wrote: post #34
izacus wrote: post #20

Earlier quoted context omitted.

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.

Yes (dunno why all the downvotes) but Apple went even further than the walled garden would require. They could have easily left an Apple backdoor. But they encrypt the protocol going over wires to/from the Enclave. They go insanely far rather than sufficiently far. Yeah, nation state level attacks will still work, especially if they have the phone. But with Android it's not nation state level. It's corporate level an…

I felt that Apple's description of the initial key setup between the enclave and the main processor was hand-wavy at best.

I know of another similar implementation that's used by Microsemi for their FPGA-based secure boot process[1]. They claim to protect the initial AES key transmission using an "obfuscated" crypto library that is sent to the processor over SPI on boot[2]. Also, I wonder if Apple exchanges a nonce during the setup to prevent replay attacks?

[1]: https://www.microsemi.com/products/fpga-soc/security/secure-...

[2]: It's a C/C++ library called WhiteboxCRYPTO. There is a whitepaper (http://soc.microsemi.com/interact/default.aspx?p=E464), but AFAIK the gist of their argument is that the code and keys are sufficiently obfuscated to prevent reverse engineering (typical marketing-speak).

Re: iOS 10 Security White Paper [pdf]

#45

Post by bryanbuckley »

Cyph0n wrote: post #43
bryanbuckley wrote: post #40

Earlier quoted context omitted.

> By default, the secure environment of TrustZone runs an L4 kernel. By default no SW runs on HW. "Mobicore" (now called "Kinibi" from Trustonic) is based on L4.

I know that mate, no need to get snarky. What I meant is that it was bundled with the core by default, but thanks for the correction. I thought I read it somewhere, but judging by a quick search, it seems I'm mistaken.

Depends on the HW manufacturer and SKU on what is bundled or not.. Even ROM code can be different per SKU.

Re: iOS 10 Security White Paper [pdf]

#46

Post by Buge »

eridius wrote: post #15
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.

You could spam them.

Anyways, it's a privacy violation. Apple shouldn't be handing out your email without your permission. Facebook has a setting allowing you to choose whether you want your email to be public or not.

Re: iOS 10 Security White Paper [pdf]

#47

Post by CalChris »

Cyph0n wrote: post #44
CalChris wrote: post #34

Earlier quoted context omitted.

Yes (dunno why all the downvotes) but Apple went even further than the walled garden would require. They could have easily left an Apple backdoor. But they encrypt the protocol going over wires to/from the Enclave. They go insanely far rather than sufficiently far. Yeah, nation state level attacks will still work, especially if they have the phone. But with Android it's not nation state level. It's corporate level an…

I felt that Apple's description of the initial key setup between the enclave and the main processor was hand-wavy at best. I know of another similar implementation that's used by Microsemi for their FPGA-based secure boot process[1]. They claim to protect the initial AES key transmission using an "obfuscated" crypto library that is sent to the processor over SPI on boot[2]. Also, I wonder if Apple exchanges a nonce d…

Read the Apple patent I cited above. Apple isn't exporting an API so don't expect much in the docs. But they do have to teach in the patent.

Re: iOS 10 Security White Paper [pdf]

#48

Post by alexpersian »

CalChris wrote: post #11
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.

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 bre…

Do you have a source on the "breakable at the nation state level"? Last I heard they've only been able to compromise models before the 6.

Re: iOS 10 Security White Paper [pdf]

#50

Post by eridius »

Buge wrote: post #46
eridius wrote: post #15

Earlier quoted context omitted.

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

You could spam them. Anyways, it's a privacy violation. Apple shouldn't be handing out your email without your permission. Facebook has a setting allowing you to choose whether you want your email to be public or not.

Sure, you could spam them, but that's not a special property of Apple IDs. Apple certainly shouldn't be leaking emails, but describing this as "leaking Apple IDs" instead of "leaking emails" makes it sound like it's more serious than it is.
Post reply on HN