3 ms·

Yup, I built this. The file storage is only for the FIDO2/WebAuthN device, which generates large private keys for each credential; the U2F device keys are small

by cmdli 4y ago

Yup, I built this. The file storage is only for the FIDO2/WebAuthN device, which generates large private keys for each credential; the U2F device keys are small enough that they are actually encrypted/stored in the key identifier that is passed in by the client. I’m currently working on trying to expand this out with new features, as most of the work here was actually emulating the USB device which involved a lot of different layers of protocols.

stavros 4y ago
Very nice work! This is one step closer to a password manager that doesn't actually need to store any passwords, just one key. I'm not very familiar with FIDO2, but I thought the private keys for each credential were derived from the single key in the device and the website's domain? Is that not the case? Or are you just generating separate credentials per site and keeping those? If the latter, couldn't you derive all credentials from a single source of randomness and skip the storage?
- cmdli 4y ago
  Each credential has its own private key which is signed by the device's private key for certification. I am uncertain if the FIDO2 spec says how those private keys need to be generated; right now they are generated randomly but they could easily be generated from a single secret/key, much like you suggest.
  - stavros 4y ago
    Ah, right. Yeah, as far as I know, Yubikeys and other devices derive them from a single random value that each device comes with. This is due to the lack of storage space in the devices, as most of them aren't even writable at all. If you want to switch to deriving keys this way, you could save the storage space and make the program almost stateless. You'd still need the initial random bits, and those could be stored somewhere (they can probably be just 256 bits or so) or come from the user in the form of a passphrase.

3 ms·

Yup, I built this. The file storage is only for the FIDO2/WebAuthN device, which generates large private keys for each credential; the U2F device keys are small

by cmdli 4y ago

stavros 4y ago
Very nice work! This is one step closer to a password manager that doesn't actually need to store any passwords, just one key. I'm not very familiar with FIDO2, but I thought the private keys for each credential were derived from the single key in the device and the website's domain? Is that not the case? Or are you just generating separate credentials per site and keeping those? If the latter, couldn't you derive all credentials from a single source of randomness and skip the storage?
- cmdli 4y ago
  Each credential has its own private key which is signed by the device's private key for certification. I am uncertain if the FIDO2 spec says how those private keys need to be generated; right now they are generated randomly but they could easily be generated from a single secret/key, much like you suggest.
  - stavros 4y ago
    Ah, right. Yeah, as far as I know, Yubikeys and other devices derive them from a single random value that each device comes with. This is due to the lack of storage space in the devices, as most of them aren't even writable at all. If you want to switch to deriving keys this way, you could save the storage space and make the program almost stateless. You'd still need the initial random bits, and those could be stored somewhere (they can probably be just 256 bits or so) or come from the user in the form of a passphrase.