Hacker News Reader

Comment by 0x0 | Hacker News Reader

Depending on the settings, the phone could:

  * Wipe after 10 unsuccesful PIN attempts
  * Be configured with a 6 digit numeric PIN code
  * Be configured with an unlimited alphanumeric password
  * Exponentially increase delay between PIN attempts after
    unsuccessful entry - for example 3 attempts in 3 seconds,
    next attempt after 10 seconds, next attempt after 60 
    seconds, next attempt after 4 hours, next attempt after 
    24 hours, next attempt after a week, next attempt in a 
    year (making up numbers to prove a point)

View on HN

Maybe fixed now, but there was someone who got around the 10 unsuccessful (an perhaps the last one as well) by shutting the device off after an attempt was failed (like 0.001ms, not manually)

By "shutting it off" you mean they inserted themselves in between the battery and device and instantly cut power at the right time. Not something that you can easily do to an arbitrary device (especially if you have to give the device back).

And I don't know for sure, but I feel like that one was fixed at some point.

Edit: Yep, superuser2 links to the CVE: https://news.ycombinator.com/item?id=10423257, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4451

These are mostly moot points. They don't have robots trying millions of passwords on phones. They make an image of the phone's memory and brute force it elsewhere. Even a 6 digit code would be cracked in seconds, at most.

False. The PIN is an input to the onboard HSM, which holds the actual key. The HSM itself enforces rate limiting and, if you have the right setting enabled, wipes its contents after N bad PINs.

Physically interfering with the delay/wipe mechanism should be possible. You only have to build the solution once. I can see that this makes it much harder up front, but eventually this too will get cracked.

Since each HSM has a unique key, wouldn't you have to decap one chip for each phone to recover the keys? I think that is sufficient protection to make decrypting phones unfeasibly expensive for most cases.

Indeed this has been done: someone programmed an RPi/Arduino to cut power to the phone after PIN verification and before the PIN attempt was persisted. This effectively defeated rate limiting and the 10 attempt limit. However I believe that was the 5S, and that seems like a fixable bug (record the PIN attempt before verifying the PIN).

Yep, it was patched: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4451

Is it possible to image the HSM somehow?

Very very unlikely. Hardware security modules are designed with the explicit purpose to protect secrets, including from physical tampering.

Why is it unlikely? It's perfectly plausible to emulate any sort of hardware. What sort of magic sauce does Apple have to make a piece of hardware that can't be replicated and modified?

Here's an overview of several techniques used to defeat this: https://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c16.pdf

A replicated HSM doesn't contain the key that the data is encrypted with. You'd need to modify the HSM that has the right key in it. The point of an HSM is to fight you very, very hard on that front by dumping the key if it detects anything shady.

And due to their black-box nature, they are very likely invisibly compromised by the five eyes. Every CEO of a major technology company, including those that manufacture HSMs, is well aware of the lessons taught by Joe Nacchio.

So impossible really means impractical.

That HSM is still just a physical machine, and it can be, with difficulty, modified or copied.

To be impossible it would have to be mathematically impossible (or at least not within human time scales).

Or emulated, which I am sure is not difficult for NSA.

To emulate you need to copy first.

Yes. Really, REALLY impractical.

"Disassemble phone, desolder security module, dissolve the outer layers in hydrochloric acid, cut the silicon into 16nm slices, scan each layer with an electron microscope" impractical.

"In a vaccuum while avoiding all the traps that the HSM maker designed, each of which will physically destroy the key if triggered".

You're missing the point. They don't need to input a pin. There's no phone involved in the process at all. They image the memory and put it on some server for processing. If there's an intermediary step, like an HSM, it is not difficult for something like the NSA to emulate.

You give the HSM the pin, it returns the key used to encrypt the data, applying the rules to that interaction with you. Emulating the HSM doesn't help since it is that phone's specific HSM with the key it knows that you need to access.

You can't. Crypto is done on a separate piece of silicon and dumping memory or NAND will get you nothing but scrambled bits.

From a cold boot user data is not loaded into memory until a correct pin has been entered once, and since A5 nobody has managed to compromise their bootchain it is not really viable to exploit either.

http://blog.cryptographyengineering.com/2014/10/why-cant-app...

To break such a system is not impossible, but would require some heroic effort, even nation states would probably resort to some side channel or the proverbial five dollar wrench.

You claim the contents of memory are encrypted with a 4-digit PIN; I'm telling you this is false, they're encrypted with a 256-bit key held inside the HSM [0]. It matters because a 4-digit AES key is indeed trivial to crack but a 256-bit key is not.

I'm not sure you understand what an HSM is. It doesn't help to "emulate" one. An HSM performs cryptographic operations under certain conditions (such as correct PIN entry) using internally stored keys. The whole point is that you can't get the keys out, only use them. If you had another HSM, or a logical model of one, it wouldn't contain the right keys.

Certainly as engineered systems, it's possible for HSMs to contain vulnerabilities, but getting the key out of an HSM is a much more sophisticated task than cracking a keyspace of just 10,000 possibilities. Possible, maybe.

[0]http://www.apple.com/business/docs/iOS_Security_Guide.pdf

Not true -- on newer iPhones this is actually done on dedicated hardware that enforces these limits.

It's actually really impressive.

Well, given that the Secure Enclave is a processor, I suspect the relevant statement in the whitepaper just means that it's done by software on the SEP rather than the main processor, not that it's done purely by hardware. I could be wrong. But if I'm right, note that the SEP will take firmware upgrades signed with Apple's key, same as the main processor.

Reply on news.ycombinator.com