| From my understanding, it's complicated to find a way to say it never does a certain thing because Passkeys technically checks the "All of the Above" box and does a little bit of everything PKI can do, because it is explicitly multi-strategy for redundancy/resiliency/speed/ease-of-use reasons. I hedge some about my understanding of the current WebAuthn/FIDO/Passkey standards as my view of the Passkey model is still somewhat filtered through my old understanding of Keybase's "sigchain" model when they moved to device-based keys: https://book.keybase.io/docs/server#meet-your-sigchain-and-e... So far as I'm aware, Passkeys doesn't deviate too much from how Keybase had been built post per-device keys [1], albeit with more OS/platform support and fewer blockchain/cryptocurrency distractions/acquihire-risks. There are a hierarchy of keys (and yes it is generally always N keys involved and a complex keychain; websites may not see the whole keychains, though) with the most trusted being the keys that are non-exportable and therefore hardware device-specific. (Those keys get additional "attestations" attached specifying those extra trust characteristics.) Every one of a user's devices would generally learn and cross-sign each others public keys to recognize each other. There's a definite N key relationship between them. Device keys are then used to bootstrap more keys. Each subkey is more ephemeral (shorter expiration date) and less "trusted" than the last. These subkeys may be website-specific. These subkeys may or may not be shared between devices. When shared between devices it may be peer-to-peer, device-to-specific-other-device, end-to-end encrypted with device-specific keys. When shared between devices it may not even be in the form of a key but a shared "pepper" (relative of a hash "salt") to be mixed with website-specific call/response into a key-derivation function (KDF) of some sort. The keys may not be shared at all and instead a CA-like approach is used that if the subkey is signed by a known device key it is accepted. The keys may not be shared at all and instead data to be signed is sent encrypted to a specific device (a roaming phone, for instance) and that device signs it with a hardware key then encrypts that for the requesting device's ears only and passes it back over close-proximity-only Bluetooth LTE. Or nearly that same thing, but data being signed is a temporary key from the originating device. Additionally, vendors may add their own keys to the keychain for easier "recovery" in "Forgot Password" situations. Many of these keys might be subkeys of some cloud-based HSM and shared in similar ways (directly to specific devices after handshaking on device-specific, unexportable keys; KDF-built using a combination of "pepper" secrets known to the user and known to the cloud provider; some other thing). All of this is highly implementation specific which specific strategies are in play in any given interaction. It will likely also be highly vendor specific which ones they prefer. It is also somewhat website specific: websites are allowed to suggest they are "important like a bank" and will only accept the most highly attested keys (the non-exportable, device-specific kind). Websites might only want one-or-two degrees maximum distance from a highly attested key. I believe in rare situations websites might request as much of the signature graph as they can. The whitepaper [2] shows the two "new" WebAuthn Level 3 "use cases": lots of device keys sharing some more ephemeral keys. Lots of devices referring to a single other device for keys. Passkeys uses both/either as needed. To properly support Passkeys doing ephemeral key tricks, websites do need to store N keys per user, but that's always been a soft-requirement for good WebAuthn support. (In the case of secure FIDO tokens well before Passkeys, there's no recovery path without N key support.) In general, a User's "passkey" is most likely never represented by only a single shared private key, it's an aggregate hierarchy of keys from non-exportable device keys to temporary keys shared between devices to ephemeral keys made of "salt and pepper" and everything in between. Lots and lots of keys that generally know/trust each-other is much easier to secure than one-key-to-rule-them-all. There may even be as many as N * M keys in cases where every website has a different key for every user device. Long story short: "[they] don't sync private keys, they sync and cross-sign public keys" is subtly wrong short-hand because they may sync all kinds of temporary/ephemeral private keys and/or private data device-to-device. But even given ephemeral private keys it still feels more to me, and my understanding/my ability to elucidate my understanding, like describing that as cross-signing public keys as the "simple, short answer" rather than list all of the surprisingly many and complex ways they might be created and/or shared. [1] https://book.keybase.io/docs/server#meet-your-sigchain-and-e... [2] https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... |