Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by BeauHD on from the mobile-security dept.

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.

18 of 111 comments (clear)

  1. Great news for law enforcement ... by perpenso · · Score: 4, Interesting

    Great news for law enforcement, this should help them get through that backlog of iPhones they want to examine. :-(

    1. Re:Great news for law enforcement ... by AmiMoJo · · Score: 2

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    2. Re:Great news for law enforcement ... by ledow · · Score: 4, Insightful

      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?

  2. Re: Honest Question by Anonymous Coward · · Score: 3, Informative

    Will firstly there is no vulnerability here.

    This does not effect the ability of the secure enclave to protect the user, it does not help law enforcement or any one to crack user data.

    This is simple the code of what it does. If upon examination someone finds a vulnerability, then presumably they will let apple know...

  3. Re:Honest Question by turkeydance · · Score: 4, Informative

    to get a job. (either ethical or criminal) "i did this, which means i'm good". show me the money.

  4. Re: Honest Question by Anonymous Coward · · Score: 2, Informative

    Because just saying "look at this bug I found" gets you ignored.
    If you want the problem solved, you give everyone a tool to exploit it for the quickest fix. Also, even going that far, you may still be ignored.

  5. This is great! by Gravis+Zero · · Score: 2

    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. :/

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:This is great! by cryptizard · · Score: 5, Informative

      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.

    2. Re:This is great! by v1 · · Score: 4, Interesting

      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

      --
      I work for the Department of Redundancy Department.
  6. Is this all iPhones, or just iPhones 5s? by Proudrooster · · Score: 2

    Phone Wiki

    1. Re:Is this all iPhones, or just iPhones 5s? by MatthiasF · · Score: 2

      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.

  7. Re:Not really a surprise by cryptizard · · Score: 5, Interesting

    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.

  8. NSA responds that's' so 2015 by Anonymous Coward · · Score: 2, Insightful

    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.

  9. Re:Not really a surprise by alvinrod · · Score: 2
    You just don't understand just how lucky he would have to get. I don't know what key size Apple is using but AES supports up to 256-bit keys. Here's a quote from HHGTG:

    Space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space.

    2^256 is just as massive. The lower bound for the estimated number of atoms in the known observable universe is 10 ^ 78, which is only slightly more than the number of combinations you can have with a 256-bit key. So everything that exists in that really big space is only slightly more numerous than the possible combinations for one key.

    It's way more likely that someone who designed the secure enclave made a mistake while doing so that left the system open to attack.

  10. Re: Not really a surprise by cryptizard · · Score: 2

    There are a lot of things that are possible but so unlikely that they aren't worth talking about. A colony of ants could randomly spell out the encryption key in the dirt but it is so stupidly unlikely that nobody is going to bother making a post about it. Brute forcing a 256-bit encryption key is the same thing.

  11. Re:Not really a surprise by gweihir · · Score: 2

    Unless you believe in magic, not really.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  12. Re: Not really a surprise by kn · · Score: 2

    192 bit keys are also defined.

  13. Re:What does 'apple root certificate' do? by ledow · · Score: 2

    I wish you were an expert in this field too.

    If the US has a copy of all root digital certificates in the world, it doesn't help them decrypt a conversation one jot.

    Those certs have a private and public key. Public keys encrypt. Private keys decrypt. You can't make/discover/etc. the private one from the public one. You literally GIVE AWAY the public key to anyone and never reveal the private one. They can then encrypt a message to you knowing that ONLY the private key can unlock that message.

    A cert is generated by:

    - Making your own private key, that you NEVER REVEAL.
    - "signing" a message that includes your public key (a "CSR" - certificate signing request). This signing does not involve ANY INFORMATION about your private key leaking. But it can be verified that ONLY your private key could have done that signing (hence it could ONLY be you signing it).
    - giving that CSR to a CA who sign it with their private key (which you never know, but can prove they own it).
    - the general public are then given copies of your public "encryption" key (if you like), which you and and the CA are signing to say are "genuine" (they ensure you own the domain you claim you do).

    AT NO POINT does the CA have, can derive, or require access to YOUR private key. They don't have any way to decrypt communications encrypted for you or by that certificate by an end-user. Your private encryption key NEVER LEAVES YOUR COMPUTER, never gets sent to a CA, is never required except on the HTTPS server itself to decrypt the messages people are sending you.

    No certificate in the world can contain a private key that will decrypt things encrypted with that public key (that you've both signed as "genuine"). If they try to fake that key, it will flag - your users will get errors, people will notice, you can even configure your DNS to tell people what the key SHOULD BE and to STOP USING IT if it ever changes.

    But the SSL certificate is nothing more than "John owns domain.com", and you saying "you can send domain.com a secret message that only domain.com can read using these details". If they fake the first, or try to change the certificate used, your users will ALL see errors in their browsers with dire warnings (even smartphones, etc. will flag if Facebook/Google are being intercepted!).

    CA's DO NOT and CANNOT decrypt your messages. Otherwise one hack of Thawte and the entire world's banking would be accessible. That's not how it works.

    The only person in the entire world who knows how to decrypt the messages you send to a TLS-secured website - without flagging up errors BEFORE you send any critical data - is the guy who created the private key that has probably NEVER left the machine he made it on. Nobody in the process from then on can hack it, derive it, fake it, replace it, change it, eavesdrop on it, or anything else.

    The US can be required to sign every .com on the planet. It wouldn't give them the keys that decrypt the messages encoded with it, and any tricks they play will flag up in any vaguely modern browser as a certificate error before you even start. You USED to be able to, say, make a fake domain.com certificate and pretend it was the genuine one. Now, with things like HSTS, public records of TLS certificates, etc. any changes made to the certificate used on a service immediately flag and error people's browsers.

    The reason nobody talks about it? Because you don't have the first clue what you're talking about. They can have the private key to every root certificate of every CA on the planet. Nothing would happen. People would still sign their certs with those CAs. And people's websites would still all be secure.

    Only idiots that don't use the modern standards to say "This is my cert, and if it ever changes without me signing the change, scream like fuck" would ever be affected, but that's literally the 90's tech that shouldn't be on the net and is using insecure algorithms anyway.

    It's people like you that genuinely think the crap about "acres of datacenters" or "listening to every phone call" actually does fuck all.