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. :-(
Maybe I'm out of the loop but please humor me on this one:
WHY do people post vulnerabilities? Especially choosing to not reach out to company beforehand?
- to embarrass the company?
- to make money somehow?
- for e-peen or digi-cred?
- or finally, just because they can?
If I find someone's wallet I look for the drivers license address & fucking mail them their wallet. I don't take out a billboard & announce to the world that their dumb-ass lost their wallet. What's with posting the numerous & infinately INEVITABLE loopholes in systems?
thx- genuinely curious.
He's a hacker, therefore a criminal, therefore lock him up already, it's the law.
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.
That's the same key I use on my luggage.
Phone Wiki
Kind of ironic a nation-state couldn't do this already.
And since they make an instant name for themselves in the security-community, there is also ample motivation.
Oh cool so I should include a "secret hacker handle" section on my resume and claim to be the anonymous hacker known as "xerub" and apply to all the security companies?
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.
I mean, it would be roughly the same chances as you buying one lottery ticket and it being the winning one every day of your life for 100 years. So... probably not.
Probably not, but still possible.
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.
and he lives in HELL!!
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.
Pretty sure they could figure out you don't have that skill within three questions.
We now know why iOS is so slooooooooooooooow!
Among other things iOS transfers our Loli images in Pictures to the FBI But the FBI chaps get so "worked up" that the "directories and images" get flushed down the toilet with the Kleenex tissues!
Haa hhahaha
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.
What does the 'apple root certificate' do?
If a nation state had a copy of the root certificate, would that be equal to eavesdropping capabilities?
I think there is no way NSA would not end up demanding that root certificate, or any other digital certifictate.
I wish I was an expert in this field, because I think US have a copy of all root digital certificates for the internet, making me think that TLS over HTTPS is just a joke as far as security goes. A nation state tool for surveillance that nobody talks about, though I could be wrong, because I don't know what the value of root certificates are for encrypting the web with TLS and with the use of digital certificates.
Maybe a root certificate incorporates a crypto backdoor into what one could derivatives digital certificates? Or could each digital certificate be uniquely random, so as to guarantee not having a built in backdoor into the numbers?
You are wrong. AES supports either a 128 bit or 256 bit key.
Bruteforced keys do not "grow". You do not get "partial" results.
So, just forget bruteforcing. That was not the way.
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.
He is the best slashdot troll. Though I admit to smiling at the "where are my cock eggs" cracks too.
192 bit keys are also defined.
This "bastion within the SoC" approach (all of 'em do that somehow) seems to make a lot of sense when you think of those FBI's attempts to crack single iPhones.
When you realize that your phone vendor is in bed with their DRM vendor, or even worse, with an authoritarian government (or with both!), and that you don't own the bastion... you are happy for each and every hack like the present.
Now let's hope publishing those hacks doesn't get shut down under some DMCAish regime, or "the tarrists"/"the children".
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
Challenge accepted. j/k
Too late I am!
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.
"A colony of ants could randomly spell out the encryption key in the dirt"
That explains the "ugly bags of mostly water, we need more lettuce" messages I've been seeing next to my garbage can.
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?!
Doesn't seem like the real guy. Too many words that are not "app" derivatives.
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.
It is the usual master key punishment the world we live in deals us, and we can get it for laziness and stupidity. Apple are suffering it for using a static key to encrypt their security module firmware. Now the security module code will be examined for vulnerabilities of which there will be a bunch. People might be able to rescue Error-53 phones too after this, so this is a real tangible loss for Apple right there.
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.
I am not sure of the "typo" explanation here.
That doesn't really match the twitter timeline.
He first posted a portion of the key, mentioning "a key is growing":
https://twitter.com/xerub/status/892916164657065985
And a partial key was posted.
Then he posted the complete key. with a "key is fully grown"
https://twitter.com/xerub/status/897896081874329600
And the full key was posted.
Unless he deliberately withheld a part of the key, the key actually "grew".
And if it did, that is incompatible with any bruteforcing that can be performed on AES.
...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.