1

I've had this idea bouncing around in my head for a while, and I'm honestly surprised that it doesn't seem to be on the market. Which probably means that it wouldn't work well for some reason that hasn't occurred to me yet.

I think it should be possible to buy hardware security tokens (Yubikey etc.) in pairs, with each pair intentionally manufactured to share a secret. That way you could seamlessly switch back and forth between them. This would make the "main key/backup key" pattern much more usable, because you wouldn't have to manually enroll both keys in every account where you want to use 2FA.

Currently this requirement makes it impractical to truly treat your backup key as a backup. It works well enough if you lose/break your primary key, but isn't helpful if your house gets burned down/flooded/whatever, because it's simply impractical to store both keys anywhere other than your home. Moreover, having to enroll two security keys for every account is pretty inconvenient, and as we all know, "security at the expense of usability often comes at the expense of security."

One downside is that this would effectively double the cost of the token, because as soon as one of your paired keys is broken/lost you have to ditch the other one and get a new pair. However, nothing says this has to be the only way in which security keys are sold, and I for one would be happy to pay the extra $40 or whatever a Yubikey costs for the extra convenience/peace of mind. Not to mention, the manufacturer could increase their per-customer sales, which seems like it would be good for them.

However, it doesn't seem possible to buy pre-paired keys like this. Why not?

Joseph Montanaro
  • 510
  • 2
  • 8
  • Can this problem be solved using Debian's master key / sub key model? The master key is registered with the service, then any of the sub keys can be used to authenticate; and later, master keys can be used to revoke sub keys. See https://wiki.debian.org/Subkeys and https://wiki.debian.org/OfflineMasterKey – mti2935 Jan 18 '21 at 18:18
  • Kind of like [keyed-alike](https://www.google.com/search?q=keyed-alike) locks, but not so insecure, as long as the keys are in pairs and not sets. I'll bet nobody at Yubikey thought of it, is all. – gowenfawr Jan 18 '21 at 18:49
  • @mti2935 that's an interesting idea, reminds me of the "deterministic wallets" used by some cryptocurrencies where a single master key can generate many public addresses which are not externally associable. One problem with doing that here though is that the key is specified when the device is manufactured, meaning that if you want a new key that works with your master key it would have to be manufactured on-demand. I imagine that would drive the price up quite significantly. – Joseph Montanaro Jan 18 '21 at 19:02
  • @JosephMontanaro I've never tried the procedure, but as far as I understand it, it would not require any additional steps in the hardware manufacturing process. See https://github.com/drduh/YubiKey-Guide for a good write-up. – mti2935 Jan 18 '21 at 21:11
  • @mti2935 It looks like the Yubikey can't use PGP keys for U2F/FIDO2, is that correct? I.e. it will only ever use its built-in secret for that, whatever it is? If so, that's a little disappointing but oh well. – Joseph Montanaro Jan 19 '21 at 16:56

2 Answers2

2

Having duplicate keys would make manufacturing a bunch trickier, because you have to create exactly two duplicates and then sell them together. If you accidentally sell a pair of keys that doesn't match, then you've caused a security nightmare, since neither of them can be securely used (since someone else can have the same key).

Also, most security tokens contain a counter of uses and reusing the counter repeats the secret. For example, a YubiKey's one-time password has a counter as part of the message. Thus, a second key would be detected as a replay attack and rejected by many sites.

What you want to do is possible using DiceKeys, which is a way to generate a secure 196-bit secret that can then be loaded onto one or more special SoloKeys. Having a programmable key is easier than providing multiple keys, since the user can program as many keys as they like.

However, as mentioned, in order to support this use case, the special SoloKeys always use a fixed counter of zero, which works for most FIDO2 and WebAuthn applications but wouldn't be usable for OTP use cases.

bk2204
  • 7,828
  • 16
  • 15
  • I'm not familiar with DiceKeys, but if the key can be loaded onto the device can it also be read from the device? I thought one of the reasons to have special-purpose hardware for security keys was so that they could be specifically designed around the security requirements, e.g. completely lacking the physical wires for outside devices to talk directly to the memory. – Joseph Montanaro Jan 18 '21 at 23:05
  • With regard to the counter, it seems that it would be easy to work around that by simply initializing the counter on one key with 1 as its first bit, so that the keys are guaranteed to be pulling from different halves of the available counter values. – Joseph Montanaro Jan 18 '21 at 23:06
  • I think the firmware of the keys only allows writing to the secret key, not reading it, but of course if you need higher security requirements then this might not be an option. As for the counter, typically the OTP passwords are verified by rejecting any OTP with a counter less than or equal to the value last seen, so multiple keys would require special handling. Some FIDO2 verifiers also keep track of the counter and reject stale values, which is acceptable, in which case multiple keys will never work. – bk2204 Jan 19 '21 at 02:55
  • 1
    Interesting, I didn't know that. I can see how it would cause a problem, then. – Joseph Montanaro Jan 19 '21 at 16:36
2

Let's indeed take YubiKey as a representative expample here for hardware tokens. The YubiKey is unique in that it combines many functions that other tokens perform singlularly.

Regarding the backup issue about the house burning-down/flooding, the problem won't be solved by having pre-paired tokens, since people will just store them the same way. This can only be solved by having a (partly-)trusted third party and basically store the backup key with them (e.g. safety deposit box). This does present the problem of enrolling both keys though.

The YubiKey and most hardware tokens are DESIGNED to be unique, it's a choice, not a bug. Their whole premise is that each key/secret is completely random, unique, well-protected and only in your possession. If the factory could extract and import into some other device, then there are issues about regulations, auditing, trust etc.

The OTP, HMAC and OATH Challenge-Response function are programmable by the user and you can create backups as you please. The problem though, is that, if you store the condiguration somewhere, what's the point of hardware tokens? So that configuration must either be store extremely securely or you make your backups in a secure environment (airgapped, live cd) at the same time and hope you wont need to create more in the future.

The PIV and OpenPGP functions are, again, supposed to be unique. Best practice should be that, especially for signing keys, you generate and attest them on the device itself and they are unexctractable. If something happens to your keys, well, better you going through the trouble of creating new ones than someone impersonating you etc. As for the encryption keys, I hold the position, like others, that they should be generated on the computer and then imported on the token. But, I go a step further in saying that it is not necessary to perform the draconian key ceremony on an airgapped computer using a live cd etc. Basic fact: You decrypt your data on a computer using the key stored in hardware. If your computer is compromised and someone already steals the data they are after, then what's the point if your encryption key is secure or not... they already have the data. This boils down to: if you are worried that someone could steal the encryption key during generation and importation, they can very well steal the data when you decrypt it. So, on a reasonably trusted computer, you can have a backup of the encryption keys with reasonable risk. (The same doesn't go for signing keys, we want those always generated on hardware)

