[1] https://blog.elcomsoft.com/2019/09/usb-restricted-mode-in-io...
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.
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.
I suppose if you assume the user never puts data on the device, it also becomes easier.
It is often more secure to generate a random, high-entropy key and storing it in secure storage, which is what the iPhone does.
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.
To be usable, phones need to allow relatively weak passwords.
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
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.
Apple has chosen to run a ton of code inside the secure enclave, and bugs from that are on them.
This is potentially a quite difficult problem IMO
But if that does happen then the system of timeouts will prevent you from using up all the attempts.
None of that gets in the way of resetting the counter only when the user succeeds.
The only way would be to physically decap the chip which would most probably destroy it.
Yep, and if it gets hacked, then all you need to do is change your fingerprints.
Until the next round of FBI tools, where they extract the fingerprints to their database as part of their unlocking process.
If you do a little bit of reading about the topic, too, note how well-designed biometric systems require more than a simple fingerprint or photograph — e.g. Apple's FaceID has liveness checks for eye motion and uses a 3D scan. None of these are impossible for a well-resourced attacker but that's true of the alternatives as well. This is why you need to think in terms of threat models — e.g. the attacker who can get a high-resolution 3d scan of your face can also watch you type your passcode in so the latter isn't more secure in practice.
If an attacker watched you type in your passcode, what would you do about it?
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)
The hard part is trying to defend a physical device in the hands of an attacker while using a simple 6-digit passcode.
Let’s not sing the requiem for their security team just yet.