Nitrokey
nitrokey.com
nitrokey.com
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/...
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.)
ccccccidufjlndefkacuknijintbntjnkdnrrtncrkfi
https://support.yubico.com/support/solutions/articles/150000...
> 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 1I 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 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.
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.
It worked perfectly! I might never use a password again!
The integration with the TPM, disk encryption and login in their machines looks amazing !
No FIDO2 though :(. Maybe in the future.
Is that a good thing?
Here I am waiting for a Type-C from them. Yet they claim that’s a good thing. What utter bullshit.
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'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.
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.
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.
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.
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.
Recent versions also have support for plenty of ECC algorithms, see https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...
a thread from 2019: https://news.ycombinator.com/item?id=21978384
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?
Unfortunately they don't do firmware upgrades, so one of mine can only do rsa.
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.
Nope, thanks.
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 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.
The Nitrokey HSM supports encrypted backups of keys.
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.