I'm skeptical of NAND mirroring
blog.erratasec.com
blog.erratasec.com
And.... this is where I stopped reading. With enough electrical engineering chops, you can automate this. With 10k possible passcodes, this only needs to be done 1k times.
What's more, I have a very hard time believing that computers are too slow to create a NAND flash simulator that you physically attach once and make present whatever the fuck you want to to the phone at will.
Then rolling back the NAND to a eariler state is simple and can be done in a split-second, much less than the actual time of the reboot. Depending on the software-implemntation, it might even be possible to roll the NAND back while the phone is still on, saving you the reboot.
So your time is bounded by how often you can reboot.
However, I'd be highly supicous that Apple might have a few bits of perminate storage inside the SOC and can detect multiple re-tries even without trusting the NAND.
What happens is that after ten attempts is that the encryption key (which may be just a few hundred bytes) is overwritten. Since the drive is encrypted you can't then decrypt it but the data is all still there.
So you wouldn't NAND mirror the whole flash drive; you'd just target the place that the encryption key is stored.
They apparently have secure memory to store the PIN. It sounds unlikely that they have not enough secure memory to store the quite small key as well.
So that would be an odd design decision. Do you know for sure that is how it is implemented?
That phone specific to this case does not have the security enclave you're talking about.
In this particular device, the CPU has a small (~200 bytes) storage area of data that never leave the CPU, burned in at the factory, and allegedly never recorded during manufacturing. This data is involved in the cryptography, and this is what you have to brute-force. Short of capping the CPU, or some crazy side-channel attack, it's unreadable.
In addition to that, modern devices have writeable memory areas that similarly stay on-die. That (or is it the related coprocessor?) is sometimes characterized as "the secure enclave" This device does not have that. Since it lacks writeable secure storage, by manipulating the NAND you can defeat the 10-pin lockout, which for obvious reasons has to be implemented in a writeable memory. However that is different than the unlock itself.
I am pretty skeptical of the OP, as it seems to me you could just use a write-blocker to preserve the NAND, without going to the trouble of pulling apart the phone every 10 attempts. You may need to do some emulation if iOS tries to check its write, but surely our friends at a three-letter-agency already have something off-the-shelf for this.
Not directly just a simple "blocker" as the software apparently also reads after the write to check the success of the write, but it seems something a not too complex is doable.
I haven't seen anybody presenting enough details about this implementation to estimate what would be the easiest attack vector, but I guess once it's not limited to "which software I can run" but assuming "we can control the hardware environment of the CPU too" there's more that can be done in this case.
Nobody in this business starts at 0000 and works their way up if they have resource constraints.
"Statistically, one third of all codes can be guessed by trying just 61 distinct combinations! The 50% cumulative chance threshold is passed at just 426 codes (far less than the 5,000 that a random uniformly distribution would predict)." [0]
Similarly, if the phone takes too long to boot, why not take a snapshot of its RAM after it has booted but before you've attempted to login?
I'm sure there's some way to automate the described process with an FPGA or similar.
Secondly, there is a separate issue of the SoC hardware state that's contained in registers separate from DRAM (including CPU state). Rewriting DRAM contents does nothing to change that state.
Edit: It seems that there is a device specific encryption key that may be hard to extract. Bring on the electron microscopes! http://searchmobilecomputing.techtarget.com/tip/How-iOS-encr...
1) That the chip needs to be physically removed to be reflashed, introducing significant down time
2) That the iPhone is incapable of rebooting hundreds of thousands of times
To reflash the chip they'll talk to it directly over the bus on the logic board-either by soldering in a test harness or by building a rig that touches pins/test points on the board. Very likely this rig will be connected to the battery as well to enable quick reboots. The addition of a camera pointed at the screen would enable the cracking software to watch the process.
The idea that the phone would care about the number of reboots is just odd-I don't know why this would even enter his mind as something to be concerned with.
> Presumably, you can make this more efficient by pipelining the process, using multiple sets of flash chips, so that a new fresh set can be swapped in within a few seconds, but it still takes a couple minutes for the iPhone to reboot.
2:
> Can an iPhone even reboot 100,000 times? Nobody knows.
The author seems to be well aware of both of those points. Besides they're not saying that it can't work, just that they don't know for certain that it will work.
What about the increasing enforced delay between individual attempts? I don't see people talking about that much. Is it easy to circumvent?
The delay between the last few retries is an hour, for example. To make 10 attempts at the passcode takes 2h21m in total [1]. So to brute-force a four-digit PIN would take 10,000/2=5,000 attempts for the average case or 500 rounds (at 10 attempts each) at 2h21m per round for a total of ~49 days. Then you still need to add the chip replacement procedure.
[1] http://cinnamonthoughts.org/2010/09/13/ios-passcode-waiting-...
Edit: incorrect numbers and words.
When the cryptography processor is manufactured, a random number (256 bits long, I believe) is built into the hardware. This random number is different for each chip, and it is not recorded anywhere.
One of the functions provided by the cryptography processor is generating a 256 bit encryption key from a shorter passcode. That function makes use of that built-in unique per-chip number. Let's call this 256 bit key the "master key".
That master key is used to encrypt the NAND flash. (Actually, I think there is one more level in there. Each file is encrypted with a random key, and that file's key is encrypted with the master key and stored in the file metadata).
When you try a brute force attack directly against the encrypted NAND flash it is that 256 bit master key that you have to brute force. Brute forcing a 256 bit AES key is far beyond the capabilities of anything in existence, no matter how big their budget and how many people they can throw at the problem.
The only thing feasible to brute force is the passcode, but unless you can take the CPU apart and examine it in sufficient detail to determine that chip's unique number, you have to use the cryptographic coprocessor from that specific phone to do the passcode to master key derivation for each try.
Edit: Oh, maybe because "speeding it up" is not the primary reason for the parallelism. OK, fair enough. The parallelism is to subvert the 10 attempt limitation. Point is, you're still trying 10,000 times.
Or am I missing something?
> After every 10 failed attempts, the chips need to be
> removed the phone, reflashed, and reinserted back into
> the phone. Then the phone needs to be rebooted.
> For a 4-digit passcode, this process will need to be
> repeated a thousand times.
On top of that, it's not parallelism either since you need the specific CPU from the phone (and maybe the LTE baseband chip) to perform each attempt, which cannot be done in parallel. This is 10,000 attempts, one-by-one, with a reflash and reboot every 10 attempts.
Thank you. This was the part I didn't fully appreciate, and should have gone back and re-read the story.
And it's a real shame that comments like yours get downvoted because it's not as if you were trolling or being an asshole.