What you actually want is a NAND emulator on an FGPA.
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.
Really anything that implements the same interface, be it parallel, i2c, SPI, and ideally with the R/!W held high, disconnected, or ignored. I don't think anyone is actually considering reflowing a new IC for every try, that's completely unnecessary.
Would the downvoters care to explain how I'm wrong? Maybe I am, but if so, I'd like to know how.
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.
It's 1,000 because you need to try 10,000 PINs, 10 per "fresh" NAND chip. So the article was referring to doing the NAND "reset" 10,000/10=1,000 times, not the total number of possible 4-digit numbers.
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.
> 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.
The article isn't saying you'll need to guess 1000 times, it's saying "this process" needs to be repeated 1000 times. What is "this process"? It's making 10 guesses, reflash, reboot. Thus the original point starting this thread that "10^4 is not 1000" is based on a misunderstanding since it's making 10 guesses that you repeat 1000 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.
> 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.
The key point most people have completely ignored is that the Flash memory doesn't get erased when the key code has been entered too many times. In any case performing a Flash erase over gigabytes of storage is an expensive (time,battery) operation.
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.
Apparently, devices with A6 processors, such as the iPhone 5C contain a hardware key that is somehow "unreachable" and "unique" but it is "tangled" with the phone passcode to create the encryption key with which the rest of the data is encrypted. It's less than the whole "enclave" but there is the hardware dependency.
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.
"secure enclave" is a marketing term that has grown over time and is hard to speak meaningfully 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.
> it seems to me you could just use a write-blocker to preserve the NAND,
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.
> 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.
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.
> With enough electrical engineering chops, you can automate this.
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.
"The flaw with this approach is that it's time consuming. 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."
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.
I think part of the NAND mirroring approach is that you eschew the last 5 tries and do the switch once you reach 5 in some automated fashion in order to expedite the process. If you're at the point that you're messing with the hardware, the replacement procedure via some emulation scheme or what not is going to be faster than waiting on the lockouts.
Once you have a copy of the phones data on a computer can't you run a bruteforce directly against the encrypted section, instead of having the iPhone software and hardware run the decryption algorithm?
There are two main chips involved here. One is the NAND flash chip that contains the encrypted user data. The other is the CPU chip, which contains the CPU but also contains other functional units. In particular, it contains a cryptography processor.
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.
Yes, the nicest trick, once you make the custom hardware is that the CPU doesn't have to "tick" at the full speed all the time which gives you the chance to process longer the conditions that need some special processing. You can "single step" the hardware.
You can't 'take a snapshot of its RAM' - if you could, there would be no need for NAND write block, you'd just patch the PIN delay/limit functions directly in RAM. CPU and RAM are stacked into the same IC package https://en.wikipedia.org/wiki/Package_on_package
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.
Wouldn't it be possible to take a copy of the NAND and run the whole thing in an emulator? If they can reverse-engineer the decryption algorithm, they wouldn't even need that.
I must be missing the same thing. I would assume that after you copied the flash, you would put the old chip somewhere safe, wire an emulator into the phone, and trap/ignore any instructions that want to wipe it.
This author is basing their reasoning on some fundamental flaws:
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.
This was exactly my thought. You would build a small circuit board with contacts on the bottom corresponding to the footprint of the NAND flash chip. On top of the board would be either a flash chip that is denser than the original flash, along with some circuitry that allows you to electrically disconnect it from the phone and reprogram it externally, or a high speed serial interface with a cable connecting the board to an external device—such as an FPGA connected to enough DRAM to have an image of the entire flash—that lets you emulate the NAND flash.
> 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.
Statistically speaking, it's unlikely to take 10,000 tries (every single permutation) to find the passcode. My understanding is that in most cases, PIN guessing is usually successful in 1,000 attempts or less on 4-digit systems - an order of magnitude difference.
Nobody in this business starts at 0000 and works their way up if they have resource constraints.
According to DataGenetics, after an analysis of 4-digit PINs:
"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]
36 comments
[ 3.8 ms ] story [ 81.8 ms ] threadThen 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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]
[0] http://datagenetics.com/blog/september32012/index.html