Desired Features

I’m looking to get a hardware security key and am really considering a nitrokey.
But, there’s a couple of this that I feel nitrokey is lacking. If it had these, I’d grab (at least) one no-questions asked. No open source hardware key, to my knowledge, has all of these features.

  • Case improvements
    • An IP6x rating. Ideally at least IP65.
      • first digit:
        • 5 → dust protected; dust must not enter in sufficient quantity to interfere with operation
        • 6 → dust-tight; no ingress of dust. (during testing: exposed to fine dust for 8 hours)
      • second digit:
        • 5 → protection against water jets (during testing: exposed to water jets for 3 mins)
        • 6 → protection against powerful water jets (during testing: exposed to high pressure water jets for 3 min)
        • 7 → protection against immersion in 1m of water for 30 min
        • 8 → protection against immersion in (at least) 1m of water indefinitely
    • A crush-resistant case. Honestly not super needed, but it would be nice to have.
    • A nicer case/enclosure. Honestly, the current case doesn’t look very good.
      • A slim case similar to the yubikey 5 or the solokey 2 (with the half-size usb-a connector, or whatever it’s called. basically the usb-a connector without the top jacket piece.)
      • Alternatively, a case like the Thetis FIDO2 key
      • A full metal enclosure would actually be really nice, but honestly even something that’s plastic would be fine
  • A single key that supports both USB-A and USB-C (also possibly: USB-C + lightning, for people who have apple devices? though all new apple devices will have USB-C). This could be done in a couple of ways:
    • swivel piece which has a connector on both ends.
    • just a normal key with a connector on both ends
    • a connector on both ends, but each end has a little tab on the side that can be uses to extend or retract the connector
  • Allow more gpg keys that aren’t subkeys. Is there a reason only one is supported? Technical limitation of the hardware or something else? They aren’t like super large once saved to disk, so I’d be surprised if storage space was the limiting factor. (tbh just “more” in general for everything. more gpg keys, more ssh keys, more aes keys, etc.)

Just wanted to post some of my suggestions that I’d love to see in a new key.

2 Likes

