4 ms·

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 gr

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.

ecesena 8y ago
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 https://solokeys.com), and this could be a nice feature to add if people feel it's needed.
- jiveturkey 8y ago
  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.
  - ecesena 8y ago
    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.
    - jiveturkey 8y ago
      > 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.
dimonomid 8y ago
I'm not sure if you've read the article. > 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.
- ecesena 8y ago
  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. Edit: grammar
  - dimonomid 8y ago
    > An attacker in possession of the primary device can increment the counter, making the primary still working In the article I explain how to make it impossible to just "increment the counter" of the primary token, see this section: https://dmitryfrank.com/articles/backup_u2f_token#caveat_with_the_counter https://dmitryfrank.com/articles/backup_u2f_token#caveat_wit... > 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.
    - ecesena 8y ago

ecesena 8y ago

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 https://solokeys.com), and this could be a nice feature to add if people feel it's needed.

jiveturkey 8y ago
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.
- ecesena 8y ago
  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.
  - jiveturkey 8y ago
    > 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.

dimonomid 8y ago

I'm not sure if you've read the article. > 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.

ecesena 8y ago
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. Edit: grammar
- dimonomid 8y ago
  > An attacker in possession of the primary device can increment the counter, making the primary still working In the article I explain how to make it impossible to just "increment the counter" of the primary token, see this section: https://dmitryfrank.com/articles/backup_u2f_token#caveat_with_the_counter https://dmitryfrank.com/articles/backup_u2f_token#caveat_wit... > 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.
  - ecesena 8y ago