I've always hated that I couldn't clone or backup my personal yubikey. It's one of the reasons I've avoided using it everywhere.
It's inconvenient, sure, but it's more convenient than my bank accounts that are accessible online being cleaned out.
Password manager. Primary e-mail account. DNS provider.
Other than that, it's rarely supported and rarely worth the hassle when it is.
Banks are so slow with this sort of thing, and still require SMS as a fallback option.
you register at least two keys, and when one fails or is lost, you pull the emergency backup out of a safe and register new one(s).
The fraction of people willing to regularly schedule enroll-o-ramas at each of their accounts and each of their backup key locations is probably smaller than a percent of all potential WebAuthN users.
Yubico or really any other manufacturer could totally e.g. release "Yubikey pairs", both a stateless CTAP2 implementation with the same root secret, that would correspondingly work at the same sites without having to synchronize anything.
The reason they probably don't is that their entire trust model heavily depends on the perception that nobody, including the manufacturer, has a "reserve key" to any given Yubikey, even though of course the absence of such "linked keys" doesn't demonstrate the absence of any such backdoor.
To be clear, I don't have any reason to believe Yubico does this, but it would probably be a harder story to tell, marketing-wise, if they sometimes selectively did, even if it's for a valid use case.
(Or just allow the user to generate the root key outside of the device and insert it)
I honestly think the interest from customers is just too low. I would bet the majority of Yubico's customers are enterprises where this is not really an issue for most use cases. If you loose your key used for Entra ID / SSO, just go to IT support and get a new one enrolled to your account. Much cheaper than having synchronised hot spares (at 30-50 USD a pop) for thousands of employees.
(The second idea seems better assuming the user nukes the private key once the import is done. Otherwise the weakest link in the security chain will continue to be the opsec you practice with the private key file, in which case why spend the money on the Yubikey?)
The idea I thought of is to essentially use the public key of (2) to seed the generation of the root secret on (1). Meaning the sync-pairing-setup is destructive to the root secret, and can only be done at startup (or if you are willing to reset the device).
(A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)
You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.
I think the real issue here is that users probably don't expect having to reset/initialize a Yubikey once they take possession of it. Given the horror stories of how e.g. Amazon commingles inventory, I wouldn't be surprised if fraudsters could succeed in getting paired keys back into the supply chain.
Targeted attacks to friends/family can probably also not be ruled out ("hey, i got this spare yubikey in a black friday sale, want it?"), and unfortunately something like a family member or partner trying to take over somebody's accounts isn't unheard of.
There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.
[1] https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...
Ah I did not know that, thanks.
> There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.
Would be interesting to see the draft. But yes of course, there are tradeoffs. Having a LED similar to on the Bio to indicate it's paired could be one way, or selling pairs in a SKU where the user actually have to initialise them (with some clear physical difference to help solve the family/friends case). But it's complicated, and I think Yubico has made the correct decision that it's simply not worth it (not that it's impossible to do in a secure way).
However, the lack of a resonable backup solution is keeping me away from Yubikey for any non-enterprise use, where a broken key would actually lock me out of an account for real.
I just use multiple tokens, and I knew that the infineon sle78 was an intel 80251 derivative before this report ;)