I put here my “list”:

  • better NFC support (which includes a Nitrokey app that works on android phones.
  • support of password length over 20 digits (25 or 30 are often possible nowadays).
  • support for more password storage.
  • a working native software for Linux in the most used GUI that is KDE plasma (under wayland) and Gnome (also here, since X is phase out that must work under Wayland) that has no need of containers or snap
  • a working software version of the nitrokey app under android. Must not be fancy but working.
  • as for the hardware: if I could imagine a viable (and economically payable) “roughetized” version of the key, I would rather imagine a tubular design with screwable head (and changeable O-ring - if we want to be “sustainable”. One of the problem of the current NFC support seems to be the energy supply, so this would give more space for components, but I am not into the technology used usually, so maybe it is technically not possible to build in a sufficiently large power source which could charge during connection to a usb-port).
  • the current casing is for me quite satisfactory, maybe a way to fix the head to a little hanger to the case body in order not to loose it during usage would be nice and probably economically payable (I do not speak actually of delivering it with the hanger, but to create the premises for being able to fix one if the user so decides.
    I gave back my version 3 key (and I really would need it) because of the software situation. Now this is already a niche product, if the usage is not straightforward and not possible under a GUI (but we have to fall back on a CLI and do what, copy and paste from there to fill it in into the password selection window? And second factor via OTP is not really straightforward like this with a browser. I do not think that it is a viable business strategy to build a niche product, within a niche market for a niche portion of users, within this market. Now we have finally OTP with the website of the German Bahn, this is a big step forward…and the new key does not support the software for a GUI?
    Just my opinion, “the market will judge” is the mantra, no?

P.S. with a correct software support as described, working and easy to use, my willingness to pay for this product would be substantially higher than the current situation and I somewhat doubt that I am a black swan with this view.

1 Like

If we talk about OpenPGP card, that GPG wants to use, it is specified that such a card can hold one Authentication subkey, one Signature subkey and one Signature subkey.

The software would need to emulate multiple OpenPGP cards to give you the access to more keys.

+1!

On this point, what about a Nitrokey Storage whose encrypted part would contain your Keepass database with potentially hundreds of passes, and for easier use, copies of KeePass instances (one per OS) in the visible part of the Nitrokey?
One may even set the Nitrokey app to open the DB only if that specific Nitrokey is present (an existing option in the software)…

1 Like

Well said and I would absolutely appreciate, as I do not endorse FIDO as the only good solution (maybe it is at times even a problem) but the OTP as second factor works only if you can remember the first one, hence the password.

As it is good practice, all sites nowadays will get a randomly generated one, often with agp or similar, alphanumerical, 20 or more digits, symbols etc. a sheer “memory nightmare”. It follows that your idea is appealing.

  • On the downside, if the key is stolen both factors are on one medium.
  • On the upside, if you choose this kind of solution, you may hold one nitrokey on the key fob, along with your house key, and another nitrokey with the key of the car (as every intelligent person knows, never mingle house key with the car key(!)). It follows that by doing this, you would partially restore a good separation of factors needed.

However we have also to understand that the industrial cost of such a change in layout may be substantial depending on the country Nitorkey GmbH (or whatever their societal format might be), mainly due to the current turmoil of delivery chains.

Personally I would guess they are literally sitting on a fence. If they would rely on PRC mainland chip layout they would (or shall I choose “will” here?) be accused of being “a national security risk”, whether this has any base or not. Albeit, given the frivolous development of the argument in several, potential served, countries, it has to be taken into consideration.

But the price in PRC mainland may(!) be convenient, depending on the chips used (e.g. 28 Nm should still be affordable). Yet, if they would choose to rely on the island, then they may as well face very high prices (mainly due to the artificial current economic moat created by the current “hysteria”).
Further to this point, we cannot know whether they have made volume contracts, which, in the light of changed economical environments, they may well be reluctant to renegotiate.

So yes, whatever idea is feasible with the current layout, I would deem interesting, and having some chance of implementation. For what are features requiring a layout change of large measures, this may proof to be “wishful thinking” at the current moment. But for the sake of brainstorming we may still mention the ideas (without expectations of fast implementation).

As I see it, the current lack of software and software based solutions is probably due to lack of money to develop it internally to the industry, as outsourcing it to Asia or US in any form, they will be, for obvious reasons(!), reluctant. Maybe they could contact and take patronage of a kind of “OSS project” with a locally based University IT faculty (e.g. giving the participants a hands on work experience and a useful entry of “industry experience” on their CV) in order to create the software missing and at the same time raise product awareness (always looks good in the press).
While all these points are for sure heavily influencing the decision-making of Nitrokey, we as users cannot know these underlying factors.

According to the spec, I believe it may support more than 3 keys, however I’m unsure. I do believe that this is indicating that it should have “atleast” 3 keys.
See: section 4.4.3.8 Key Information in the Functional Specification of the OpenPGP application on ISO Smart Card Operating System (version 3.4.1).
Although, elsewhere it refers to these “additional keys” as “proprietary keys”, so applications like gnupg may not support them.

according to the manpage of gpg-card it also supports something called “apps”? unsure what those are, however those may be a way to address multiple separate keys on a single card? Unsure.

there are also PIV cards which I think may support multiple keys and which gnupg already supports. Unsure if these would be an option as well?

however the alternative could be to pretend to provide multiple independent keys, and then just have the user specify which one they want to use, as gnupg does allow the user to address multiple cards.

I just wanted to tell you that OpenPGP cards like Nitrokey Pro or Nitrokey 3 support what they support - 3 keys as per OpenPGP specification.

There are devices like a smartcard being part of the Nitrokey HSM 2 that do not follow the OpenPGP standard and have to be integrated with GnuPG for example using PKCS#11 interface.

yes, I am aware. however they do also have to be 3 subkeys and cannot be 3 seperate pgp keys.

and even if they are subkeys, 1 is a signing key, 1 is an decryption/encryption key, and 1 is an authentication key.
but, I personally maintain

  • a unique pgp subkey for each of my devices
  • a unique ssh key for each of my devices

and would, ideally, like to keep doing this. but, this would not work with the current nitrokey and would require having multiple nitrokeys. I’d like to avoid that and instead have a single one on my keychain.

Are multiple FIDO2 credentials an option for your ssh use case? You might need to store the stub file online so that you could import it on a new workstation.

Also for encryption, FIDO2 could be an option using age and binding it to the token. This would allow for unlimited identities that require the token to be present for decryption. But you also need to store the identity files.