OK, I’m back after several hours hacking iPhones.
So, I’m going to admit I was wrong. I can’t do it. Not in the scenario given. I’ll give the reasons why, which hopefully some will find interesting.
Now, I never intended to claim I can crack AES, that would be a very stupid claim to make. AES is rock solid, and I know this as the HIPAA expert at my company. It’s gold standard encryption. Especially the FIPS140-2 variant of AES256, which means it’s been certified.
My attack vector requires access to a phone *backup* on a desktop computer. With that, I can load it into the iPhone simulator, hack the code on that to stop the check on number of incorrect passcode entries, and fire sequences of PINs at it until it spits out the right result. This works; I just tried it.
HOWEVER, and this is where I admit defeat, with just the phone, the hardware won’t play. I can hack the software, but without physically removing the crypto chip, shaving the surface off and reverse engineering it (a process which is possible, but will cost a couple of hundred thousand bucks and could well just break the chip), it isn’t possible. You’d have to do that to get the AES key, which is what you need to decrypt.
So, I am wrong and I apologize to Swordmaker. I gave it my best college try and failed.
I’m going to add some more to this because I’m amped up after hours of trying it.
That crypto chip is a work of art. Apple really, really thought about this. I figured I could bypass it with some clever hacks, but it’s simply not possible.
For a little while I even had the phone plugged in to some electronics to try to grab stuff of its internal bus, but EVEN THAT isn’t enough to bypass the chip. Sure, I could stop the flash erase, but that doesn’t help without access to the AES key - I *have* to have the key to decrypt.
If I were the NSA with unlimited cash I’d attempt the chip shave, but that’s the only way I can see this working.
I made a strong claim, tried to back it up, and failed. More fool me.
Fair enough...and I did find your post interesting :)
Words you don't see very often these days. Typically, when posters realize they're wrong, they quietly leave the thread and never return.
You're a stand-up dude.
Anyhow, plenty of posters on this subject have chimed in with "I could hack that phone!" Looks like you actually tried. I appreciate your detailed efforts and where it was you hit a brick wall.
Well don’t feel bad!
Apple told the court it would take a team w/up to 6-8 programmers less than a month for them to do what the FBI wants.
Even assuming a very high-ball estimate that’s a whole lot more information and manpower than you can apply!
It’s not just about judicial precedence. Easy, universal encryption is just going to get more common.
There’s a valid need for it- but how can the courts do their job if more and more evidence is beyond their reach?
Thanks for your explanation, which shows you are not just some BSer. . . sp apology accepted. However, even trying the shaving routine is unlikely to get you anywhere. First of all, the AES key is not stored on the chip. It is calculated anew each time the iPhone is opened. Also the chip is a multilevel technology, so finding what you need would be quite difficult before you destroy what you are seeking. Secondly there are some volatile information stored in there you MUST have to do the decryption that will most likely not survive the process, obviating continuing the process.
Among those volatile data are the random number calculated from the combined randomized input from camera, microphone, accelerometer, and other sensors of the iPhone when the user first enters his passcode, and also the one-way HASH used to compare whether the input passcode of whatever size matches a recalculated one-way HASH to allow the startup to continue and the passcode itself to be included in re-calculating the entangled 256 bit AES key.
That key is made up of the user's passcode, which is entangled with an-recorded anywhere unique device ID, a group ID that is identical on every similar iOS device, and the above described random number stored in a dedicated EEPROM unreadable from outside the Secure Enclave or Encryption Engine by anything running in RAM, the Data Processor, or even external hardware or software probes.
As you pointed out, the only thing that might have a chance of doing what is required to learn what is needed is to reverse engineering either the Secure Enclave chip or the A6 processor with the Encryption Engine. However, Apple has designed both systems to require the decryption/encryption process be done on the iPhone due to hardware incorporation of much of the software. Without all of the hardware being present and working, it simply can't happen.
That's where you ran into your wall. Apple has not emulated the Encryption Engine or the Secure Enclave, the chips necessary, for the development community.
My hat is off to you, sir. You are an honest poster. You admitted when you were wrong. That is rare. We've had blowhards on these threads who claim they could do it and just keep claiming it. You are the first who actually made the effort and then explained and admitted his failure with an explanation that matches our knowledge. Thanks.
Thanks for the clarification. I’ve been following this as it unfolds and was curious how your hack would turn out.