Nitrokey(nitrokey.com)
nitrokey.com
Nitrokey
https://www.nitrokey.com/
97 comments
Used the original Nitrokey HSM model on a code-signing server project with a Customer a couple of years ago. I haven't worked with "big name" HSMs before (we looked at Gemalto when we were spec'ing the project but were scared off by the ridiculous pricing) so I can't compare them to "serious" HSMs, but for our project they were a good fit.
The applet running inside the original HSM model is in no way free / open source. The dev tools for the applet are really good, the documentation is top notch, and the integration with OpenSC is very good, but it's definitely proprietary. For our purposes that was not problematic. I don't know if this has changed for the "2" model. Edit: The "2" model also uses the proprietary Smartcard HSM applet.
It was nice, as compared with big name HSMs, to be able to configure the Nitrokey HSM to support escrow of the key material offline (printed on paper in an AES-encrypted state). The project we were working has a 25 year service life for the key material, and Gemalto's solution was "We can't let you escrow key material but we can let you keep buying new Gemalto HSMs every few years."
(I know putting the key material into escrow adds risk, but the risk if keys were lost was considered greater. We ran a commissioning ceremony on the Customer's site, with Customer-provided air-gapped hardware, video recorded and with witnesses present, with the printed keys immediately going into serialized tamper-evident envelopes, all to try to mitigate some of that risk.)
The applet running inside the original HSM model is in no way free / open source. The dev tools for the applet are really good, the documentation is top notch, and the integration with OpenSC is very good, but it's definitely proprietary. For our purposes that was not problematic. I don't know if this has changed for the "2" model. Edit: The "2" model also uses the proprietary Smartcard HSM applet.
It was nice, as compared with big name HSMs, to be able to configure the Nitrokey HSM to support escrow of the key material offline (printed on paper in an AES-encrypted state). The project we were working has a 25 year service life for the key material, and Gemalto's solution was "We can't let you escrow key material but we can let you keep buying new Gemalto HSMs every few years."
(I know putting the key material into escrow adds risk, but the risk if keys were lost was considered greater. We ran a commissioning ceremony on the Customer's site, with Customer-provided air-gapped hardware, video recorded and with witnesses present, with the printed keys immediately going into serialized tamper-evident envelopes, all to try to mitigate some of that risk.)
As a Yubikey user, what stops me from considering this or the Librem key is the lack of confirmation button / touch sensor (and LED).
I do wish the Yubikey had a slider like the webcam covers so you could prevent accidentally pressing the button.
ccccccidufjlndefkacuknijintbntjnkdnrrtncrkfi
ccccccidufjlndefkacuknijintbntjnkdnrrtncrkfi
Maybe you have the nano? I can't imagine touching the Yubikey 4's touch sensor by accident. In fact, I can't imagine my hand touching USB devices by accident.
I got one earlier this year when they upgraded my work laptop, and found out that was a button when I pressed it accidentally while removing it - got the whatever-it-is dumped into a random terminal that happened to be in focus. Didn't hear what version it was, but it looks like a Yubikey 4.
In your case, though, you didn't know that it was a button. Now that you know, I doubt you'll press it again by accident, since there's a lot area around it to avoid the button.
> got the whatever-it-is dumped into a random terminal
I don't use that feature, but I believe it can be configured to either be an OTP or a fixed password.
Looking it up, if you or malandrew don't use it, you can disable it by deleting the OTP programming that comes in slot 1 by default:
> got the whatever-it-is dumped into a random terminal
I don't use that feature, but I believe it can be configured to either be an OTP or a fixed password.
Looking it up, if you or malandrew don't use it, you can disable it by deleting the OTP programming that comes in slot 1 by default:
ykman otp delete 1You could plug it into a USB cable with a built in switch which disconnects power/data.
If you don't use the Yubico based 2fa, you can completely disable it and prevent the string output. Nowadays, most sites are using Webauthn/U2F and that will continue to work if you disable Yubico's proprietary 2fa implementation.
I always install yubiswitch [0] to prevent accidental yubisneezes. It lets you disable it from the Mac menu bar until you need it.
[0] https://github.com/pallotron/yubiswitch
[0] https://github.com/pallotron/yubiswitch
You can move OTP generation to slot 2. This prevents accidental triggering by requiring a much longer press.
https://support.yubico.com/support/solutions/articles/150000...
https://support.yubico.com/support/solutions/articles/150000...
If you don't use OTP, I definitely recommend turning it off as it contains your YubiKey serial number and can be used to identify you. https://medium.com/hackernoon/avoid-leaking-your-identity-wi...
I've been meaning to check these out for a while as I'm totally useless (although, in security terms my chaos probably means I'm securer... just not conveniently-so) with password organisation.
I more mean all the second tier shit I could barely care less about, but have to manage across multiple machines.
I also remembered that if I subscribe to ArsTechnica, they give you a 'free' key for your $50 subscription. Not bad when the keys cost $45!
Anyway, thanks for the prod!
(I'm not in any way affiliated with Ars or CondéNast - I don't benefit from mentioning their offer here - I'm just a reader and your prompt made everything fall into place!)
I more mean all the second tier shit I could barely care less about, but have to manage across multiple machines.
I also remembered that if I subscribe to ArsTechnica, they give you a 'free' key for your $50 subscription. Not bad when the keys cost $45!
Anyway, thanks for the prod!
(I'm not in any way affiliated with Ars or CondéNast - I don't benefit from mentioning their offer here - I'm just a reader and your prompt made everything fall into place!)
I wish they would make something that felt more durable. I bought the U2F key and the combination of plastic and not quite being sure where to press left me with a very flimsy feeling.
I like everything they say they stand for, but compared to my Yubikey the quality is night and day. Something that important that lacks durability is a problem.
I like everything they say they stand for, but compared to my Yubikey the quality is night and day. Something that important that lacks durability is a problem.
Most of these key products "feel" expensive to me, which is purely subjective. Can someone more knowledgeable explain where the cost comes from? Small runs, extended research, custom hardware issues, etc? All of the above?
I think the bigger companies like Yubico are probably now doing runs large enough to be able to compete with many other consumer electronics. So far as amortising R&D and strait manufacture costs.
However they have very high marketing costs as it is harder to explain to the non-Hacker News crowd. They also have little competition, and a high perceived value so are probably slightly price inflated.
As a value proposition I am very happy with mine, and the ones I have given my family.
They're a business device.
Historically, if you have a genuine business need for an HSM you're likely to be spending tens of thousands upwards on compliance costs and key management.
The device itself has become such a blip of a line item that it's dropped into the prosumer range.
I think this is partly due to racked HSMs (with a dedicated priesthood to perform the necessary rites) being slowly replaced with KMS and cloud HSMs in many (most?) new applications.
I'm not sure these things (small HSMs) can ever trend down to being true consumer commodities in their current form. The problem is that long-term you WILL lose your data unless you do proper key management, which is not something most people can do for themselves.
Historically, if you have a genuine business need for an HSM you're likely to be spending tens of thousands upwards on compliance costs and key management.
The device itself has become such a blip of a line item that it's dropped into the prosumer range.
I think this is partly due to racked HSMs (with a dedicated priesthood to perform the necessary rites) being slowly replaced with KMS and cloud HSMs in many (most?) new applications.
I'm not sure these things (small HSMs) can ever trend down to being true consumer commodities in their current form. The problem is that long-term you WILL lose your data unless you do proper key management, which is not something most people can do for themselves.
I predict (and hope) FIDO2 will commoditize all these keys.
I think this can be better explained by starting with the company (instead of the device) which is lean but still requires development and maintenance, purchasing and manufacturing, billing and accounting, customer support, management, shipment and logistics. Those tasks need to be paid.
Do any of these have NFC? I had the most magical experience recently. I was logging into Google from my iPhone, and it said "hold your Security Key near the top of your phone." Knowing that there was no way that could possibly work, I did it anyway, just to show everyone (in my empty apartment) how dumb Google was for telling me to do that.
It worked perfectly! I might never use a password again!
It worked perfectly! I might never use a password again!
Good question - I really enjoy using NFC with my Android phone and YubiKey Neo.
I use a Feitian ePass FIDO NFC (terrible name) - fits smoothly onto my keychain and supports both USB and NFC.
See also: https://puri.sm/products/librem-key/
Looks interesting, I did'nt know Purism did hardware tokens, so thanks.
The integration with the TPM, disk encryption and login in their machines looks amazing !
No FIDO2 though :(. Maybe in the future.
The integration with the TPM, disk encryption and login in their machines looks amazing !
No FIDO2 though :(. Maybe in the future.
There’s enough FIDO2 in the market, but relatively few hacker-friendly options for the traditional PKI stuff (really just Yubikey).
> proudly made in the USA
Is that a good thing?
Is that a good thing?
This depends on your threat model.
Exactly. This greatly reduces the chance that say the Chinese government tampered with your security device. It might or might not affect the fact that the US government tampers with things at times, including Snowden's revelation of intercepting imported goods.
And increases the change that it's nsa-backdoored
They have a warrant canary.
Threat model again: what if you're concerned that they themselves are unaware their hardware's been compromised?
Has anyone actually tested a warrant canary in court yet? It seems pretty transparent to me that if a court order says you can’t publish that it’s been received that also covers continuing to update the canary.
I don't know if it's been explicitly tested, but the concept of the canary was developed specifically because there's strong case law that the government can in rare cases compel your silence, but pretty much can never command you to speak specific language (can't put words in your mouth).
From my viewpoint, if the pride is in the making, yes. If the pride is in where it was made, a bit less so - I'd hope the people making products they want me to buy are proud of what they make, regardless of where they make it.
For Americans I guess.
Unlike some competitors, Nitrokey contains a complete and standard compliant USB plug. This ensures thousands of insertions without connectivity issues.
Here I am waiting for a Type-C from them. Yet they claim that’s a good thing. What utter bullshit.
Here I am waiting for a Type-C from them. Yet they claim that’s a good thing. What utter bullshit.
YubiKey and SoloKey allow a choice between USB-A and USB-C. You can also an adapter for either. Quite handy to have one of such anyway.
I’ve also begun using trezor for the same purpose and from security standpoint it is even better. Onscreen pin code is required and a tap on the screen with the exact info on what service is trying to log in.
USB-C plug would still be complete and standard compliant USB (but not USB-A) plug.
Yep. Also way more convenient to connect to modern android smartphones.
I don't think Nitrokey is claiming that the lack of USB Type-C connector is a good thing. Rather, it appears to be a specific reference to Yubikey's (and maybe also other competitors') "half USB" designs where the very slim HSM slides into a USB port, but isn't actually a USB-compliant connector.
Take a look at https://www.yubico.com/product/yubikey-5-nano for an example.
I think both approaches are fine, and it's really a matter of preference. But it _would_ be nice if manufacturers of USB-connected devices that strictly speaking aren't actually USB-compliant would be a little more explicit about that detail.
Take a look at https://www.yubico.com/product/yubikey-5-nano for an example.
I think both approaches are fine, and it's really a matter of preference. But it _would_ be nice if manufacturers of USB-connected devices that strictly speaking aren't actually USB-compliant would be a little more explicit about that detail.
I get the value if you assume the host is not compromised and you are worried about encrypt-at-rest or for transmit, but how does a user securely provide a PIN to the device if the host itself is rooted?
That's why in another comment I mentioned that the confirmation button / touch-sensor (and LED) on the Yubikeys is important. If a malware tries to use the key with the compromised PIN or while the credentials are cached, the Yubikey will still ask for confirmation. If it's asking for confirmation when you did nothing to trigger it, then that's a sign that the host might be compromised. Simply don't confirm, fix the malware issue, and change the PIN.
That's not too hard to work around. Simply wait until there's a legitimate request from the user and piggy back off that instead
Then there'd be two confirmations you'd have to accept. Even if the compromised host replaces the legitimate request for its own so that the original doesn't run, you'll still notice that whatever you requested was never done after confirming.
I'm not sure what you're precisely proposing by "piggy backing", but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong.
I'm not sure what you're precisely proposing by "piggy backing", but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong.
>but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong.
Maybe if the user is always on their toes and hasn't gotten complacent. You can probably fool most users by causing a technical hiccup (eg. "your session timed out", "Gateway timed out", wifi cut out, etc.), which will provide a plausible reason for them to press the button again. You can also fool them by faking a login screen when they're already logged in, which will allow you to hijack the request without worrying about the legitimate request. Unless they're truly paranoid, most users won't report minor glitches like that to IT, but for the attacker one hijacked press is all they need to own your entire infrastructure.
Maybe if the user is always on their toes and hasn't gotten complacent. You can probably fool most users by causing a technical hiccup (eg. "your session timed out", "Gateway timed out", wifi cut out, etc.), which will provide a plausible reason for them to press the button again. You can also fool them by faking a login screen when they're already logged in, which will allow you to hijack the request without worrying about the legitimate request. Unless they're truly paranoid, most users won't report minor glitches like that to IT, but for the attacker one hijacked press is all they need to own your entire infrastructure.
All that seems targeted, not a generic malware checking for Yubikeys connected to random systems. It also doesn't seem "simple" or "practical".
Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree; if the latter, then I can agree.
I mean, we're comparing to the alternative where if the credential is cached, then any software can use the key as they like without the user being any wiser. They wouldn't need to present convincing fake login screens or anything else.
Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree; if the latter, then I can agree.
I mean, we're comparing to the alternative where if the credential is cached, then any software can use the key as they like without the user being any wiser. They wouldn't need to present convincing fake login screens or anything else.
>All that seems targeted, not a generic malware checking for Yubikeys connected to random systems.
Well that's because it's 2 factor, not because you're using a hardware token. Using TOTP would offer similar protections against "generic" malware that's scanning credentials to use later.
>It also doesn't seem "simple" or "practical".
Is it? It doesn't seem too hard to hook into browser (or whatever other program like gpg or ssh-agent) so you can listen for authentication requests, and disable the wifi using the platform api.
>Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree, if the latter, then I can agree.
The sensor adds marginal amount of security and provides a false sense of security. Most the increased complexity (compared to "generic" malware) involved in such a hypothetical attack comes from the 2 factor aspect, not from having a hardware token or having a physical button on the token.
Well that's because it's 2 factor, not because you're using a hardware token. Using TOTP would offer similar protections against "generic" malware that's scanning credentials to use later.
>It also doesn't seem "simple" or "practical".
Is it? It doesn't seem too hard to hook into browser (or whatever other program like gpg or ssh-agent) so you can listen for authentication requests, and disable the wifi using the platform api.
>Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree, if the latter, then I can agree.
The sensor adds marginal amount of security and provides a false sense of security. Most the increased complexity (compared to "generic" malware) involved in such a hypothetical attack comes from the 2 factor aspect, not from having a hardware token or having a physical button on the token.
Anyway, how to generate GPG keys on YubiKey in ~15m: https://github.com/DataDog/yubikey
last I checked pgp keys were limited to rsa2048. While the recommendation for the last two years have been rsa4096 (or ed-512 depending who you ask)
Is this still the case? their site only have pgp support as a binary option on the models, no extra info anywhere to be found on their search.
Is this still the case? their site only have pgp support as a binary option on the models, no extra info anywhere to be found on their search.
Yubikey 4 and newer supports 4096 bit keys with PGP:
https://www.yubico.com/products/compare-yubikey-4-neo/
https://www.yubico.com/products/compare-yubikey-5-series/
where do you see that information on that page?
All the way at the bottom of the table, under "Cryptographic Specifications".
Recent versions also have support for plenty of ECC algorithms, see https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...
Recent versions also have support for plenty of ECC algorithms, see https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...
It's not well-documented, but non-FIPS can support 4096. FIPS goes up to 3072 for, well, FIPS reasons.
If curious see also
a thread from 2019: https://news.ycombinator.com/item?id=21978384
a thread from 2019: https://news.ycombinator.com/item?id=21978384
I do wonder if physical hardware keys still make sense (at least under a threat model where my hardware is almost always in my home or, if not, under my control) if every device I use has a secure enclave that could conceivably used to fulfill the same role.
That's essentially what https://krypt.co/ is...I've used Yubikeys in the past, but have been on Krypton for maybe the past year or so. No problems with it at all, aside from GitHub recently (within the past couple of weeks) not recognizing the authorization despite it working just fine elsewhere. I haven't had a chance to dive deeper into why.
I had not heard of krypton; read over the website based on your suggestion and got excited, but my excitement turned to disappointment when I saw that neither the iOS nor android apps have been updated in nearly 2 years.
Makes me wonder if the project is still active or not, and don’t want to invest effort in trying out a tool that’s effectively abandoned.
I wish there was an encrypted storage drive that combined something like USB killer with the storage device. Instead of destroying the host, however, it would physically destroy itself if certain criteria were met.
Seems like they've got the security UX down and into a convenient form factor, with a customer list whose judgment I would trust, and I'm going to assume their implementations are sound and free of issues.
As a security product guy who says, "for all security products, the threat model defines the business model," I have to ask, what's the threat model for this product?
As a security product guy who says, "for all security products, the threat model defines the business model," I have to ask, what's the threat model for this product?
Curve25519 seems to be only available on one specific model, and not even the most expensive one. What's up with that?
Some Nitrokeys contain smart cards and those don't support Curve25519 as of now.
Can't figure out which version of any of these keys (and alts) I'd want.. suggestions?
If you're just wanting the 2FA piece (and not the other fancy stuff that the Nitro has), I use the Yubikey 5 NFC and really like it. It's so slim I don't notice it on my keychain and it's very durable.
As of somewhat recently NFC is supported on iOS, so I also keep all my OTP tokens on the Yubikey, and can access them via the Yubico Authenticator app on a computer or on my phone.
One potential downside is that the only Yubikey that has NFC is USB-A only. Another is that there's no backup mechanism (which is by design for security, I guess), so you really need two Yubikeys and program them both identically in case you lose one.
As of somewhat recently NFC is supported on iOS, so I also keep all my OTP tokens on the Yubikey, and can access them via the Yubico Authenticator app on a computer or on my phone.
One potential downside is that the only Yubikey that has NFC is USB-A only. Another is that there's no backup mechanism (which is by design for security, I guess), so you really need two Yubikeys and program them both identically in case you lose one.
"How it works" doesn't explain how it works. Is it basically just a Yubikey?
Which part are you wondering about? Everything is laid out pretty clearly under the "Nitrokey Enables" section. It's a 2FA token that supports OTP and U2F (like the Yubikey), but also has secure storage (flash drive).
The claimed "plausible deniability" benefit seems dubious. You are carrying a branded device with marketing materials that tout its ability to offer you plausibly deniability…
Plausible deniability refers to Nitrokey Storage's hidden volumes. They can optionally be setup, but no need to, and without the appropriate password it can't be distinguished. Similiar to VeraCrypt's hidden volumes.
Yes and? If you carry this on your keychain heading into a security checkpoint, expect to receive interrogation++.
It really much depends on the individual case. In a constitutional state it should make a difference if obviously an encrypted volume is used or if there is the possibility but no certainty of one, two, three or four hidden volumes.
So how long do they interrogate you before deciding there's really no hidden volume? And even if you do reveal a hidden volume, how could they ever know it's the only one? It's pointless, even if they know about the technology.
> To install the driver, you may need to allow the installation of unsigned drivers first.
Nope, thanks.
Nope, thanks.
Can those things break? What if it does? Is all your data lost?
Break as in: smash it to pieces with a hammer? Surely so :p
I would assume that you can have more than one so you have a backup, but if not, yeah that seems like a serious single point of failure.
I've had a Yubikey on my main keychain for about 5 years. I dropped it dozens of time and it never broke.
Same here; the YKs on my keychain take an incredible amount of abuse, rubbing against keys and other objects all day long, for years, and I've never had any trouble. Contacts don't show appreciable wear (and they've had thousands of insertions).
One thing I'd really, really like is for a way to distinguish multiple YKs. The things are so durable that they won't take a permanent marker, and I've had to gouge identifiers on them, clip off corners and so forth.
One thing I'd really, really like is for a way to distinguish multiple YKs. The things are so durable that they won't take a permanent marker, and I've had to gouge identifiers on them, clip off corners and so forth.
In the case of Yubikey's OpenPGP smartcard emulation, you can generate the key on a computer, write it to the Yubikey, then do whatever kinds of backups of the keys you like. If the Yubikey is destroyed or lost, you can buy a new one and write the key to it from a backup.
If I recall correctly, writing the key is an OpenPGP smartcard feature, so it should work on any hardware key that supports acting as an OpenPGP smartcard.
If I recall correctly, writing the key is an OpenPGP smartcard feature, so it should work on any hardware key that supports acting as an OpenPGP smartcard.
The Yubikey documentation recommends always buying them at least in pairs. And configure them both for access.
If you use either a Static Password an HMAC-SHA1 Challenge-Response or TOTP with the key you can easily backup the secret material used to program the key and replace the key if one fails.
Store backups safely.
If you use either a Static Password an HMAC-SHA1 Challenge-Response or TOTP with the key you can easily backup the secret material used to program the key and replace the key if one fails.
Store backups safely.
For Nitrokey Start and Pro: Only during generation of key, it can be backed up.
The Nitrokey HSM supports encrypted backups of keys.
The Nitrokey HSM supports encrypted backups of keys.
I wonder how this compares to the YubiHSM2?
Is this just for the German market?
I bought a Nitrokey and they sent it to the U.S.
Nitrokey ships world wide.
1. Nitrokeys can't do Ed25519. If you want to do ECC, you're stuck with NSA Suite B (which may be fine, depending on your purposes). This was a bummer for me, though, in the context of a greenfield project. YubiHSMs can do Ed25519...but they can't generate attestation certificates for Ed25519 keypairs. This isn't well documented anywhere; I had to lean on a friend who knew a Yubico engineer.
2. Nitrokeys can do attestation against a baked in certificate. However, they can't export those attestations via PKCS#11 -- you have to use some custom shell provided by the underlying hardware vendor (CardContact). The baked in cert (and its public roots) are also RSA2048, which is a bit of a bummer. Oh, and everything's in a weird container format[1] that isn't x509. It's still ASN.1 + DER, at least.
[1]: https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/...