[codesuela]

The phone was released with iOS 13 which prominently featured enhancements to USB restricted mode[1] which was supposed to defend against GrayKey/Cellebrite attacks. Seems like GrayKey can easily bypass that feature. Does not really inspire much trust in Apples security team as the USB restricted mode was already a bandaid itself.

[1] https://blog.elcomsoft.com/2019/09/usb-restricted-mode-in-io...

[londons_explore]

Apple's security team has been given the near impossible task of defending a physical device in the hands of an attacker.

I wouldn't blame them for any lack of success. Perhaps instead blame them for suggesting to the user physical security is possible at all.

[close04]

I think people don't fully realize the magnitude of such a task. We're not talking about something like consoles where the attack has to meet a higher bar to be viable (be persistent across reboots and upgrades, work over the internet against the provider's infrastructure, etc.). And as usual, the attacker only needs to get it right once and they can afford to wait for months or years to find the exploit on the particular device they have seized.

[Hamuko]

As far as I know, there is actually a pretty easy defense mechanism against this: strong alphanumeric password.

The hard part is trying to defend a physical device in the hands of an attacker while using a simple 6-digit passcode.

[Dylan16807]

It doesn't need to be perfect. The main requirement is that a chip holds on to a secret key, releases it upon getting the correct pin, has a limit on attempts, and is resilient to voltage and timing attacks. That's difficult but not exceptionally difficult.

Apple has chosen to run a ton of code inside the secure enclave, and bugs from that are on them.

[MiroF]

> has a limit on attempts

This is potentially a quite difficult problem IMO

[Dylan16807]

Is it? Have nonvolatile storage inside the chip, and increment+verify the attempt counter before checking if the supplied PIN is correct. What do you need beyond that?

[Jamwinner]

How do you know when to reset the counter? You dont want invalid attempts incrementing forever...there is your chink in the armor.

[Hackbraten]

What’s wrong with resetting the counter when unlocked successfully?

[Thorrez]

> the near impossible task of defending a physical device in the hands of an attacker.

If you assume the device is off and the user chose a strong password, it's pretty easy to defend. You simply encrypt the data with a key which is encrypted with the user's password.

If you want to protect devices that are on, or want to protect devices with less than stellar passwords, then it becomes harder.

[DagAgren]

That is not very strong protection - it lets you perform dictionary attacks at high speed.

It is often more secure to generate a random, high-entropy key and storing it in secure storage, which is what the iPhone does.

[Thorrez]

If you assume a strong password you don't need to worry about dictionary attacks.

There are 2 ways to slow down the attacks: key stretching and secure storage. Key stretching is a good idea.

I recommend not relying fully on secure storage, because I've heard of tons of hardware vulnerabilities (side channel attacks, undervoltage, electron microscopes, buggy implementation). I trust math more than a physical object. In fact it seems impossible to me to build fully secure storage, because if someone has a delicate enough measurement tool to measure the atoms inside the storage, the data inside can be extracted. If you store the password (or hashed password) as well as the key in the secure storage, and have it only return the key if the input password is correct, you run the risk of someone finding a bug in the storage to extract the key without the password. Then you're compromised.

But you build a system so that the secure storage is no worse than regular crypto. You do the encryption using a combination of the user's password and the output of the secure storage. That way even if the secure storage is fully compromised, the password is still needed.

[DagAgren]

You can't really assume a strong password, because if you have to type in 12 characters, letters and punctuation marks every time you want to look at your phone, you're going to give up on the whole thing pretty quickly.

To be usable, phones need to allow relatively weak passwords.

[Thorrez]

I've had a password like that on my (Android) phone for ~7 years and haven't given up. I don't use punctuation though, it's not worth the extra taps to get to the punctuation keyboard for the entropy you gain. I've never had fingerprint or face ID enabled either.

12 characters gives 62 bits of entropy. That's plenty if proper key strengthening is in place.

Linus Sebastian says that when his phone got slower to open up, he got happier, because it caused him to use his phone less, cutting out the useless stuff. https://youtu.be/WGZh-xP-q7A?t=305

[deadbunny]

> If you assume the device is off

When was the last time a regular person turned their phone off? Not counting reboots or out of battery incidents I'm going to guess not since it was purchased.

[afthonos]

“if you assume the device is off”?

I suppose if you assume the user never puts data on the device, it also becomes easier.

[sjy]

Do you really think it's impossible to "defend a physical device" – prevent an attacker from accessing and decrypting the data stored on it? I believe it is possible, that's the promise of hardware security modules. The article is about a mostly secure physical system that Apple undermines by encouraging the use of easily-cracked numeric PINs. I am not sure if the implementations are there yet, but biometric authentication looks like a promising solution to this problem.

[mcphage]

> biometric authentication looks like a promising solution to this problem

Yep, and if it gets hacked, then all you need to do is change your fingerprints.

[acdha]

You need to think about this a bit more: biometrics are bad if you pass them over the network where an attacker can replay them but it's different in a local context where they never leave the device. You get a high-entropy key and an attacker who can get both your device and a sufficiently high-quality biometric scan can also simply do things like like you in a room until you unlock the device. That seems like a reasonable compromise.

[ColanR]

> it's different in a local context where they never leave the device

Until the next round of FBI tools, where they extract the fingerprints to their database as part of their unlocking process.

[szc]

The handling of biometric data is designed to be secure between the sensors and the secure enclave. For example, data from the fingerprint sensor is encrypted when it is sent over the wires inside the device. The secure enclave does not store images of the fingerprint, but a representation of it which is not enough to reverse back into a fingerprint.

This is covered in the Apple Platform Security Guide.

https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app... (I believe this link can change when the guide gets updated)

[sjy]

I don’t think any of the existing exploits actually involve extracting keys from a hardware security module.

[acdha]

How do they extract fingerprints? All competent biometric implementations store hashes for exactly this reason.

[rem7]

Biometrics shouldn’t be trusted this way. Biometrics are closer to a username, not a password.

[seanhunter]

Apple specifically uses biometric authentication (faceID and their fingerprint thing) except when the device is first powered on. This is (at least partly) because of US legal rulings that allow LEOs to compel you to provide a fingerprint and similar biometric id but cannot compel you to provide a password.

[xtracto]

Directv won that war years ago.

[matthewmacleod]

I think it’s important to stress that we have essentially no solid information as to whether these attacks are real, and if they are, then the methods they use or the amount of time they take, nor what measures can be used against them.

Let’s not sing the requiem for their security team just yet.