Incidentally I was talking to Conor about this problem yesterday.
This post, in very short, proposes to flash two devices with the same key. I think this is great for hackers & makers, but not for consumers.
Moreover, it might be convenient on a superficial level, but I think it's fundamentally useless. If we consider the security model, the backup device can only be used if the primary device is damaged. If the primary is lost or stolen, the key should be invalidated, and thus the backup device is useless.
This means that you always need 2 distinct, active security keys anyways.
Assuming there's a real case where you want a backup, i.e. you fear physical damage, but don't fear lost/stolen.
For consumers, I believe that the distinction between broken vs lost/stolen is very hard to explain. Think also to a company where you deploy security devices. An employee suddenly needs a backup device. Helpdesk should investigate if it was broken, or lost. It's simply a mess.
For a possible solution, I think there should be a protocol where a user can export the key, encrypted for a backup device.
At a high level: 1) insert the backup device and start the backup process, this export a public key, proof of possession of the corresponding private key, attestation certificate 2) insert the primary device, export the key: upon validating attestation and proof of possession, encrypts the key for the backup device and export the blob, 3) re-insert the backup device to receive the key, decrypt, store and use it. Since this moment on, the device should clearly look as a backup, for example the led could be red instead of blue (see, for example, how MetaMask displays imported keys).
I don't think the protocol is really important here, I think what's really important is that: 1) the user should be the one creating the backup device, if he's knowledgeable enough and understands the risks and uses, and 2) most importantly, there shouldn't be a way to flash a security device with untrusted code.
I'd be curious to hear what people think about this, would backup be useful to you? We're working on the new gen of u2fzero (https://solokeys.com), and this could be a nice feature to add if people feel it's needed.
There's no advantage to your method vs programming the same wrapping key into both devices. As far as the site is concerned, these are the same device but with different counter streams.
I mean, yes the 2 devices can be initialized at different times, but otherwise it makes no matter.
In my method no one knows the key. In the article, you have the key in an env variable. In particular, if someone prebuilds the keys for you, he/she has you key.
> In the article, you have the key in an env variable.
Only during the moment of provisioning.
> In particular, if someone prebuilds the keys for you, he/she has you key.
You have a similar weakness. If someone prebuilds the keys, you don't know if they are loading a fixed key. You also have the problem of not knowing if the attestation cert is actually trustworthy, or where else the key for that cert might live.
> If the primary is lost or stolen, the key should be invalidated
Exactly.
> and thus the backup device is useless.
The article mentions multiple times that the backup is set up in such a way so that right after we use the backup token on some service, the primary token becomes immediately invalidated for this service. Read the article for the details on how it's implemented.
An attacker in possession of the primary device can increment the counter, making the primary still working, and invalidating the backup. In crypto, keys are secrets, the rest can’t be relied on for security.
> In crypto, keys are secrets, the rest can’t be relied on for security.
First, there's no 100% security in the world: it's all about time and resources, and a proper security consists of many layers. The counter is one of them; after all, it does exist in U2F protocol for a reason (to prevent clones).
And if you've read an article, you'd notice that it mentions: the backup token should only be used to log into accounts, add a new key, and invalidate the old one. Of course it would be a bad idea to keep using backup token. To avoid waiting for the new pair of tokens to arrive, I keep them together with my backup: my backup consists of the backup token itself, and also a brand new pair of tokens (new primary and new backup), which aren't used anywhere yet. So if something terrible happens and I lose my primary token, I go all the way down to get the backup, use the backup token to login to each service, add a new primary token, and revoke the old one.
I don't think we understand each other. If a device gets in the hands of the attacker, I won't assume he/she's going to use your code and obey to your restrictions. The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants.
I see your point on the limited usage of the backup while you buy a new device. This goes back to my initial comment... you basically always need 2 active security devices, so I don't really see any big benefit in having a backup vs a secondary device.
> The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants.
Again, not saying it's impossible, but with the existing implementation, it takes considerable amount of time. I should be able to get the backup token faster.
> I don't really see any big benefit in having a backup vs a secondary device.
A big benefit for me is not having to add my backup token to every single service. It's both more convenient and more reliable (since I can't forget), and also more secure, because I can take my backup token and brick it into the wall. If this benefit is not a benefit for you, then, fine, we're not going to agree.
Got it, this makes sense to me. And sorry, I was rereading the thread, I don't want to think I'm dismissing your whole article, I really appreciate you writing about it.
I think the time is a big advantage. As I mentioned, I'm working with Conor on the FIDO2 security key (actually, update [1]), and we were thinking to an option to create backups, maybe for advanced users. I'll keep you posted if we end up doing something in the space.
Thanks! Yeah Conor mentioned that to me; I think the real benefit (at least personally for me) would be not being able to buy pre-made matching pairs of tokens, but being able to easily write my own key material plus the counter boost value. You know, yubikeys do have this functionality for OTP: their utility allows to program OTP keys. I actually expected the same for u2f, but alas.
This post, in very short, proposes to flash two devices with the same key. I think this is great for hackers & makers, but not for consumers.
Moreover, it might be convenient on a superficial level, but I think it's fundamentally useless. If we consider the security model, the backup device can only be used if the primary device is damaged. If the primary is lost or stolen, the key should be invalidated, and thus the backup device is useless.
This means that you always need 2 distinct, active security keys anyways.