
I'm skeptical of NAND mirroring - jessaustin
http://blog.erratasec.com/2016/03/im-skeptical-of-nand-mirroring.html
======
pikachu_is_cool
> 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.

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

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

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

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

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

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

~~~
JamilD
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]

[0]
[http://datagenetics.com/blog/september32012/index.html](http://datagenetics.com/blog/september32012/index.html)

------
MichaelBurge
I'm sure there's something I'm missing, but why not just wrap an old-school
ROM in a controller that emulates the storage interface?

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.

~~~
05
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](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.

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

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...](http://searchmobilecomputing.techtarget.com/tip/How-iOS-encryption-
and-data-protection-work)

~~~
05
Anti-fuses seem to be difficult to read even with electron microscopes.
[http://chipdesignmag.com/display.php?articleId=5045](http://chipdesignmag.com/display.php?articleId=5045)

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

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

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

[1] [http://cinnamonthoughts.org/2010/09/13/ios-passcode-
waiting-...](http://cinnamonthoughts.org/2010/09/13/ios-passcode-waiting-
intervals-for-failed-attempts)

Edit: incorrect numbers and words.

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

------
wodenokoto
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?

~~~
wodenokoto
This is an honest question. Why is it not possible to run decryption directly
against the data?

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

------
dickwads
10^4 is not 1000

~~~
riobard
He is correct in quoting the 1000 number because each cloned phone gets you 10
tries, thus 10 x 1000 = 10^4.

~~~
jnbiche
You're still trying 10,000 times, you're just using parallelism to speed it
up.

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

Or am I missing something?

~~~
biot
The relevant part of the article is:

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

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

