31–38 of 38 posts
This is interesting. I hope Apple has some hefty bug bounties on SEP vulnerabilities. I also hope Apple has chosen a sensibly safe language for the SEP firmware code, since correctness is of essential importance here.
Ultimately there will be some exposure from this, and they'll address each exploit as it comes just like the rest of the system.
Earlier quoted context omitted.
Isn't it more like getting the plans to the vault?
It’s more like acquiring knowledge of the mechanics of a safe dial lock: if the mechanism exposes a safe interface, it doesn’t matter. Only if there’s a flaw in the inner workings of the lock, that an attacker can exploit from the outside, does it pose a problem.
Earlier quoted context omitted.
It does more than that. From the [ios security guide]: > The Secure Enclave provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised. e.g. you can encrypt and decrypt, referencing a key by id, but without having the private key ever leave the enclave, even if the app or iOS kernel gets compromised. [ios security gui…
Sounds like basically what a cryptocurrency hardware wallet does. Several months ago I saw a project making wallet software that used the enclave. I forget who they were but I think they'll have a hard sell; everyone just reflexively assumed it was insecure because it was on a phone.
Earlier quoted context omitted.
Indeed, cryptocurrency hardware wallets and the SEP are basically just HSMs (hardware security modules). It's unfortunate people would draw negative connotations from it being on a mobile device. The security architecture of iOS and the SEP combined with the relatively wide deployment of iPhones makes for a great number of use cases.
The secure enclave uses secp256r1 while blockchain typically use secp256k1. Since private keys can't be imported, blockchain devs still require software interface until one or the others adopts the scheme.
Both of these modules use the secp256r1 curve at least, so the signature verification algo which runs on the blockchain can be the same for both types of devices. (You can find some more details on this topic here: http://blog.enuma.io/update/2016/11/01/a-tale-of-two-curves-...)
Since the Byzantium fork there are some precompiles available for curve operations. Using those for the r1 curve signature verification in EVM code brought down the gas cost to practical levels.
Earlier quoted context omitted.
Can you point out the section in that whitepaper that describes SEP in detail? Because all I see is a high-level marketing document.
Says the PhD candidate in hardware security. You may want more low-level details but it's inaccurate characterize it as "marketing". That's just snark. It presents numerous details on the implementation of the SEP throughout the document.
If you would like to avoid such replies in the future, try to avoid making strong, absolute statements. When I talk about topics I am unfamiliar with, I tend to use phrases like "I think" and "I believe" quite sparingly.
> Says the PhD candidate in hardware security.
Again, the fact of the matter is that the Apple security whitepaper is a marketing document. I'm not sure what my background has to do with that though.
Earlier quoted context omitted.
Maybe for a casual reader, but nothing is misleading about the headline unless you don’t understand how Apple’s Secure Enclave Processor (SEP) works. For more on that, as mentioned in the linked page, there’s the “Demystifying the Secure Enclave Processor” talk from Blackhat: https://www.youtube.com/watch?v=7UNeUT_sRos Or here’s the PDF: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...
> unless you don’t understand how Apple’s Secure Enclave Processor (SEP) works. So basically it’s only misleading to 99.9999% of people?
Earlier quoted context omitted.
It does more than that. From the [ios security guide]: > The Secure Enclave provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised. e.g. you can encrypt and decrypt, referencing a key by id, but without having the private key ever leave the enclave, even if the app or iOS kernel gets compromised. [ios security gui…
That sounds like what's essentially a TPM.