
The FBI can almost certainly crack the San Bernardino iPhone without Apple - lisper
http://blog.rongarret.info/2016/02/the-fbi-can-almost-certainly-crack-san.html
======
mrpippy
This assumption is not correct. The (4-digit) passcode is entangled with the
device's unique ID, which is burned into the A6 application processor (on the
other side of the logic board). It's theoretically possible to extract the UID
from the A6 at the silicon level, but not realistically possible.

I suggest you read the iOS Security Guide:
[https://www.apple.com/business/docs/iOS_Security_Guide.pdf](https://www.apple.com/business/docs/iOS_Security_Guide.pdf)

~~~
lisper
It doesn't matter that the UID is incorporated into the key. If you have a
copy of the flash then you can restore the device to its current state, at
which point you can brute-force the PIN. The only way this could not work is
if the A6 has some non-volatile storage on-chip and it is used to prevent this
kind of replay attack, but AFAIK this is not the case.

~~~
tzs
I _think_ it does have non-volatile on-chip storage, which is used to store a
randomly generated key that is encrypted with the key derived from the PIN and
UID. It is that randomly generated key that is used to encrypt flash data.

I cannot find documentation to verify this. I presume the people down voting
you do, but unfortunately they've chosen to down vote instead of being useful
and posting a link. (The only link I've seen is for A7 and later systems)

~~~
lisper
What you describe would not defeat a brute-force attack on the PIN using a
duplicate flash. The only way NV-storage on the A6 chip would do that is if it
stored the attempt counter there.

------
sabujp
all of you were wrong and he was right

~~~
vatotemking
relevant link
[https://news.ycombinator.com/item?id=11248320](https://news.ycombinator.com/item?id=11248320)

------
teacup50
The author is absolutely, totally wrong.

The PIN number is entangled with the device's 256-bit "UID", which itself is
on-die in the SoC/CPU and _NOT_ extractable without either being able to run
code on the CPU, or decapping the SoC, reverse engineering its implementation,
and extracting the UID, all from the SEM imagery.

The PIN number and the UID are fed to key derivation code for strengthening;
the result of that process is used to actually perform encryption of the data
on the NAND.

The weak point here is the PIN number; the FBI would be extremely hard-pressed
to brute force the derived AES keys.

This is described in the "Tangling" definition on page 59 of the iOS Security
Guide:
[https://www.apple.com/business/docs/iOS_Security_Guide.pdf](https://www.apple.com/business/docs/iOS_Security_Guide.pdf)

I flagged the article, as the entire argument is predicated on a factually
false premise.

~~~
CPLX
For what it's worth I unflagged/vouched for the article because I think the
premise and the comments refuting it are an interesting discussion.

Even if he's wrong, the reason _why_ he's wrong is informative.

~~~
lisper
Thanks! I really did want to respond to this.

It's possible that I'm wrong, but not for the reasons given so far. Once you
have a copy of the flash you can always get back to the current state by
installing a copy of the flash in its current state. Then you can simply
brute-force the PIN.

~~~
CPLX
Is that true though? Other commenters are arguing that the encryption of that
flash chip is a value that, while based on the PIN, is sufficiently long as to
resist brute force encryption. Is it possible that you're mistaken?

~~~
msherry
He's not claiming that you can brute-force the encryption key -- he's
proposing another way to brute-force the PIN itself that won't trigger
exponential timeouts or auto-wipe of the device. I don't know if he's right or
wrong, but let's at least make sure we're clear what his argument is first.

------
lisper
Just posted an update, but I thought I'd reiterate it here: it doesn't matter
that the UID is used in the key derivation. Once you have a copy of the flash
you can always get back to the current state by installing a copy of the flash
in its current state. Then you can simply brute-force the PIN.

~~~
teacup50
How do you brute force the PIN if the KDF process operates over the PIN, plus
a 256-bit UID that's only accessible to signed code running on the SoC?

If you modify the kernel on the NAND, signature checks in the on-die
bootloader will fail, and you won't get to run.

If you modify application binaries on the NAND, signature checks in the signed
kernel will fail, and you won't get to run.

~~~
lisper
Turn on the device. Make 5 PIN guesses. Replace the flash chip with a copy of
the original. Reboot the device. Make 5 more guesses.

~~~
Someone1234
That sounds time consuming. 5,040 possible pins with the 4x length pin and
151,200 possible pins with the 6x length pin.

~~~
lisper
I don't know how long it takes a 5C to boot, but my iPod takes 30 seconds. Add
another 30 seconds to swap out the RAM chip (I'm assuming a ZIF socket has
been installed) and you can brute-force 150k PINs in 30k minutes which is
about 3 weeks.

------
Gernot
The flash is not wiped after 10 attempts. The key is thrown away after 10
attempts, and it's stored in the secure enclave. So flashing the memory to its
last state does nothing, it's not even necessary. The actual key to the files
is made of Device-ID (can't be read, binds any attack to the device) + random
key (can't be read, can be securely thrown away) + file-specific data (so you
need a different key per user file) + the users passcode (only component not
on the device). It's a very elegant system actually.

~~~
chadzawistowski
The 5c doesn't have a secure enclave. That came with 6.

------
Someone1234
This author doesn't support the technical claims they're making with technical
fact.

They point at the NAND chip and just say "pull off the encryption key, then
decrypt the device" but without supplying any fact as to how the key was
stored in the iPhone 5S, what kind of resources reversing it would take, and
if Apple has employed any kind of anti-reverse engineering means.

For all we know Apple could have thrown different elements of the decryption
key all over the device, the A7, the NAND, and elsewhere. Without more
technical specifics it is hard to draw the conclusion this article draws.

~~~
lisper
The 5C has an A6, not an A7.

~~~
Someone1234
Misread it as a 5S, not 5C. So yes an A6 in the 5C.

What say you about my overarching point about the technicals of key extraction
and decryption? Do you have any information on more specifics? I am not
calling you wrong, I am saying you aren't showing us enough specifics to say
you're right.

------
spdustin
> They are not worried about the data on the San Bernardino iPhone, because if
> they were they would have had it by now.

I wish this was the point made by more mainstream media outlets. Not for the
reasons the article author posts, but rather that the SOP for Apple devices
involves bringing it to a known access point and powering the phone to allow
an iCloud backup to occur.

~~~
Someone1234
Unfortunately the iCloud backup option is no longer available to the FBI now
as they changed the iCloud password.

~~~
spdustin
Precisely - from where I'm sitting, the disregard for standard forensic
examination procedures [0] shown by the reset of the iCloud password proves
that their actual desire to obtain the data is not in proportion to their
assertion that Apple gives in to their demand.

Additionally, had they brought the device to a known access point and plugged
it in to a charger, they could have availed themselves of another handy thing:
Access to a computer synchronized with iCloud would've yielded an iCloud-
specific token that could be used to download and extract the backup (without
Apple's involvement), bypassing even TFA. [1]

[0]: [http://www.nij.gov/publications/Pages/publication-
detail.asp...](http://www.nij.gov/publications/Pages/publication-
detail.aspx?ncjnumber=199408)

[1]:
[https://www.elcomsoft.com/eppb.html](https://www.elcomsoft.com/eppb.html)

------
payne92
This attack vector also assumes that 100% of the phone state is in the NAND
chip -- is that known to be true? The phone has a lot of modules.

The article is interesting, but it presents a hypotheses with far more
confidence than it deserves. People finding the article, and not this
discussion, will be misled.

