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. :-(
Could be many reasons. I would rather they communicate to the company first, then publish. But it's better to get the knowledge out there. Vulnerabilities that are hidden are ripe for zero day exploits. Those can be abused by criminals, law enforcement, and intelligence agencies.
But getting credit for it is probably what most hackers want. Curiosity is a large part of it. Money, maybe. Embarrass the company is likely low on the list.
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...
to get a job. (either ethical or criminal) "i did this, which means i'm good". show me the money.
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.
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.
Phone Wiki
They wouldn't need to. they have all the pipe wrenches they'd ever need. (And by pipe wrenches, i mean physical pipe wrenches, as well as whatever metaphorical pipe wrenches you can think of for compelling someone's cooperation)
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.
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.
It could have been brute forced, and the guy just got lucky.
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.
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.
yeah... hence the <em> tags around "could"
ostensibly, it only exists inside the secure enclave
If they're referring to unmodified TrustZone then it's secure by emphatic assertion of Arm's marketing department. "This bit is secure, because we've said it is". I don't know whether Apple have made further changes or done their own firmware, but hacking TrustZone isn't that hard.
Following up to my own post: OK, it's not (don't)TrustZone but a distinct processor. Well done Apple for doing it properly (although this ref then claims it's just TrustZone, which doesn't seem to be the case).. I'm assuming the guy found a flaw in the SEP, which for example has it's own I/O lines for GPIO, SPI, I2C, etc, so you've got a large attack surface and direct access to the CPU.
First of all, love the H2G2 quote, but I think AES supports 512. It's the default level of encryption OpenSUSE asks during installation; it actually says "AES 512" on the screen. I could be wrong or misunderstanding, but that's what the installer says and my system immediately asks for a password before mounting my swap and home partitions during boot.
I would recommend reading "Hacking the Xbox" by Bunny. Also, most of the security community assumes that an attacker with physical access will get in eventually, with the only possible exception being a real HSM (at, say, $50'000 and up per piece). A HSM would eventually get hacked as well I expect, but they are too expensive and too uninteresting (due to very limited deployment) for that to happen.
I do hope we get a detailed write-up of the hack, these are always pretty interesting.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
You are wrong. AES supports either a 128 bit or 256 bit key.
You forgot one: No girls allowed!
On filesystems, there's one method of setting it up that basically requires two keys: this is sometimes called (whatever) 512 for a 256 bit key. So "AES-512", while not accurate, is how some people have read AES-256 XTS, with one 256 bit key for the cipher and one 256 bit key for the IV.
192 bit keys are also defined.
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.
And, ostensibly, it only exists inside the secure enclave and in Apple's care
It only exists unencrypted there. It also exists encrypted in the firmware update blobs that Apple ships. It's entirely possible that Apple's use of encryption in their distribution chain included some flaws. This wouldn't be the first time: there was a vulnerability in FileVault2 (Apple's full-disk encryption code) caused by incorrect use of AES keys, which dramatically reduced the search space.
I am TheRaven on Soylent News
If upon examination someone finds a vulnerability, then presumably they will let apple know...
Or sell it for a million on the vulnerability market.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Mistrust authority—promote decentralization.
You'll love this Hacker Ethic until one day when your own and your loved ones' personal details are hacked and uploaded to torrent or reddit.
Actually, I would bet a true HSM (host security module) would not get hacked for the main reason that it must have physical security surrounding the key storage so if there is a physical breach, the keys are destroyed.
1. It is called "Hardware Security Module"
2. What makes you think there is only one device involved in finding out how to bypass exactly these detectors?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I have some people try to do "AES 512" by chaining AES, or even doing triple AES (encrypt-decrypt-encrypt) like how triple DES was done. This is brain dead, and shows the person who wrote this doesn't have a clue about crypto.
Want more bits? Cascade different encryption algorithms, similar to how TrueCrypt/VeraCrypt does it. It is wise to use a multi-algorithm cascade anyway, because if one gets broken, there are two others. For asymmetric algorithms, same thing. Cascade RSA, some elliptic encryption, and maybe a lattice algorithm, and have each of them have a chunk of the key.
Writing security programs and doing the job right isn't trivial. Computing is littered with many, many broken and worthless crypto programs because of people trying to reinvent the wheel, making their own worthless algorithms, or implementing existing algorithms in a brain-dead manner (ECB, for example.)
Is TrustZone like a hypervisor, or is it like a LXC, managing containers/worlds? It would be nice if ARM supported VMs on the chip level with a standardized hypervisior.
Does combining algorithims really combine the keysizes? or does it actually just have the same key size but in a third algorithm you just haven't discovered?
Can you be Even More Awesome?!
Having two algorithms result in an unxpected third transformation is called a "group". Realistically, with TrueCrypt/VeraCrypt's cascades, you are not getting 3*256, or 768 bits, but somewhere between 258 bits and 768 bits. There is a lot of advanced crypto study on this, especially if one algorithm when used may weaken the second algorithm used after that. However, 99.99999% of the cryptographic breaks tend to be along the lines of weak key management and storage, or failure to implement existing algorithms in a secure fashion.
Following up to my own post: OK, it's not (don't)TrustZone but a distinct processor. Well done Apple for doing it properly (although this ref then claims it's just TrustZone, which doesn't seem to be the case).. I'm assuming the guy found a flaw in the SEP, which for example has it's own I/O lines for GPIO, SPI, I2C, etc, so you've got a large attack surface and direct access to the CPU.
From what I understand from previous flame-wars on the subject, it is NOT TrustZone-based, but rather completely home-grown by Apple. Since Apple has an Architecture-level license with ARM (one of the few companies that do), they can pretty much do what they please inside of even the ARM core, let alone any peripheral subsystems.
Well, first, since both the Thales and Futurex manuals I have refer to their own products as "host security modules", I still stand by my first statement. Second, if you actually look at the internal setup, you will notice that any attempt to breach the area where the master key is stored, the electronics are damaged to where the keys are permanently unrecoverable.
The way to brute force is simple and widely known.
1.Simply create a pocket universe where time run many many times faster than ours
2. drop your computer in there
3. run the brute force
5. retrieve the computer with the results from the pocket universe
6. make sure to safely deallocate the pocket universe when done.
good grief, do I have to tell you monkeys how to do everything?!!!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
The hacker is actually a /. editor and it was a typo meant to be "known".
Interestingly, their websites call it "Hardware Security Module", you know, like everybody else does:
- https://www.futurex.com/produc...
- https://www.thalesesecurity.co...
As to you second remark, do you actually think a HSM is unhackable? That would be pretty dumb.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
...especially if one algorithm when used may weaken the second algorithm used after that.
That is a concept I can't wrap my head around. Wouldn't that open up the possibility of using an intermediate encryption before an attack? Or is that just if you re-use the same key for the second algorithm?
Can you be Even More Awesome?!
There might be an algorithm C which is equivilent to (A(B()). However, the chance of that is quite unlikely, especially if a proper implementation of the cipher is used (CBC, for example, or XEX), it makes this almost impossible... likely less than the chance of brute forcing the key.
As for reusing keys, if one has three different algorithms (AES, Twofish, and Serpent), three different keys should be used. This ensures that if one of the algorithms coughs up a key somehow, the other two are still working.