Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Encryption Security IOS Iphone Operating Systems Privacy Software Apple

Hacker Claims To Have Decrypted Apple's Secure Enclave Processor Firmware (iclarified.com) 111

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.
This discussion has been archived. No new comments can be posted.

Hacker Claims To Have Decrypted Apple's Secure Enclave Processor Firmware

Comments Filter:
  • by perpenso ( 1613749 ) on Thursday August 17, 2017 @06:10PM (#55037417)
    Great news for law enforcement, this should help them get through that backlog of iPhones they want to examine. :-(
    • by AmiMoJo ( 196126 )

      I've long been thinking that we need a time limited storage system for our secrets like encryption keys.

      I'd suggest storing such data in SRAM. A small capacitor can keep it powered (only needs nanoamps to maintain).

      If the phone is powered off for too long or powered but the user doesn't enter the passkey for a day or two it wipes itself.

      Prevents this kind of attack, prevents any kind of slow attack in fact.

      • I like this plan, but the SRAM itself should still be encrypted with the device key HMAC'd with some other identifier as well (PIN ideally).

      • New standard procedure: Clip this thing onto that circuit board until the nerds arrive with their magic box.

        • by AmiMoJo ( 196126 )

          There is nothing you could attach that would extend the time limit. Also, cops aren't going to take the phone apart and connect stuff to the PCB.

      • by ledow ( 319597 ) on Thursday August 17, 2017 @06:32PM (#55037535) Homepage

        Suicide chips were common for a long time. And although effective are MUCH more trouble than they're worth.

        For example, you'll lose ten times more "genuine" evidence (e.g. witnesses willingly handing their phones over for evidence, then the chip dying while in court storage) than anything you'll save on personal privacy.

        Not to mention, get one duff battery/capacitor and one day your phone just stops working permanently with no possibility of restoration whatsoever.

        This isn't an attack stopped by a suicide chip, either. You buy one device, let it wipe itself a thousand times in testing, get the key out of it eventually, and then you can attack ALL the security chips in ALL the phones way within your "day or two".

        Plus, there's almost no way to ensure the timer is running. Isolate the suicide chip's clock (especially if it has to track real time and be running all the time) and you can pretty much stop it dead so it never gets to the point it can do anything about wiping the data.

        Look into the old arcade stuff. Lots of old arcade games had suicide chips. Lots of them are still emulated. In many cases, people just ignored it and - like this - determined the keys in other ways (lots of arcade games have the equivalent of rainbow tables for their encryption in common emulators because the key itself was never found), in others they de-capped and imaged the chips while they were still working, which lets you basically pluck the stored data and logic of their semiconductors out of a microscope image of the silicon.

        It's a lot of effort to go to, for a lot of risk. But what you describe is basically a proper TPM chip. I don't think anyone has ever successfully broken a TPM chip / keys, have they?

        • by AmiMoJo ( 196126 )

          It's certainly not for everyone. The clock thing is a non issue though. Ultra low power RC oscillator on chip, only +/-30% but that's all you need to measure a couple of days approximately. Protected the same way as the secure enclave.

      • by Kjella ( 173770 )

        If the phone is powered off for too long or powered but the user doesn't enter the passkey for a day or two it wipes itself.

        And when you end up in the emergency room because you were in a traffic accident you'll find that everything you had on your phone is gone forever. For the vast majority the problem is they lose information because they don't have backups and forget keys. The second biggest problem is that the user is hacked, tricked or forced so the attacker has the user's credentials, doesn't matter how good the lock is if the attacker has the key. If you're trying to hack a locked iPhone you're a little bit past script k

        • by AmiMoJo ( 196126 )

          I generally don't worry too much about losing the information on my phone, because I cross borders regularly and have to backup and wipe it anyway. Encrypted backups stored on my server mean I don't need to carry sensitive stuff through border security.

          My main concern is that an attacker gets hold of the phone before I can sanitize it. I want to be able to store private information on it, but obviously can't if it isn't secure.

          • If wanting to store private info on your phone I would consider something like OpenKeychain. While not a nice as VeraCrypt as OpenKeychain will leak info since it encrypts and decrypts to and from a file it is still better than nothing. Unfortunately I haven't found anything like VeraCrypt for android that will create an encrypted file that can be mounted as a file system. If anyone knows of one I am sure others would like to know about it.
    • by Anonymous Coward

      and apple will get to sell a lot more of the next model iphones with a different security scheme.

    • No, having access to the unencrypted firmware does only make a system less secure if you believe in security by obscurity.
      This will make the system MORE secure in the end.

  • by Gravis Zero ( 934156 ) on Thursday August 17, 2017 @06:46PM (#55037627)

    What people aren't grasping is that this is actually good news. When someone breaks security, it forces the device maker to improve their security tactics (lest they be considered insecure devices). The result is that people will get better security. The same is not true about cell towers because telecom companies don't care if your shit is insecure. :/

    • Re:This is great! (Score:5, Informative)

      by cryptizard ( 2629853 ) on Thursday August 17, 2017 @07:21PM (#55037775)
      To clarify though, no security was actually broken here. All he did was decrypt an obfuscated portion of the firmware. This may lead to some vulnerabilities in said firmware being discovered, but as of yet iOS is just as secure as it was yesterday.
      • by Khyber ( 864651 )

        Decryption was essentially negated. That's breaking a layer of security if there ever was one. Otherwise, why would the encryption be in place in the first place? That is the point of encryption, correct? To secure things?

        • by tlhIngan ( 30335 )

          Decryption was essentially negated. That's breaking a layer of security if there ever was one. Otherwise, why would the encryption be in place in the first place? That is the point of encryption, correct? To secure things?

          A minor form. The secure enclave doesn't actually have to be encrypted, it could just be signed. All you need to know is when you start up, you verify that the image is properly signed and then you start the processor up. Encryption makes it so you don't actually have to verify it decrypte

        • Re:This is great! (Score:5, Interesting)

          by v1 ( 525388 ) on Friday August 18, 2017 @08:11AM (#55039829) Homepage Journal

          Decryption was essentially negated. That's breaking a layer of security if there ever was one.

          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)

          Otherwise, why would the encryption be in place in the first place? That is the point of encryption, correct? To secure things?

          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

      • To clarify, there was no sex. He just put his penis in her vagina, moved around a bit. In 9 months there will be a result of this no sex.
  • by Proudrooster ( 580120 ) on Thursday August 17, 2017 @06:58PM (#55037675) Homepage

    Phone Wiki [theiphonewiki.com]

    • I am assuming each version of the iPhone SEP firmware is encrypted with it's own unique key, so we're talking just iPhone 5s with this particular version of firmware I think, unless I'm understanding this wrong.

      It's a big step anyway, because once you know what's inside an encrypted file it is easier to decrypt later generations of that same file.

      So, hacks are probably already out there splitting up this decrypted firmware and attempting to decrypt later versions.
      • by AmiMoJo ( 196126 )

        I am assuming each version of the iPhone SEP firmware is encrypted with it's own unique key

        It can't be. The SEP has to decrypt it, which means it needs the decryption key. Doesn't matter if you use symmetric or public key crypto, in the end you need to store a secret key in the SEP and compromising that key means you can decrypt every bit of firmware released for it.

        This is similar to how battery management processor firmware updates work on their laptops. AES encrypted with a secret key, which they accidentally leaked themselves. The key is protected by the processor's secure memory, which has p

        • That's how a figured it too, but I highly doubt every phone of a generation is using the same decryption key. They probably have different keys for different runs of the particular version of chipset. Can't imagine every phone of the generation has the exact same SEP chip version in it.
  • by Anonymous Coward

    Given the assets available to the NSA, and their propensity to hide defects they find, I would not be surprised if this was already known to the NSA.

After all is said and done, a hell of a lot more is said than done.