3 ms·

I believe the Solokey meets your definition. The hardware schematics are open, as is the software running on it. The Precursor is also open hardware and softwa

I believe the Solokey meets your definition. The hardware schematics are open, as is the software running on it. The Precursor is also open hardware and software. If you trust any smartcard at all running a Javacard-compatible operating system, there's also https://github.com/BryanJacobs/FIDO2Applet https://github.com/BryanJacobs/FIDO2Applet . And of course if you're truly paranoid you can get a FPGA and implement a hardware security key on that. The overall security posture would likely be weaker, but you could be confident, hopefully, that nobody has put some kind of backdoor into the hardware you designed yourself to run atop a generic array of logic gates.

willis936 3y ago
You'd have to choose your FPGA judiciously. The truly paranoid see the attack surface area of 100 GB of black box libraries needed to synthesize designs and appreciate the possibility of gateware trojans.
- Borealid 3y ago
  While I think choosing an open source stack is important, can you imagine how difficult it would be to inject a remote exploit into ARBITRARY hardware your code didn't know in advance?
heavyset_go 3y ago
Nice, last time I looked the Solo Hacker Edition was completely out of stock. Looks like the Solo HE lets you load your own firmware on to it, but it doesn't let you load your own signing or encryption key to ensure firmware updates are trusted. Apparently the Solo HE can be flashed once permanently by overwriting the bootloader, though. The non-HE versions of the Solo 1 and 2 will load new firmware signed by Solokey. Earlier this year I looked into this and remember finding out that it was either the Solo 1/2, Somu or one of the Nitrokey products that, while shipping with a secure element, didn't actually use the secure element.
- Borealid 3y ago
  If you're worried about nation-state level attackers you are probably best off with a device that is burned in and can't be upgraded/changed.
  - heavyset_go 3y ago
    Not even that, I just assume that in a few years, anyone who has a few thousand dollars to hand to Cellebrite will have access to devices that can crack security keys, just like they can give Cellebrite some money today for devices that can hack phones, tablets and computers nearly instantly.
    - Borealid 3y ago
      The applet source code I linked above can be configured to use your PIN (not stored on the device) as the keying material to AES256-encrypt all the credentials stored on the trusted element. The PIN may be up to 63 bytes long, and the derivative used for keying is 128 bits. If you think some company in the future will have the ability to somehow "steal" the contents of the device's flash, you'd still have to climb the mountain of explaining how they could then break the encryption the open-source software already - before they got hold of the key - applied to the flash contents. Just to make sure this is clear, the security key at rest is not storing your credentials. It is storing AES256(key=<PIN>, value=<credential>). It is not storing the PIN. You only need to trust the hardware to implement encryption correctly, which you can - of course - verify yourself. It's not realistic to say that the pre-encrypted values might be secretly stored somewhere else: there just isn't enough space on the device to do that.

willis936 3y ago

You'd have to choose your FPGA judiciously. The truly paranoid see the attack surface area of 100 GB of black box libraries needed to synthesize designs and appreciate the possibility of gateware trojans.

Borealid 3y ago
While I think choosing an open source stack is important, can you imagine how difficult it would be to inject a remote exploit into ARBITRARY hardware your code didn't know in advance?

heavyset_go 3y ago

Nice, last time I looked the Solo Hacker Edition was completely out of stock. Looks like the Solo HE lets you load your own firmware on to it, but it doesn't let you load your own signing or encryption key to ensure firmware updates are trusted. Apparently the Solo HE can be flashed once permanently by overwriting the bootloader, though. The non-HE versions of the Solo 1 and 2 will load new firmware signed by Solokey. Earlier this year I looked into this and remember finding out that it was either the Solo 1/2, Somu or one of the Nitrokey products that, while shipping with a secure element, didn't actually use the secure element.

Borealid 3y ago
If you're worried about nation-state level attackers you are probably best off with a device that is burned in and can't be upgraded/changed.
- heavyset_go 3y ago
  Not even that, I just assume that in a few years, anyone who has a few thousand dollars to hand to Cellebrite will have access to devices that can crack security keys, just like they can give Cellebrite some money today for devices that can hack phones, tablets and computers nearly instantly.
  - Borealid 3y ago
    The applet source code I linked above can be configured to use your PIN (not stored on the device) as the keying material to AES256-encrypt all the credentials stored on the trusted element. The PIN may be up to 63 bytes long, and the derivative used for keying is 128 bits. If you think some company in the future will have the ability to somehow "steal" the contents of the device's flash, you'd still have to climb the mountain of explaining how they could then break the encryption the open-source software already - before they got hold of the key - applied to the flash contents. Just to make sure this is clear, the security key at rest is not storing your credentials. It is storing AES256(key=<PIN>, value=<credential>). It is not storing the PIN. You only need to trust the hardware to implement encryption correctly, which you can - of course - verify yourself. It's not realistic to say that the pre-encrypted values might be secretly stored somewhere else: there just isn't enough space on the device to do that.