FIDO/FIDO2 function: The particular standard is designed so that it minimized exposure/risk in case of an attack/breach. The YubiKey 4, if I recall correctly, is seeded for the U2F function and it is static, so I guess that they could make duplicates at the factory. The YubiKey 5, and anything with FIDO2 is supposed to generate the key on-board and be unextractable, so to maximize security. If you could create backups, then there is no claim anymore for hardware-backed credentials.

All the above basically come down to any credentials/keys etc being generated on-board. As long as something is generated on-board, it would be counter-purpose to enable backups. This strict behavior is what makes such solutions strong authentication. The "inconvenience" presented far outweighs the benefits provided.

There indeed do exist some configurations that have backup capabilities but these are for very specific cases. Enterprise Hardware Security Modules (all except SmartCard HSM costing thousands of $$$) can do backups. Even in those cases, the HSMs that will hold backups have to be provisioned for that purpose in advance and "grouped together" so that the secrets can be transferred between them in encrypted form. Even in that case, someone has do do the backup in advance, not after the fact. This HSM backup is very similar to registering your backup FIDO2/OTP tokens at the same time for each account.

In all the scenarios, we notice that, for as-absolute-as-possible certainty that the secrets/keys on the tokens are not forged/duplicated etc, we HAVE to limit the backup capabilities (otherwise the secrets aren't hardware-bound anymore). Obviously they don't expect people to but expensive HSMs or have the knownledge to use the SmartCardHSM for secure backups (which are, again, done in advance, not the DKEK which aren't truly unextractable, but the XKEK), so the best reasonable way to implement all this and still be secure is to just have the ability to provision many tokens for the same service.

Some do mention the ability to do deterministic key derivation and duplicate devices. This is reasonable for e.g. BitCoin use because it's more acceptable to have a small chance of someone to steal the derivation passphrase, than having a destroyed wallet and losing your assets. But then their is the problem of storing the BACKUP of that passphrase. The same risk isn't acceptable for e.g. digital signatures. I don't want someone accessing my safebox and stealing a backup for my signature key.

In conclusion, great security requires some inconvenience. It is up to the user, bank, service provider to weigh whether the inconvenience offsets the security gains. Moreover, their could be a solution for backup devices that is less "inconvenient". Someone could e.g. provision 3 different SmartCardHSMs to share the same XKEK (Exchange Key Domain). Those devices can agree on a shared key without exposing it outside the device. Since all devices now use the same keys, the user can export ENCRYPTED keys from the "regular-use" device that can then be imported to the backup device. The benefit from this is that there is no need for the main and backup devices to be added at the same time for each service, only for the initial pairing. This solution requires much expertise though (above average users'). Having it done at the factory probably would have many problems with regulatory requirements, especially for digital signatures etc.

ARGYROU MINAS
  • 111
  • 1
  • 10
  • 1
    "Great security requires some inconvenience" - I don't disagree. But surely there's some middle ground between the current situation (where everybody's Aunt Sally just uses "123456" as their password) and Infosec Utopia where everyone is handed a hardware security token at birth and never loses it? In other words, if _great_ security requires _some_ inconvenience, then can _pretty ok_ security be had with _no_ inconvenience? I doubt that great security will ever be a realistic goal for the majority of people, so it would be nice to at least offer _options_ that are more modest in scope. – Joseph Montanaro Jan 31 '22 at 21:40