Hacker News Reader

Comment by ysv2 | Hacker News Reader

Am I missing something here, or is there no reason the FBI couldn't desolder the 5C's Toshiba NAND flash chip, read its encrypted contents, and perform the desired offline brute-force attack themselves?

The key derivation function is known, right?

View on HN

A few reasons:

- FBI wants to turn Apple's "good security" campaign into something that makes them look like they are not willing to help with the terrorism investigation (thereby, if all goes according to plan, the public will value their own security less than national security).

- FBI wants to be sure the data stays intact. It would be bad for them if they took out the chip and it got cleared. (This is clear in the document; it says the OS should run solely in RAM and make no writes to disk.)

- FBI wants to do this again in the future. Once the software is made and signed, it will be easy for Apple to (a) give it to them so it can be used for other phones or (b) run it themselves on the other phone. If Apple refuses the second time around, FBI can always take out the chip and do it themselves.

- FBI doesn't know everything that Apple knows about where the data is stored on the filesystem, assuming they can get as far as the filesystem. It's easier for them to have a proper UI they can use the phone through.

The last point is moot. It's extremely straightforward to get a dump of all messages, media, pictures, if you get in.

That's been covered by most of the articles on the topic, but not very clearly in this article.

Removing the storage chips from the device would mean breaking a very strong key, perhaps 128-bit AES, which is not a desirable offline brute-force attack.

That strong key is derived from the PIN combined with a unique device ID which cannot feasibly be extracted from the processor. So an offline attack needs to crack full AES, but an online attack by running modified OS code on the device itself means only the weak PIN needs to be attacked (just 10,000 distinct combinations, roughly equivalent to a 13 or 14 bit key).

According to Apple's own whitepaper one the topic, the pin only used to hash the class key, not the encryption key itself.

Perhaps the key could be extracted by physically analyzing the chip, e.g. grinding it down and using microscopic tools to detect state?

Secure chips that store private keys generally keep them on a part of the silicon die that can't be analyzed like the rest of the chip. Any attempt to open the chip package (take off the black plastic/epoxy covering the die) results in the destruction of the secure region and methods of reading state in semiconductors (using electron microscopy) require you to somehow expose the silicon holding the private key.

Apparently this iPhone 5C pre-dates the "Secure Enclave." So the key is somewhere else. Possibly a place vulnerable to a physical readout, possibly not.

Interesting, how does that work exactly? I would've thought with an accurate map of the chip package and a precise grinder you could shave off just what you wanted to expose.

I mean it might take a lot of practice but if you have the time and money and chip samples to practice on...

Perhaps, but that is a destructive option that is very risky.

Thanks for the explanation.

10k distinct combinations-- if, and only iff, they used a 7 digit all numeric pin. The odds of this are not bad for most people, but in this case the person who had this phone has shown better than the average criminals level of OpSec.

One thing is for sure- for phones with TouchID where you only need to enter the pin on reboot, it makes sense to make the pin something other than numeric and longer than 4 digits.

iirc iOS 9 now requires 6 digits passcode on devices with TouchID.

Not true -- 4 digit passcodes work just fine (and are default) on Touch ID phones.

"The default for passcodes on your Touch ID–enabled iPhone and iPad is now six digits instead of four." ~ http://www.apple.com/ios/whats-new/

The key derivation function involves a key which is burned into the CPU, and which cannot be exported from the CPU.

I've been wondering this as well. Even with the key derivation function, I'd imagine the CPU also has some secure keys stored in it as well, and these keys are so long that it wouldn't be feasible to brute force it. I'm not sure if thats how the architecture works but thats what I'm thinking.

EDIT: This seems like a pretty good primer on iOS full disc encryption. http://www.darthnull.org/2014/10/06/ios-encryption

Reply on news.ycombinator.com