[petedoyle]

This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2]

Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)?

I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case??

    [1] "From the user's point of view, this means that when using 
    a passkey for the first time on the new device, they will 
    be asked for an existing device's screen lock in order to 
    restore the end-to-end encryption keys"

[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...

[2] https://www.omnicalculator.com/other/password-entropy?c=SGD&...

[sebk]

Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available.

The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering.

There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540

[petedoyle]

Thank you! I'm trying to understand more deeply, so I appreciate it. :)

> This approach works because the secure enclave provides measures against bruteforcing and tampering.

That's interesting!

> because that implies off-device use of the PIN, so those measures are lost

This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...

Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.

From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)

[015a]

Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher. The question shouldn't really surround the effective entropy of the PIN, but rather the systems in-place to protect bypassing safeguards in the key derivation function which render the actual entropy of the PIN irrelevant. There probably isn't no way around that safeguard, but as more of this gets moved into trusted compute silicon the level of sophistication required to breach it goes up; and is one hardware revision or operating system update away from being made moot again.

This thread really smells like https://xkcd.com/538/. Three things you have to remember, that are far more important than any of the concerns you have:

1) The effective entropy of the current system (passwords) is "shrugs shoulders fuck it not our problem". Services can enforce password entropy requirements. They cannot effectually require users to use a unique password. They also cannot forbid users from writing the password they use in a .txt file on their desktop or post-it note or throwing it in Apple Notes (EVERYONE does this outside of our bubble. Apple Notes and Excel are the #1 and #2 password managers on the planet). A six digit pin + hardware TPM key derivation is, at best, the same thing that was guarding how most people store their passwords anyway, and in many cases far better than the current state (if a user's device has no E2EE, or if they're syncing their passwords.xlsx file with Dropbox, etc).

2) Passkeys do not and are not designed to protect against nation-state level attackers. Passwords weren't either. They also don't protect well against the "grab a hammer and beat it out of him" threat vector; you're going to give up your password, and tomorrow they'll probably have your iPhone and your passkeys will be disclosed as well. Passkeys are designed to protect against unsophisticated (and even moderately sophisticated) attackers; phishing, data breaches, etc.

3) If you want higher tiers of entropy guarding your passkeys, you can do that. 1Password, as an example, already has this [1]. They store passkeys, and encrypt those passkeys with their two-level account & master password keys. Done! If you don't like 1Password, you can roll your own, and I'm sure OSS password managers like gopass/keepass/etc will eventually add this. Passkeys/WebAuthn don't prescribe to anyone how you store the private keys; Apple will do their thing, Google will do their thing, you don't have to use them, many people will, and they'll be better off (see point 1).

[1] https://future.1password.com

[petedoyle]

> Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher.

Thank you. 100% agree.

> Passkeys do not and are not designed to protect against nation-state level attackers

I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.