News for hackers. Stuff that matters.

A comment on iOS 10 Security White Paper [pdf]. Parent comment

Re:iOS 10 Security White Paper [pdf] by CalChris on Saturday March 25, 2017 @06:51PM (#13957944)
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.
[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by Cyph0n on Saturday March 25, 2017 @08:25PM (#13958261)
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 the Secure Enclave is a custom IC designed by Apple? I wouldn't be surprised if it's the former as it becomes much cheaper to implement the required security features.

Edit: Check out this previous discussion on this exact topic: https://news.ycombinator.com/item?id=8410700

[1]: https://www.arm.com/products/security-on-arm/trustzone

[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by bryanbuckley on Saturday March 25, 2017 @08:54PM (#13958370)
> 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.

[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by Cyph0n on Saturday March 25, 2017 @09:06PM (#13958416)
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.
[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by bryanbuckley on Saturday March 25, 2017 @09:35PM (#13958530)
Depends on the HW manufacturer and SKU on what is bundled or not.. Even ROM code can be different per SKU.
[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by CalChris on Saturday March 25, 2017 @08:35PM (#13958304)
TrustZone was announced 2012 (?). The Security Enclave is a separate very Apple designed chip. They've patented aspects of it, dated also 2012:

https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De... https://www.google.com/patents/US8832465

[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by bryanbuckley on Saturday March 25, 2017 @08:52PM (#13958365)
> TrustZone was announced 2012

No, 2012 was when Trustonic was formed from competing TEE vendors: ARM, Gemalto, and Giesecke & Devrient.

TrustZone has been around since before that. TI OMAP were front-runners of using it.

[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by izacus on Saturday March 25, 2017 @06:58PM (#13957967)
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.
[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by CalChris on Saturday March 25, 2017 @08:21PM (#13958241)
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 and maybe less if they have the phone.

[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by Cyph0n on Saturday March 25, 2017 @09:14PM (#13958445)
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).

[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by CalChris on Saturday March 25, 2017 @09:37PM (#13958536)
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.
[ Parent | on HN ]
Re:iOS 10 Security White Paper [pdf] by emsy on Sunday March 26, 2017 @07:52AM (#13960321)
There was an article about iOS security where someone argued that Apple controls the enclave for security reasons, to which I answered that this is basically security by obscurity. You can see I was downvoted for this: https://news.ycombinator.com/item?id=13676135

I still downvoted izacus because it was an uncharitable fanboy rambling. The charitable interpretation would be that the walled garden (in regards to the enclave) is a side effect of their implementation, and not the intention.

[ Parent | on HN ]