Hacker News Reader

On the most recent iPhone, data isn't encrypted based on a 4 digit PIN. It uses a tremendously long piece of data as the encryption key, but the encryption key is only accessible through some special hardware they have (which is essentially tamper proof and brute-force proof) with the 4 digit PIN. But as you said, since they can remotely update the software for this special piece of hardware, it is still susceptible to being compromised.

A lot of the conversation happening in regards to this FBI case is only due to it being an older iPhone that doesn't have this special hardware. Which is why people are confused with the FBI chose this case as their poster child when it would have made a lot more sense with the most recent iPhone.

What's the "tremendously long piece of data as the encryption key"? Are you refering to the 6 digit code?

No, they're referring to the 256-bit AES keys in the CPU and Secure Enclave, which are entangled with the user PIN to derive the crypto key.

Would you explain how 256-bit AES keys CPU and Secure Enclave and user PIN all work together to provide encryption on the iPhone? Is this documented anywhere?

Is this same method employed across different generations of iPhones?

Thanks

Apple's description is here https://www.apple.com/business/docs/iOS_Security_Guide.pdf, and you can find varying quality of discussion in the media by searching for Secure Enclave.

Basically, the Secure Enclave contains a 256-bit AES key physically fused into the silicon during the chip fabrication process. Apple don't know this key, and neither do the manufacturers. It's different on every iPhone. The key cannot be read by any software, or the OS, or even firmware. All that can be seen is the result of using it in a crypto operation.

The key used for actual encryption on iOS is derived by taking an intermediate key derived from the PIN, and then entangling it with the Secure Enclave key (and, I believe, the CPU's key, which is also unique and fused into the hardware, but not quite so secretive). This effectively ties the crypto process to the phone - if you take a data dump of storage and try to brute force it on some more powerful kit, cracking the PIN isn't enough. You'll also have to crack both the AES keys.

This isn't universal across all iPhones - I think the 5S onwards have it.

Awesome. Thank you! I'm guessing Android doesn't have anything like this being that there's no single chip SoC design across Android phones.

> iPhone data shouldn't be encrypted on the basis of a 4-digit PIN. It should have a much longer password that's entered at startup.

As the iOS security documentation details, iOS uses a KDF to generate secure keys rather than just relying on a short PIN.

> The 4-digit PIN can be a "screen lock" to prevent casual friends grabbing your phone and swiping pictures but shouldn't be the thing that encrypts your data.

Photos ARE your data. You either require a full passphrase 100% of the time, or as Apple has done, only allow limited attempts with a PIN. Yes, they* could enforce a passphrase at all times, but this might make iOS less user friendly and drive regular consumers to less secure devices.

* A user can choose to always require a full passphrase/TouchID at all times. I don't use a short PIN on my iPhone.

Disagree - I want to be able to have my phone "casually" locked (when it's on) and "securely" locked (when it's off). If the casual lock is harder to break, that's icing on the cake, but the important thing is that I can quickly prevent access to the phone, and that it will revert to that state automatically after some time.

Ideally my phone would go into "secure" locking mode (requiring my 7 word passphrase) after not being unlocked "casually" for more than X hours.

If the user has to enter the code by hand, it's very impractical to require more than a memorizable number of symbols for the initial decryption code, unfortunately. Plenty of users turn off their phones periodically.

iPhones don't require a four-digit PIN. You can set a nice, long passphrase, which would then make brute forcing completely impossible even with modified OS shenanigans.

The only reason brute forcing is even potentially an option in this case is because the person in question didn't bother to use a secure passphrase.

So, it sure sounds to me like iOS is already doing what you describe. Do you just object to giving the user an insecure option?

Can someone explain how the encryption works on the iPhone? I was under the impression that the 4 digit code is just a screen lock and had nothing to do with the encryption.

Also is there a reason they can't just use this piece of hardware to brute force the phone?

https://www.intego.com/mac-security-blog/iphone-pin-pass-cod...

Lots of info here:

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

The short version is that your passcode (whether four digits, six digits, or a full password) is combined with an encryption key embedded in the device in a way that's supposed to be impossible to extract, and used to derive the encryption key used to protect your data.

The device you linked to relies on a vulnerability in the US, where it would report that a passcode entry failed before recording that failure to nonvolatile storage. Normally, the device starts adding more and more delays to passcode entry after a few failures. By cutting power to the device immediately after it reported failure, it bypasses those escalating delays. As your link mentions, Apple fixed this vulnerability in a subsequent OS update, so that hardware only works on older OSes. This phone's OS is too new.

Thanks for the clarification. Does anyone know how Android's crypto at rest compares to iOS?