[onnoonno]

Wait a bit... So you say that they actually store the keys on the external NAND instead of the supposed-to-be-very-secure crypto parts of the CPU?

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?

[eugeneionesco]

>So you say that they actually store the keys on the external NAND instead of the supposed-to-be-very-secure crypto parts of the CPU?

That phone specific to this case does not have the security enclave you're talking about.

[onnoonno]

Ah, thanks. I am still a bit lost though: What are they going to brute-force then, if there's no such security enclave?

[drewcrawford]

"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.

[acqq]

> 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.

[acqq]

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.