Slashdot Mirror
Hacker Claims To Have Decrypted Apple's Secure Enclave Processor Firmware (iclarified.com)
According to iClarified, a hacker by name of "xerub" has posted the decryption key for Apple's Secure Enclave Processor (SEP) firmware. "The security coprocessor was introduced alongside the iPhone 5s and Touch ID," reports iClarified. "It performs secure services for the rest of the SOC and prevents the main processor from getting direct access to sensitive data. It runs its own operating system (SEPOS) which includes a kernel, drivers, services, and applications." From the report: The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor, determining if there is a match against registered fingerprints, and then enabling access or purchases on behalf of the user. Communication between the processor and the Touch ID sensor takes place over a serial peripheral interface bus. The processor forwards the data to the Secure Enclave but can't read it. It's encrypted and authenticated with a session key that is negotiated using the device's shared key that is provisioned for the Touch ID sensor and the Secure Enclave. The session key exchange uses AES key wrapping with both sides providing a random key that establishes the session key and uses AES-CCM transport encryption. Today, xerub announced the decryption key "is fully grown." You can use img4lib to decrypt the firmware and xerub's SEP firmware split tool to process. Decryption of the SEP Firmware will make it easier for hackers and security researchers to comb through the SEP for vulnerabilities.
Great news for law enforcement, this should help them get through that backlog of iPhones they want to examine. :-(
I would say it is at least a little surprising. I can't find anywhere where it is described how the key was obtained, but it is large enough that it couldn't have been brute forced. And, ostensibly, it only exists inside the secure enclave and in Apple's care. A breach in either place would be surprising.
This was a small shade of "security through obscurity" but is only a thin veil. The performance of GOOD security or cryptography isn't affected by exposure of its methods. Like you see in the movies, where the criminals get the floorplan of the vault, the schedule of the guards, placement of the cameras etc etc, and manage to come up with a plan. That means the security was actually quite poor. They should have looked at it and said "Well... I guess there's just NO way to break into this place without getting caught." Now that still doesn't mean they publish their guard's schedule on the web page.
The reason of course is that vulnerabilities may (and usually DO) still exist, and obfuscation or hiding of your security information does help a bit to mitigate that, but should not be seen as a solution. That's why good security is constantly changing and improving itself.
You could even look at this as a good thing for them. Hackers love a challenge. A few of them will find a few holes, and publish them. (either for the credit, or the bounty, or on the darkweb etc) And any of those that are made public will get patched. There'll still be a few zero-days, the kind that either lurk in the kernel for years in plain sight without being discovered (think ShellShock) or the kind that teams of state-actors dig up and use for espionage. (think NSA dump)
In this case, there are two types of encryption going on. One is just obfuscation. The reason is that the key is there. The hardware decrypts the firmware and runs it. It has to be able to decrypt it unless you're going to key in a 128/256 bit key every time you turn on your phone, hence the symmetrical cipher. So it may as well not really even BE encrypted. To say you "negated" something that was already negated is silly. I wouldn't even call this "encrypted". The key is right there, so it's really more "encoded" than "encrypted". "Encrypted" means you know the process but you need the key, "encoded" means you have the key (if there even is one) but you need to figure out the process.
The other encryption, the Asymmetric one, is the one that signed the firmware. The hardware decrypts the firmware, then checks the signature to make sure it hasn't been changed. No amount of searching the hardware or firmware will reveal the code to do the signing, as it doesn't exist. The public key is there, but not the private key. Now if the hackers had figured out THAT one, okay, NOW you can call it actually hacked. This wasn't hacked, it was simply researched. BIG difference.
TL/DR time?
OK that was a bit long-winded (but necessary) groundwork. What does this mean for ME? It's always safest to assume that people can and will do anything that's reasonably possible to be done. Digging out the obfuscation key is just something that's going to happen sooner or later. Where does that leave us? Since there's no private key to be dug out, and the crypto that's used in the signing isn't going to be brute-forced anytime soon, here's your options on how to leverage the firmware:
1) you could find a bug in it that you can take advantage of. Maybe a timing condition or a race. Maybe a back door. (VERY unlikely in this case) For example, they may find that if you wait EXACTLY 83 seconds between passcode attempts, there's a bug in the firmware that doesn't increment the attempt count toward a device wipe. LEA would find this useful, and someone would make a lego mindstorm or arduino contraption that would guess your pin in a few weeks. (go look for the Garmin ones on youtube) They may even find a way to get it to unlock without the correct code, but this is far less likely. (though not com
I work for the Department of Redundancy Department.