Comment by gjsman-1000 | Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

Parent Full thread

Quote from Apple Platform Security > Hardware Security > Secure Enclave:

"Devices first released in Fall 2020 or later are equipped with a 2nd-generation Secure Storage Component. The 2nd-generation Secure Storage Component adds counter lockboxes. Each counter lockbox stores a 128-bit salt, a 128-bit passcode verifier, an 8-bit counter, and an 8-bit maximum attempt value. Access to the counter lockboxes is through an encrypted and authenticated protocol.

Counter lockboxes hold the entropy needed to unlock passcode-protected user data. To access the user data, the paired Secure Enclave must derive the correct passcode entropy value from the userʼs passcode and the Secure Enclaveʼs UID. The user’s passcode can’t be learned using unlock attempts sent from a source other than the paired Secure Enclave. If the passcode attempt limit is exceeded (for example, 10 attempts on iPhone), the passcode-protected data is erased completely by the Secure Storage Component."

https://support.apple.com/guide/security/secure-enclave-sec5...

I once had auto reset enabled on my phone after 10 attempts, and then somehow while it was in my gym bag it proceeded to accidentally get buttons pressed and reset itself. Better to set that number to 1000 instead of 10.

Nowadays the time between guesses increases exponentially. So by the time you are close to a reset, you need to wait a few hours or days before the next and final guess.

How's that even possible? AFAIK after the first few attempts there's an exponentially increasing lockout time between passcode attempts, so the random button pressings would have to persist for a long time for it to reach 10 attempts.

It wasn’t always like that, it used to be just 10 attempts you could do in a minute.

The exponential backoff existed in iOS 5, IIRC.

Or someone tried to access your phone while you were away

My mom had the same thing happen, suffice to say that she doesn't trust her iPod anymore.

I set mine to four attempts, figuring that if I screw my passcode up four times it takes me like an hour to restore the device state from backup/MDM but if someone thought they had guesses at my passcode they'd lose that much quicker. Everything I can't "live without" that I use my phone for day to day is in GSuite/Spotify/iCloud/1Password anyway.

(I now really pay attention when typing my passcode, which doesn't happen often because of Touch ID)

You don't use phone TOTP? Google Authenticator, etc.

Those, too, can be backed up, though for a while, at least on Android, Google Authenticator could not be (unless rooted, and even then, a nontrivial undertaking). This, AFAIK, has changed.

On iOS it could not be backed up or transferred to another device. I think it can now, but I moved to another app forever ago because of that.

I use Authy and 1Password for that.

You can also use saas pass as either or both as an authenticator and password manager.

Worked on the passwordless 2FA part of it

Surprised this wasn't implemented as whole filesystem encryption and then just overwriting the secret key in the SE instead of dealing with the time/battery cost of an incomplete wiping of "passcode-protected data."

When you design protocols like this, the big question is whether there is a bias in the salt and verifier keys that get installed in the SE at the time of manufacture. It's a good design as described in principle, assuming there is sufficient entropy in those 128-bit values, as we tend to assume the field size is what provides the security, but really, it's that there are this many sufficiently random bytes from that field that provides the assurance. If you have seen how crypto gets backdoored in practice, key length doesn't matter if the RNG is hobbled in a deniable way.

Personally and armchairing it, if I were solving this problem I would work more on brute forcing collisions in sensor/image sampling human fingerprints than bothering with crypto and side channels. But in terms of the real threat model, it makes more sense to approach it from the perspective of what the whole product truly is and what it provides.

From a product perspective, designing iPhone security is such an interesting problem because the whole brand image is predicated on being the best available, so you can't do an "oops, sorry" like an inferior product. You can only do what you know you can do better than anyone else. The real threat model is the brand damage from a company like Cellebrite or NSO getting caught or leaked about.

Oddly, the north star for a product like that is probably the U.S. 4th and 5th Amendments, as from a security feature perspective, you can always evaluate whether a design is aligned to those as the sufficient and necessary criteria.

>Surprised this wasn't implemented as whole filesystem encryption and then just overwriting the secret key in the SE instead of dealing with the time/battery cost of an incomplete wiping of "passcode-protected data."

It is; it zeroizes the KEK. Nothing is slowly wiped from end to end.

> key length doesn't matter if the RNG is hobbled in a deniable way

An interesting thought: Consider how valuable target Apple's RNG is, the design, the code, and the devices themselves. Reduce entropy, in a way that only you know, and you have an enormous advantage.

> the whole brand image is predicated on being the best available, so you can't do an "oops, sorry" like an inferior product

It's also possibly an effective way to manage engineers: Set a strong, public standard, and they know there is no avoiding it.

Reply on news.ycombinator.com