I look forward to hardware tokens reaching a popularity level where we see implementations in software and this conversation can be rendered moot.
Shout out to Mozilla and Dan Stiner for their work so far.
(I don't even want to think about how to tell Mobile Safari on my iPhone how to find my key)
EDIT: My ideal setup, I think, is an app on my phone that I can use as my token - somehow signaling to my desktop/laptop that it's nearby and can be used as a token and ideally popping up a notice on the phone lock screen when there's an authentication request so I can quickly get to it. Then in my app, I'm free to export and backup my keys for all of the sites I'm enrolled with as I see fit. I know, I know, maybe being able to export the keys makes the setup less secure, but I will trust myself not to accidentally give the backup to a phishing site. (And I do worry that I'll accidentally get phished using a TOTP app, so I'd like to switch to FIDO, but I don't want the pain of multiple keys)
If you don't trust your hardware, it's almost always game over. Desktops have devices running dubious firwmare as well, but at least with a hardware key store, the window of compromise ends at the time you update – a stolen key stays stolen forever.
That's not to say that you should trust modern smartphones. That's up to you. It's just that in whatever "trust" means to you, the baseband urban legend shouldn't come into the equation.
If there are vulnerabilities on the AP (main processor) then you can hack it from the baseband, but also from the bluetooth or WiFi chips.
Caveat emptor on cheaper/older phones or ones you enabled developer modes on.
Yes, either the Browser or the OS will need to be involved. For example, for Webauthn on Chrome on Windows: chrome receives the request, then it calls the Windows Hello APIs. Then, that Windows Hello API shows a popup to read a physical security key or authenticate a virtual security key via face/PIN (this is protected by a TPM, but it's "virtual" since Windows generates it via the TPM but stores it encrypted on-disk).
To support a syncing fido keyvault, Chrome could very well redirect the calls to its own popup for choosing to 'use Chrome', or 'use another key', which would then call the Windows Hello API. In fact, Chrome already supports this[0], with 'Add a new Android phone' is simply how they're presenting Webauthn over BLE, and it works with iOS when passkeys are enabled in the iOS developer menu[1].
0: https://i.judge.sh/Qq93C/v_GG5R7LyM.png
1: https://developer.apple.com/documentation/authenticationserv...
This is already supported by many browsers (unfortunately Mozilla/Firefox are dragging their feet on this one [1]) and gives you exactly the user experience you want.
In a compliant implementation, you can add a new external authenticator from an existing trusted device, and a new trusted device from an existing external authenticator.
> while also adding to privacy concerns.
What concerns are you thinking about here?
> TPMs are essentially a misfeature given the existence of smartcards and hardware keys.
TPMs are essentially built-in smartcards (with a few other optional features like measurements/attestation, but these have never really taken off as far as I know, other than giving TPMs the reputation they have) and are very well suited for use as platform authenticators.
You can kinda sorta do this with WebAuthn if the service you're enrolling into allows for multiple authenticators (the spec recommends this, but some services don't allow more than one). But then you have to repeat that enrollment step with all devices, for every new service you sign up to. Which is practically useless because an actual backup is supposed to be stored in a safe place that might be hard to get to.
> TPMs are essentially built-in smartcards
The question is why anyone sensible would want to have a smartcard built into their computing device. The only uses I can think for it are nefarious, i.e. allowing outside services to track the user and violate their privacy.
> The only uses I can think for it are nefarious, i.e. allowing outside services to track the user and violate their privacy.
A smartcard would be one of the worst or at least most complicated ways to implement tracking: It can communicate with the rest of the system only through an extremely limited interface and can strictly only ever answer requests sent by the host, never initiate requests on its own.
To do anything nefarious, it would need a privileged companion service on your computer – which doesn't gain anything from being able to talk to the smartcard.
As an aside: Even TPMs are an extremely passive technology. The only thing that arguably makes them "evil" is the fact that they can perform measurements for device attestation, but it can still never transmit these on its own. That evil is pretty indirect, in that some service providers might only allow users to use TPM-enabled and sufficiently attested clients to access their services, and exclude open hardware and software.
That's coincidentally exactly what DRM is, and it's already here, and not at all limited to TPMs. I'm cautiously optimistic though that it's possible to strike a compromise and limit attestation to properly sandboxed parts of the system, e.g. only the parts of the GPU relevant to display copyrighted movies, without getting undue access to the rest of the system.
The smartcard part of TPMs is about as capable of evil (as far as your computer and your data on it is concerned) as a USB-connected mug warmer.
You can use the "smartcard part" of a TPM. This gives you secure/non-extractable key storage.
You can use the attestation/trusted computing part of a TPM. This gives you trusted computing, which can be used for DRM, if you install software or use a service using DRM and grant it access to your system. If you don't like that, just don't do that. (Today's DRM solutions don't even use TPMs anymore, for what it's worth.)
If you want/need neither, just use neither!
The only think that kept DRM from leveraging it was indeed the low usage in consumer spaces.
> Your privacy is important to us.
Privacy statement of the group and I think it is a straight lie. This is a major if not the major security concern. TPM didn't address the problem and therefore isn't a too popular guest.
I wrote that U2F implementation in software because I wanted phishing protection without needing to carry a hardware key. Well, and to learn Rust :) It's certainly a security trade-off to just store secrets in your keychain like I choose to, it is not meant to be a replacement for a hardware key and in fact I have a Yubikey I use when the situation calls for it.
I'd love to use TPM and biometrics to implement U2F/WebAuthn on Linux and have a proper, secure solution. Similar to what Apple has done with Touch ID. But that's no easy task. TPM support is poor on Linux and other options like relaying auth requests to your phone for approval and storing secrets in the Secure Enclave is no easier.
Like the acquired/abandoned https://github.com/kryptco/kr [key stored in a [...] mobile app] with iOS and Android apps all under an "All Rights Reserved"-source license?
Also, newer Macs have a Secure Enclave (supports 256-bit secp256r1 ECC keys):
https://github.com/maxgoedjen/secretive [storing and managing SSH keys in the Secure Enclave [...] or a Smart Card (such as a YubiKey)]
https://github.com/sekey/sekey [Use Touch ID / Secure Enclave for SSH Authentication!]
And yep Apple is way ahead on this imo, the touch sensor securely communicates with the Secure Enclave, I'm not aware of other laptop hardware doing that. (https://support.apple.com/en-bh/guide/security/sec067eb0c9e/...)
I'd love to have something equivalent for Linux, but given that requires hardware support I think relaying auth requests to your phone is the closest equivalent.
As far as I understand, "real" HSMs (i.e. the expensive, rack sized type of security key) sometimes offer the ability to export their root key to other models by the same manufacturer using a specific ceremony.
Arguably this also significantly weakens the security of the keys protected in the HSM, but at least it does not automatically expose it to software.
This only needs to be done once. For example by booting an old computer with no wifi capabilities and no hard disk from a Linux Live CD.
> You'll need to generate the key on a less secure host to do that, though, which partially defeats the purpose of a hardware key in the first place.
I kinda disagree with that. I generated my key by throwing physical dice. No random number generator to trust here. I only needed an offline/airgapped computer to compute the checksum and that program cannot lie: I know the first 256 bits out of the 264 bits so the program computing the checksum cannot lie to me, it's only giving me 8 bits of checksum.
Then I only need to trust the specs, not the HSM vendor.
Now, sure, my old Pentium III without any hard disk and without any WiFi, without any physical ethernet port, may be somehow compromised and exfiltrate data through its fans or PSU or something but what are the odds here? Especially: what are the odds compared to the odds of having a rogue HSM vendor selling you U2F keys for which it fully knows the secret?
I'd argue this requires less trust than the trust required in buying a pre-initialized HSM device.
By doing that, you are increasing your trusted code base by several orders of magnitudes doing that. This might be fine for your purposes, but in a corporate environment, it might very much not be.
> Then I only need to trust the specs, not the HSM vendor.
You do trust the HSM (vendor) no matter how you use it. Ironically, the more modern a cryptographic protocol is, the more opportunity for surreptitious key exfiltration there is. This could be in the form of predictable (using a shared secret) initialization vectors, wrapped keys and much more.
You also trust an HSM to be more tamper-resistant and/or more hardened against logical attacks than a regular computer, or there would not really be a point in using one in the first place.
It is enough to have a means to wipe out any information contained in the device, including any master secret.
At that point, there should be a means to enter a new master secret in the blank device, before proceeding to use it normally.
If a device provides this feature and it does not contain any other secret information introduced in it by the manufacturer, then it allows the owner to have any kind of backup that is desired.
I am also one of those who would never use a security device that contains any kind of secret information that is not under my control.
Precisely. The Ledger Nano S (and probably the Nano X too) allows to do exactly what you describe, the very way you describe it (three wrong PINs, on purpose or not, and the device resets itself to factory default and, as you wrote, at that point it's unusable until you enter again a master secret (either your old one or a new one: the device has no way to know and doesn't care).
https://osxdaily.com/2021/05/27/set-iphone-erase-automatical...
It is not a device useful to have for an individual user. On the other hand, hardware password managers are useful for individual users.
You're getting it backwards though. You are right that the whole point of an HSM is to not leak secrets when connected to a compromised computer. However there's nothing wrong with a HSM device that can be initialized with a "seed" of your liking, as long as that initialization step is done in a fully offline / airgapped way.
Ledger (whose CEO was, before creating Ledger), one of the member of the team working on the FIDO specs, make a "hardware wallet" for cryptocurrencies that can run a FIDO app. And it's totally possible to initialize the seed of your liking for your U2F device.
Now I did test this a while ago (out of curiosity) and it all working but I'm not really using it atm: I don't know where it's at regarding the latest FIDO2 specs.
But the point is: what GP asked for can totally be done.
I understand some may want to move the goalpost and say: "ok but then the problem now is not losing your piece of paper where you wrote that seed". But that is another topic altogether that does change nothing to the fact that you can have an HSM used for U2F that can be backed up.
Seriously, though, paper is better for most people that managing device cloning or the like. Most people can have a notebook in their house as a backup-of-last resort. Asking folks to become HSM managers seems unlikely to lead to better outcomes.
You mean their CTO aka btchip, right? Current CEO is non-techie and was not directly part of founding team.
Why would you need that ? On most services that I use that support FIDO, you can register as many keys as you like.
Seems to me that is a much more secure option than to provide a potentially exploitable option of allowing key extraction.
This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.
As stated, you can have as many backup keys as you like.
Thus you are not limited to two keys.
Buy one more key. Keep one off-site and two on-prem. Rotate them once in a while to keep the off-site one fresh.
That does not solve anything unless the backup keys are enrolled to each and every one of the services you use. Adding more backup keys and storing them more and more securely just makes it harder to be sure that you've enrolled them all to the latest service.
This is not an issue if users are explicitly allowed to enroll "virtual" soft authenticators that they can back up and restore as they see fit, but that's an additional requirement that comes at some compromise, since some services might instead want to ensure that you're enrolling a non-cloneable credential. (E.g. your physical bank or non-remote employer, that can easily verify your identity via additional means if needed to restore your access.) The WebAuthn spec allows for both models.
That said, the real answer is that FIDO keys can be synced by e.g. Apple (as described in more detail here: https://www.wired.com/story/fido-alliance-ios-android-passwo...). So you can potentially just make your offsite backup be a hardware key that gets you into your iCloud keychain, and (if you are willing to trust Apple) use your iCloud for backing up all your other accounts' keys.
Now go enroll 100 sites in it and then lose or destroy the device.
Enter the 24 word backup to a new device and access to your 100 sites is restored.
Also, you could make FIDO keys that support restoring but not backing up. If you could set up a FIDO with custom random seed _as an expert option_, then you could have a secure key, and keeping the seed private would be your expert problem.
I would adopt such a solution, whereas now I don't adopt the proposed solution because I cannot add a new service while having the backup key remaining off-site.
Maybe another solution would be to be to have _absolutely all_ services accept several keys (enforced by protocol), in addition to be able to accept adding an off-site key with only its fingerprint, but without requiring to have it physically.
The result of a WebAuthN challenge procedure is almost always a session cookie (TLS channel binding if you're really fancy), so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y", which arguably does not add that much value.
That is exactly why you want it.
Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects.
Without an unforgeable indication on the authenticator to show what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where.
A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.
It's a different story if the operation you are confirming with a security key actually can be rendered on the display, e.g. "pay $100 to someshop.com" (as in SPC [1]). In that scenario, there is actually nothing to steal except for the signed message itself, which would be useless to anybody that's not someshop.com, but given that WebAuthN almost always just yields a session cookie, I don't really see the benefit.
Sure, but you might never log in to your bank from this particular computer precisely because you don't trust it. But you think it's fine to log in to your hobby account since that doesn't store anything you really consider important.
If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.
> If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.
True, a permanently plugged in authenticator is largely equivalent to just using a password manager (which also prevents against skimming, if used exclusively via autofill, never via copy/paste), but unlike a password mananger, it makes unsafe actions explicitly impossible for non-sophisticated users. I'd consider this a strong advantage.
It also survives OS reinstalls, ransomware etc.
Being able to export/back up/restore master secrets would be nice too.
Edit: there seems to have been a paper that studied the very question of "can you create keys asynchronously so that you can later use them with a backup key": https://eprint.iacr.org/2020/1004.pdf https://www.youtube.com/watch?v=urJ2DhpLAEk
I need to read the paper however on how feasible an implementation of this is, and how much buy-in it needs from website and browser vendors.
One of the things FIDO adds beyond a protocol for "plain" hardware-generated and stored keys is the idea of attestation, i.e. authenticators being able to express statements like "keys can never leave this authenticator" or "this key requires PIN or fingerprint verification" – all assuming you do trust the manufacturer.
Attestation probably isn't the correct choice for almost anybody, but the cases where it could at least make sense are if you're an employer checking employee authenticators, if you gave everybody a Yubico Fantastic XXV authenticator, you might decide it makes sense to verify the credentials enrolled are from Yubico Fantastic XXV authenticators. But still probably not. On the whole, everywhere I see UIs for managing attestation it makes me a little bit sad, because it's an attractive nuisance. Azure AD for example does this.
But for sensitive systems/services, why not make use of the advanced capabilities that hardware authenticators offer? I'm using one in a corporate environment, and in my view it makes a lot of sense.
I'd also not be upset if my bank would let me bypass the mandatory "account restricted, call customer support" dance every time I initiate a transfer over $10 between my own accounts using only a "trusted" authenticator brand... And banks typically care a lot about security properties like "this authenticator does not allow extracting private keys".
Now, I want you to imagine if corporate has to approve motor vehicles for the HQ's 600 vehicle car park. Of course the CEO's BMW M5 daily driver is approved, and for the first week maybe the random cars owned by people who regularly use that car park get whitelisted pretty easily. By the next month though, one of two things, either you're told just buy the same exact model of car as the CEO to "save trouble" or everybody just tells you to use a different car park nearby, and the HQ real carpark sits mostly empty because approval is a hassle.
The right answer, you can see, is to just not have a rule whitelisting cars at all. It's a bad rule.
If all you want to ask for is "Use a second factor" then you can do that, there's a flag in WebAuthn, and the resulting signatures have the UV bit flag set (all WebAuthn signatures have UP set, but Presence of users is distinct from Verification of users). Because it's a signed flag, even though it's a single bit, you can rely upon it unless you don't trust the device you enrolled. But, again, why? What is your threat model where your users do deliberately enrol untrustworthy devices but presumably never just helpfully enrol a device for a crook ?
There likely is a hardware key that supports export and import of keys (even if that winds up being a fork of say the Solo key firmware). However, as an end-user one doesn't want to accidentally forget to export keys for a while, nor do they want to worry about how to properly secure a backup. So, you likely would want additional infrastructure such as vendor software which would do this for you on a schedule.
There are interesting models which could work here, such as a factory-paired 'set' of keys being sold in the same package, where only the second key (the one you kept in your fire safe) has the necessary keys to decrypt and load such a backup.
The question is whether a security manufacturer would be interested in this, as the presence of such a mechanism may prevent them from getting certain security certifications and being able to sell/be used in certain markets and scenarios.
Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state.
Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.
https://github.com/herrjemand/awesome-webauthn#software-auth...
There was mention of a secure backup proposal, but it doesn't appear to have been touched after being a draft for a year:
For users with a greater threat model (worry about enclave being hacked), they can use physical FIDO keys.
Apple, Google and Microsoft all have native API variants of the Web Authentication API. These typically use entitlements requiring authorization back to a website. This means e.g. a Twitter application could leverage the same authenticator registrations as twitter.com, leveraging both platform and roaming security keys.
>... and should work with my logging into my laptop in the browser and leveraging my phone as a FIDO "key".
The press release details this commitment; for instance, I can use an Android phone to log into a website on my Mac. An example of such an option should be visible on all shipping desktop Chrome browsers if you do a Web Authentication registration or authentication request (I believe unfortunately currently titled something like 'Add an Android phone'). On the Apple side, being able to leverage this is currently sitting behind a developer feature toggle.
One can hope that this will be extended to say the Windows platform itself - at that time, I would expect be able to use my iPhone or Android phone to log into any Windows machine on an AAD-backed domain.
Pixel 6 supports this (Titan Security Key built-in) , but only works with Google accounts I think. I hope more phones support this.
One bonus feature does need the Google account. If you're signing into say banana.example with WebAuthn, using Chrome on a PC, and Chrome can't see any FIDO authenticators plugged in, it will try your phone! It asks Google, hey, does this user have a phone (Chrome is signed in to your Google account) ? Google says yeah, they have "amf12's Pixel 6". The Chrome browser uses Bluetooth on the PC to say "Hey, amf12's Pixel 6 are you out there? Can you do WebAuthn?" if your phone hears the Bluetooth message it's like "Hi, amf12's Pixel 6 here. Standing ready to do WebAuthn" and then via the Google servers it's arranged that your login attempt on Chrome, on the PC, is proxied to the phone, where it appears on screen ("Do you want to log in to banana.example as amf12?") and you can OK that from the phone. Nice work flow actually, although the technology is remarkably complicated.
Yup there are for sure, for I tried it and it works. Now: I tried it out of curiosity and I'm not actually using it atm, so I don't where it's at but...
I tried on Ledger hardware wallets (stuff meant for cryptocurrencies, but I tried them precisely for the U2F app): initialize the device with a seed of my own and then register to FIDO2/U2F/webauthn sites. Worked fine.
Took a second hardware wallet, initialized it with the exact same seed: boom, it's working fine and I could login using that 2nd HSM device as the 2FA.
Note that as soon as I used the 2nd device, the first one wasn't working anymore: if I wanted it to work again, I'd need to reinstall the U2F app on the HSM device (the way the device work is it only accepts apps that are signed, and that is enforced by the HSM itself: the HSM has the public key of the Ledger company so it can only install "apps", like the U2F app, that is actually signed by Ledger... I'm not saying that's 100% foolproof, but it's not exactly the most hackable thing on earth either).
The reason you cannot use both devices at once is because of how an increment number is used: it has to be monotonicaly increasing and when the app is installed on the HSM, it uses the current time to initialize its counter.
I haven't checked these lately: I know the specs evolved and I know Ledger said they were coming with a new U2F app but I didn't follow the latest developments.
Still: I 100% confirm you that it's not only doable but it's actually been done.
EDIT: you basically save a 256 master seed as a list of 24 words (out of a fixed dictionary of precisely 2048 words, so 11 bits of entropy per number). 264 bits altogether: last word contains 3 bits par of the seed and 8 bits of checksum.
Trivial to write down. Very little chance of miswriting it for: a) you must prove to the HSM you wrote your seed down correctly and b) the dictionary is known and hardly any word can be mistaken for another.
And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate another(and even decide whether this new device can auth yet another or not). (Like the way google use: popup on user phone, and ask if user would like to let the computer login.)
I think the one we actually need is a common protocol to authenticate new fido device from existing one. Although you can do it currently, every website have different flow to do it. And there is not currently a common way here. A common and machine understandable way to auth new device from existing one may ease the pain.
In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side.
Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not on websites, but that's a different story.)
The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.
True, that was my concern with the new specification as well. But I believe the main problem will be account takeovers, not malware.
> Because if you can export or sync the key, then malware probably also can if your device is compromised.
Not necessarily. There are ways to still keep these keys only in secure hardware while allowing synchronization if the secure hardware supports service-provider mediated attestation.
HSMs usually support a similar process, where keys can be copied to a different HSM by the same vendor, preserving all of their usage and authentication restrictions (i.e. only the same set of authenticated and authorized users are able to use them).
This conceptually works by e.g. a new and old device, or a service-provider side HSM-secured backup and a new device, establishing a secured channel, attesting their state to each other and then copying the credentials over that secured channel.
By necessity, this includes the service provider (or at least their HSM code) as a trusted party: They are the one that ultimately gets to decide which new devices get added to the synchronization set, and under what circumstances (running a recent hardware and software version, multifactor authentication, providing a high or low entropy shared secret).
Of course, all of this also vastly increases the trusted computing base, and this might well not be appropriate for high security organizational environments.
Beware that if you do this and lose your primary key, or if it is stolen, then an attacker can impersonate you. Setting up multiple unique keys is probably more useful in general, even if it's more cumbersome.
If you lose your main key, you can resort to that one to re-gain access.
Keys that allow backing up the secret material are tricky, since they could potentially be cloned and someone would have a backdoor with you being unable to know of it.
You can use this seed by hand or on a duplicate device to deterministically recreate all keys be they webauthn, pgp, bitcoin, or otherwise.
Why isn't my identity just a Merkle root? I don't understand the need to register individual keys.
I think Yubico will actually do something like this for large enough customers, though revocation is left as an exercise for the customer. When I worked for AWS, I was issued a couple company YubiKeys, and there was a web portal where I could revoke a token's association with my account.
The FIDO/WebAuthN model does by design not include a stateful/centralized authority that could maintain the required state for any such solution.
That's basically what I'm getting at. Do I need to do significant amounts of extra work to keep an off-site backup in another state?
Then go get it every time you sign up for a new account so you can make it the backup for that account
then go store it again.
and again. and again. and again.
oh no! you lost your key! time to go to the bank to get your backup, sign in to all the accounts, remove the old key, register a new backup, oh wait, got to wait for the new backup to ship, so i guess you can't do that yet. hope you don't lose your key in the meantime, anywho, time to spend a few hours painstakingly removing your lost key from all the 9 thousand sites you use.
yay! its a week to a month later, you finally got your new yubikey shipped, time to go log into to 9 thousand websites again to set it up as the backup for all of the sites.
Ok, time to take it down to the bank.
whats this? a cool new app my friend wants to show me, ok, time to go drive to the bank and get my backup key out of storage and sign up for this cool new app.
You know, this whole driving to the bank thing, its kinda inconvenient, maybe i should just store it in my closet safe.
What do you mean the gas line under my house exploded? but both my yubikeys are in there!
----
The above is fiction, and even under fiction it seems ridiculous how this would really go is even worse:
"Go get my backup key to use for this new app my friend showed me? fuck that"
. .
"What do you mean i can't reset my password, but i lost my yubikey!"
"No, i didn't want to get up to grab my backup token when i was registering."
"Oh wait! i bet i still have the recovery codes as a pdf in my downloads folder. its a good thing no viruses ever think to look in there"
----
More advanced FIDO devices like the Ledger allow you to backup the initial random seed allowing you to create a duplicate device from the backup any time you wish. No sites you signed up with will know or care that you swapped devices as the new device will generate identical keys via a deterministic KDF from the seed.
You can put this seed far away and would only ever need it when you wish to replace a lost or broken authentication device.
Aside: no US major banks issue safety deposit boxes anymore other than wells fargo which will stop issuing them soon as well.
1) I don't keep all of my keys on my person, so if I want to sign up for a service when I'm not at home, I have to remember to go back and add my other keys at a later time. If I wanted to, for example, keep a backup key in an offsite location such as a safe deposit box, this would be even more painful.
2) If I lose a key, I need to go and change every service to deactivate the lost key and add my replacement key. This is both time-consuming and error-prone, as it requires me to keep a full list of providers that I use keys with somewhere.
3) Some providers do not even allow you to register multiple keys.
1. You register both the primary and the backup key with every identity provider (ie GitHub)
2. You only carry the primary key with you at all times. You keep the backup key in a physically safe space (ie next to your birth certificate).
3. In case the primary key gets lost, you make the backup key your new primary key. You can log in with it everywhere because you already registered it in step 1.
4. You order a new key which will become your new backup key.
5. Go to step 1.
Decrypt/Extract NitroKey HSM RSA Private Keys