Replies

Thanks for looking into it. The second part of you original claim was correct, the case is not about tech but judicial precedent. But as you just noted, the tech is rapidly making the whole argument moot. Either Apple and every other vendor of (e.g.) FIPS 140-2 will be mandated by a real law to have a back door in every device or they won't and there's no court order or writ or warrant in the world that will make the device give up its data.

I think you ran into was the SoC used to take the passcode, check it against the hash, combine with the UID and create the decryption key that decrypts the AES key. Note that the OS (and RAM and main processor) can be untrustworthy in this system and you proved that by not being able to get the AES key. I wouldn't rule out the NSA shaving down the SoC and reading the passcode hash, but at that point they have probably destroyed the UID and they need both to recover the AES key. Here's a picture of the system (probably):

Note that with your nearly complete control of everything going on outside of the SoC you had no way to obtain the AES key.

That’s a great diagram.

Yes, the problem was that I couldn’t get the key. I was hoping that with a bus dump I could either 1) get the UID and guess the algorithm (failed) or 2) The SoC was stupid enough to write incorrect guess count to flash (it’s not)

No, Apple really thought about this, and I’m genuinely impressed. Even with a shave it’d be very hard.

Everything which is insecure is not trusted in this system, which is a great way of doing things.

Up until iOS8, I think, it was possible to get the UID with a couple of dirty tricks. Now it’s not possible without hardware hacks. I can still get it with bus dumps or very deep hacks, but it’s still useless unless you can guess the algorithm for hashing, AND you have to hack the physical hardware. That’s beyond my ability at home.