Would there be any possibility that you develop / produce some keys for the following trust model: the host computer is not completely trusted. I think that this is the only “reasonable” trust model for modern computers. Developing such a key would make sure that the only thing the host computer can access, for example in the case of decrypting a file with RSA, is the file that has been decrypted, and that the computer cannot take advantage of an unlocked key. To me, that would mean:
1: the pin protecting the key should be entered on the key itself, not on the computer; that would mean, adding a keypad
2: to avoid that the computer exploits an unlocked key to decrypt more files than intended, the user should touch a capacitive button each time the key should be used to perform some decryption, even after the key has been unlocked with a pin code. This way, the computer cannot start decrypting files without the user explicitly accepting it, even if the key is unlocked by having entered the pin.
Would a fingerprint reader be an acceptable solution?
This should be already possible with Nitrokey 3 once the OpenPGP smart card interface will be added. Part of the solution will require properly configured software on the host side.
Nice about the USB Armory Mk II - but that will still require me to carry around a keyboard and connect it directly to the Armory, if I want to make sure nobody can intercept my pin code - would be more convenient to have the keyboard embedded directly in the Nitrokey, similar to OnlyKey.
I don’t think a fingerprint sensor would solve the issue, as a fingerprint is actually kind of ‘public’ (we leave fingerprints everywhere we go), and easy to obtain by force. A pin code entered directly on the device, similar to OnlyKey, is much harder to obtain IMO - especially when entering the wrong pin code a few times erases the contents of the token.
To me, as it is now, the Nitrokey is ‘something you own’, and if we trust the smartcard implementation, a ‘safe something you own’. The pin code is in theory a great ‘something you know’, but there is still the issue of how it is protected. For me, if the pin code needs to be entered through a host computer, and given that a computer has such a large attack superficy that it is potentially possible to compromise the computer and intercept the pin code, it is currently not a completely safe something you know. By contrast, if the pin code can be entered directly on the token, which is small enough that I can inspect its whole design and implementation myself, I feel a bit safer that the pin code cannot easily be intercepted, and is a ‘safe something you know’.
honestly using the tech cryptowallets have brought is generally something I’d love to see more generalized.
especially as the trusted display makes several things also easier. for example a password manager could store the encrypted data on the computer or whereever and instead of just blindly tapping to show a password with the user not getting to see in advanced which is actually sent to the key (or even something completely different, one could be specifically see for example "do you want to show the password for ABCXYZ -> yes/no
or sign message -> yes/no/show message where you could see what you sign (which is the number one principle crypto wallets use.
or hell even when normally decrypting for example pgp data you could get a glimpse of a preview on the display before you decide to shoot the data to the PC if you are paranoid.
one thing I noticed with the onlykey tho is that it has a backup functionality, which while useful shows that the key data can be extracted off the onlykey, which on a smartcard style device is often unwanted.
I do have an OnlyKey and there are a few things I really love about it: fully waterproof since baked in epoxy, and keyboard. But when I had looked at the firmware a couple of years ago, it looked like a horrible, horrible mess that I would definitely not trust. I think it is a bit better now but still feel a bit skeptical… Also, there is this issue that I am not sure of really how safe it is, when as pointed here, the private key can be extracted through software - this means that if there is any way to exploit the firmware, there is no much safety left. So I stick to Nitrokey - and I would really love to see a Nitrokey with keyboard and baked in epoxy ^^ .
What exactly is horrible in the code? It uses well known and established libraries (e.g. mbedtls) and open source implementations provided by vendors like Yubico. As the creator has a background in security consulting, they are also very transparent about their security (where they mention that they do not rely on hardware read out protection using NXP Kinetis).
I really like that there is a healthy community of Open Source developers with astounding technical expertise.
Using various security tokens of different vendors, I like the open source variants most. You can see how those vendors flourish, find their own USP and collaborate where possible. E.g. love the success stories about gnuk / Nitrokey Start or Solokey / Nitrokey FIDO2.
Regarding the trust model, where the host computer is not fully trusted: You need some compute that you can trust - be it said USB armory (neat device) or cheaper: Raspberry Pi Zero with case and Tyvek Wristband wrapped around or a remote VPS.
You could then execute ssh commands, use shellinabox, spawn a guacamole VNC or X11 forward a GUI, and port-forward/authenticate asymmetrically via your token.
I agree it looks much better now and they have done a lot of work, but when I bought my OnlyKey 2 or 3 years ago, their code was as far as I remember a horrible mess of spaghetti with re implementation of the algorithms, all shoved in a single Arduino .ino file. Agree it is much better now, they seem to have come a long way in the meantime .
.