[spencerflem]

Last I heard, they were pushing hard for resident keys only, maybe that's changed. I don't like that there's still the option to restrict it to that in the same way having the option to force remote attestation makes me uneasy.

[timmyc123]

A passkey is a discoverable credential (aka resident key) in spec terminology. But the type of credential has no relationship to attestation (which is not used in the consumer passkey ecosystem).

[spencerflem]

Ah my bad, I thought the distinction was resident = stored on a YubiKey/Secure Enclave/TPM and that was what made them resident.

To my credit I think yubikey uses the term that way and webauthn has a different definition but in the context of passkeys you’re right.

[jmsgwd]

Just to point out, protecting a key using the secure enclave and syncing it using end-to-end encryption aren’t necessarily mutually exclusive.

The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).

That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.

[spencerflem]

Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.

How do the decryption keys for the encrypted passkeys get shared between devices?

[jmsgwd]

>Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.

I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.

Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)

By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.

Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.

> How do the decryption keys for the encrypted passkeys get shared between devices?

They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).

In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.

[timmyc123]

> stored on a YubiKey/Secure Enclave/TPM and that was what made them resident.

Stored in an authenticator/credential manager in general, not specific to a security key, secure enclave, or TPM.