[alwa]

What do you imagine a solution here might look like? I don’t know enough about the problem space to truly know, but I feel like I’ve seen versions of this: I can authorize any arbitrary public key for use over SSH, for example; and (based on my memory of YubiOTP) it’s seemed like at least some of these hardware auth protocols work based on using an open serial number or public key to identify the authorized authenticator.

Intuitively it seems like it should be possible for me to store on my main auth device some form of the backup device’s identity or public key material, and at enrollment time, ask the authenticating service to trust either the current device or also this other device to authenticate me.

I wonder what risks I’m overlooking-surely there must be good reasons the protocol excludes that kind of approach.

[timwis]

Perhaps if you could register your hardware key using its public key, which could be saved on your device? So you don’t need the hardware keys to be physically present when registering; just when signing in later.

[tialaramex]

In FIDO a separate public+private key pair is minted for each (key,site) pairing. This has lots of important benefits, but one is that it preserves existing anonymity.

If I use a Security Key to sign into Facebook as "Melissa Smith" and use the same Security Key to sign into my GitHub account "acab420", even if Facebook and Microsoft work very hard they can't correlate the information they have to prove those are being authenticated with the same authenticator. The keys are different, as they would be if these were different authenticators.

You might think it's impossible for FIDO1 or in scenarios where it's "just" a second factor and isn't storing anything for the site on your key, but there's a really clever trick. The Relying Party (e.g. web site) is required to remember a large random-looking "ID" for your key. Those aren't really random - they're effectively your private key for that site, but encrypted using a symmetric key only your authenticator knows. It encrypted its own private key and just sent that, in plain text, knowing it's impossible to decrypt (typically AES-128 or similar) and when the ID is sent back, the authenticator just decrypts it. AEAD is used, so an authenticator can tell if this ID isn't one it made because the AEAD fails.

[timwis]

Thanks, that's a really helpful explanation.

[saltcured]

I wonder if the actual desire is to be able to buy a set of cloned keys. I.e. instead of having each key be unique, be able to buy a set of N keys with identical private key. Or the ability to create such a set yourself with a special initialization sequence. This would give you your high-availability backup, but means you cannot revoke the first key if lost. So it seems like you'd really have to trust the other hardware protections and PIN/lock features if misuse of a lost/stolen key is a concern.

Periodically, I try to think if there is some other expected UX you might want that is somehow neither cloned nor independent keys. Like some hybrid of secret-sharing and group key schemes. Have a set of N keys which know about each other and can act individually to authenticate for the same identities, including for new identities enrolled by any key in the group, as in the case of a cloned key. But, include some capability for k out of N keys to "vote out" a member from the group in order to revoke the lost key and prevent it from authenticating any of the identities in the future.

I am not a cryptologist, but I can't really imagine any crypto mechanism to actually produce this combination of effects. A fully distributed group registration and authentication effect during normal use, so enrollment via one key can be followed by authentication using another. But at the same time, allowing ejection a member from the group to prevent future misuse. I can only imagine this as a protocol, where every authentication for the group would have to consult some centralized ledger or revocation list for the group membership. It could be decentralized/federated in a sense, but would require some kind of online check with the "latest" ledger state for a given key group.