Also, don't be mislead by the headline. To quote a comment on the article:
"Imagine the Secure Enclave as a vault. Apple hung a big, dark curtain over it to prevent anyone from even seeing the vault. Now, that curtain has been opened and people can see the vault. The vault, however, is still locked as securely as ever."
Even if you understand firmware (which I wouldn't expect of most readers, just some; the reason we develop abstractions is so our fellow hackers can hack on new things instead of studying the same things we already studied and hacked), it's extremely common for companies that keep security software secret to rely on that secrecy for security. You need to understand the Secure Enclave in particular and believe that the Apple folks are both talented and honest enough to implement what they say they're implementing to know that, in this case, that's not what's happening.
I think the best you can hope for, even here, is that the majority says "from the headline I'm not sure what that means in practice, so I'll reserve judgment until I look into this."
Back when this was first posted, the headline on HN from an article was “Secure Enclave decrypted”, which couldn’t be further from the truth. The more nuanced “Secure Enclave firmware decrypted” replaced it, and is vastly more accurate. Both headlines fail a general public test IMO, but at least the “firmware” is factually true!
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.
Actually the sentence you've chosen is misleading. This is the essential step towards breaking the iPhone open. The next steps will be less news worthy, til we get a jail break
> It’s a black box that we’re not supposed to know anything about
Nope. Apple published a whitepaper that details how the SEP works.[1] Decrypting the firmware does help researchers look for vulnerabilities in the implementation, but it's not like Apple is relying on it being a black box.
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.
The article claimed that SEP is a black box, which you strongly denied based on the contents of the security whitepaper. But when confronted, you failed to present which part of the document presents how SEP is implemented in detail.
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.
There's a video of a presentation by Ivan Krstic (head of security engineering, Apple) at Black Hat from 2016 about iOS security: https://www.youtube.com/watch?v=BLGFriOKz6U
How does one find such a key? It's my understanding the brute forcing such key would take billions of years on a regular CPU, so can anyone here explain how this was (probably) achieved?
> 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.
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.
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.
https://www.trustedkey.com actually uses the Enclave and also the equivalent component (Secure Element) in Android phones.
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.
Ah, too bad. Ethereum is supposed to be adding signature abstraction, so you can use whatever signature scheme you want; maybe using secp256r1 with phones would be a good application of that.
This was actually cracked back in August, and sites quoted Apple as saying they have no plans to fix it, presumably because obscurity is not security and they originally encrypted it because well, why _not_?
Ultimately there will be some exposure from this, and they'll address each exploit as it comes just like the rest of the system.
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.
