Hacker News Reader

Comment by lemiant | Hacker News Reader

Can someone explain how Apple has managed to render brute force ineffective if there are only 10000 possible 4-digit passcodes?

View on HN

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)

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.

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.

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.

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?

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.

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

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.

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

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.

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

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

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

To emulate you need to copy first.

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

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

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.

My 6 year old was very excited to find the passcode feature on his iPad and disregarded Daddy's direct warnings that if he kept changing the passcode ("soccer", "baseball", etc.) he wouldn't be able to remember the result and would get locked out. This, of course happened, and after some tears, the solution was for me to remote wipe the iPad and then restore from iCloud backup. The whole process was an extremely impressive mix of security and usability.

After a few invalid attempts, it forces you to wait a while before trying again, increasing the wait time each time. One can also set the phone to wipe itself after 10 failed attempts.

After six tries a rate limit is reached. There is no cool down period. You have to connect it to your computer and login to apple, or wipe it.

Is that rate limit hardware based? or implemented in software? If it's software, they can update it at any time.

Hardware. There is a chip (or a SoC component) called Secure Enclave that holds the real encryption key and accepts PINs or fingerprint data and releases the key.

Of course, there is the potential that Secure Enclave could be updated with new microcode (I have no idea if that is actually possible).

Aside from the valid points below about rate limits and auto-wiping, the new default is a 6 digit passcode, so more zeros..

You can also have a longer, possibly alphanumeric password if you like.

the same way everyone else does. they limit the number of attempts you get.

I'm not too familiar with how iPhone hardware is put together, but is there a possibility of performing a forensic extraction of the flash memory and performing a brute-force attack offline? Or does the conversion of PIN to the storage encryption key happen in the secure enclave, which may resist such forensic meddling?

Each iPhone comes with a unique key burned into the processor. I believe the PIN is cryptographically combined with the unique key to derive the encryption key on device. That makes offline brute-force intractable without knowing the unique key (or somehow getting it out of the chip by looking at it or something, but it won't be easy).

Ah yes, the infallible password that's really small and hard to see. I'm sure the guys at the NSA were all "man we'd need, like, a microscope or some shit to read that!" and just went to lunch and called it a day. There is literally nothing Apple could do to have a key of some sort on their processor that wouldn't be laughably easy for a well funded organization to get access to.

I am no expert in that sort of stuff, so I have no estimate of the difficulty of it. I'd imagine it's too costly to be worth doing on every random iPhone in every random investigation, but if someone really really wants it, then yes. The weakest link most of the time remains the stupid unencrypted iCloud backup.

If you actually care about security, use a long alphanumeric password. It's not a big hassle when you have Touch ID. If you are ever in trouble, try turning the iPhone off immediately or quickly touch your fingerprint reader a few times with a wrong finger or enter the passcode wrong five times (so that Secure Enclave discards the cached decryption key and no longer accepts fingerprints). Also, use Apple Configurator tool to make your iPhone "Supervised" and don't let it pair with any new computer. And disable iCloud backup entirely.

If you really care about security from an organization like the NSA, the only option is either to have it be entirely air gapped or to be entirely open source, including BIOS and UEFI firmware and anything else that might run on the hardware. There are really no feasible options, and especially so in phones.

It's amusing to see open source still promoted as panacea after all those OpenSSL exploits.

It's obviously not a panacaea, but it does have the quality of allowing audits by the community and by independent experts in the field.

Not being able to read the key material with a microscope (optical or electron) is a specific design goal for these things. This takes me back more than 30 years to my very first job, the summer between high school and college. I had to disassemble and modify a number of crypto units used in the banking industry. These things had all sorts of mechanisms to make it hard to access the key, including zapping the EPROM containing the key with very high voltage if any of the case intrusion switches were tripped. My boss cheerfully informed me that the previous model had used a small explosive charge, and this new one was a safer alternative!

You probably can, but this isn't to access the phone of some international criminal mastermind but of some guy that was picked up on the corner for peddling drugs. Its not like the NYPD can dump 500,000 or more for every phone they need to access.

What worries me is that this will lead to laws being passed that will criminalize refusal to hand over passwords and encryption keys.

the secure enclave stores the actual encryption key. I'm not sure if it's just unlocked or generated from the PIN, but in either case they can only brute force the actual encryption on the flash and not the pin offline.

You don't just get to try 10000 times.

There is an option to "Erase Data after 10 failed passcode attempts"

To everyone replying to this comment saying that you can set a limit and then the phone will wipe itself after the limit has been reached - that point is moot. Although I wish it wasn't so, there are a couple people who were able to setup a mechanism to brute force an iPhone pin by shutting off the device before it registered an unsuccessful attempt therefore ... giving you limitless potential.

That's patched: https://news.ycombinator.com/item?id=9225317 Unless you're talking about a newer instance of the same bug.

Here is what I was referring to: https://youtu.be/meEyYFlSahk

Seems more of a mechanical setup, rather than this guy's video. Like put a kill switch ON THE PATH (i.e. before signals reach) the "Okay iPhone, register this failed attempt" destination.

The automatic thing is just an automatic exploit of the same issue[0] (forcefully cutting power rather than powering off with the buttons might make it more reliable.) It's called an iPBOX and AFAICT it doesn't support iOS 8.1.1[1], when the issue was fixed.

Other commentors have pointed out that the PIN/crypto stuff is handled by dedicated hardware designed to resist tampering, probably pretty much state-of-the-art. The issue before was a software issue. Now that it's fixed it's very hard to completely hack the hardware and would have to be done to each phone individually: https://news.ycombinator.com/item?id=10424439 I'm not an expert, but I imagine intercepting the signal would be just as hard, as the signal is contained within one tiny chip and it might not even be possible to reliably modify a circuit on that scale. You can't just replace the chip with a no-PIN version either, because it contains a unique crypto key to the data you presumably want from the phone. This also makes modifying the chip difficult, because if you screw up you could lose the key.

[0] https://www.mdsec.co.uk/2015/03/apple-ios-hardware-assisted-... [1] http://forum.gsmhosting.com/vbb/10720367-post1.html

Apple fixed that in iOS 8.1.1. (CVE-2014-4451).

Exploits are about information asymmetry, if you know about this and you didn't discover it out yourself it won't be around for long.

I'm not quite sure why I was getting down-voted. This is what I (admittedly should have included earlier) was referring to: https://youtu.be/meEyYFlSahk. Try the password and before the system can register the password attempt, cut the power. I'm actually curious if this is something impossible to fix, almost in a mathematically provable way.

Trivial to fix, I would have thought. Record the attempt before testing for validity, rather than after.

Reply on news.ycombinator.com