Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
Some vendors may also add "recovery" public keys to those synced keychains so that you can "Forget Password" your way out of a lost device or locked account or bootstrap new devices, and you have to trust your chosen vendor's security for how they manage that private key for any "recovery" keys.
But my impression is that there isn't anything that Passkeys is doing that you couldn't do by also collecting Yubikey public keys by hand and making your own keychains if you are sufficiently motivated.
I haven't seen anything in the FIDO alliance or vendor (Apple, Google, MS) documentation to suggest that they're cross-signed public keys - can you point to some that I may have missed?
The reason why I ask is on the face of it, it doesn't make sense to implement in this way: It would mean that each new device would have its own keypair per service and cross signed by at least one other trusted device. Which could be fine, but now each service needs to store n public key pairs (one per device) after validating that the new key has been signed by a known key.
Then, when a new device is added to the Keychain (in apple's case), that device needs to generate m new keypairs for m services, have them cross-signed and then proactively registered for each service.
It does make sense to implement it as the person you're replying to suggests, where a shared private key is shared over an authenticated, end-to-end encrypted process - with the corresponding weakness that if the authentication method for adding new devices to an existing Keychain is compromised, so are all passkeys.
Hence the question.
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...
