I've bought one, but didn't use it yet. I had ideas to use it to test an HSM + pkcs11 OpenSSL engine setup in a personal project (RFC3161 server), but I didn't found the time to play with it yet.
However, the standard tooling to interact with a P11 device under Linux is a bit of a mess, you have tooling from gnutls, p11-kit and OpenSSL (kind of actually, they kind of broke arguments passing, for example the URI of the key not being a valid path, when using external engines).
That price point needs to come way down. Yubico thinks they're competing with established HSM vendors, but they're really competing with their own products. If I have a small business and am considering a hackish YubiKey-as-HSM for $40, it may be worth it to spend around $100 on an officially supported YubiHSM instead.
If $650 is a lot for your business, wouldn’t you just keep the keys on disk? Hardware-based security implies that you have a compliance regime to satisfy, or at least something valuable to protect.
Agreed. For even a small tech business, $650 should be in the 'lol whatever' category of purchasing - especially if there's compliance regimes mandating some kind of HSM in the stack.
However, this device lacks FIPS 140-2 certification of any type, which is a huge detractor for any company wanting to shovel that kind of money towards a solution.
I checked the "NIST List" (rhymes haha), and they might have this module under evaluation:
Let's Encrypt has an account keypair you use to sign your API requests when issuing a certificate.
Does anyone use their OpenPGP key as their letsencrypt account key? How would you convert the signatures from gpg into the jws for the letsencrypt ACME API?
Performance is key. How many TLS handshakes can you complete per-second with a token/smartcard/TPM? The numbers for TPMs are abysmal (TPMs only need to perform well enough that their work is not noticed by the user when booting). I suspect the numbers for smartcards are also abysmal, and for similar reasons.
Don't expect them to be much faster than a regular Xeon CPU however.
The main selling aspect is to avoid your private keys from being leaked to the world. For that there is all sort of tamper proofing on usually what is a PCIe card. They can also be sold as appliances.
Also, they tend to be a bit crappy. I had a really bad experience with Safenet Luna SE at my last job. The thing was buggy as hell, performance tended to be random between devices and on the security side, it was a CentOS 6.0 (with no updates) and a custom kernel driver + some userland tools which strangely enough, creates devices under /dev that were world writable...
The Luna SA seemed better, but their rackmount appliances where nothing to be proud of: cheap 1U chassis, with regular desktop parts (micro ATX motherboard, a cheap celeron, non ECC RAM). The one we opened with quite old however (Luna SA 4 IIRC).
The Thales ones seemed better at least in term of finish. The base appliance seemed to be of overall far better quality (sturdier case). But I didn't play with it, so no opinions on overall performance and ease of use.
I have it on reliable intel that Thales has been employed successfully for heavy applications in datacenters used by CVS and the US Gov. Their products must be good.
My smartcard can do about one, maybe two SSH authentications per second. I don't think it would be much faster with TLS, even with caching the sessions.
Neat! Out of curiosity, the YK4 supports PKCS#11 in PIV mode, why use GPG instead of that? I use it for SSH all the time.
For SSL, I believe that OpenSSL has a pkcs11 engine.
I’ve done both and found the GPG route marginally more reliable but YMMV. You might run in to fewer issues if you’re not on macOS; one example of a problematic interaction is that the official OpenSC installer package installs a tokend plugin that grabs the card as soon as you plug it in; but gpg wants to open it in exclusive mode even though it really only needs the OpenPGP applet, not the PIV applet.
(I’m happy to accept that it’s GPG behaving badly here; the bottom line is just that if you want to use your card for and GPG and SSH and apparently TLS, gpg might be easier to get working than trying to use gpg + anything else. FWIW I hear gpgtools (the Mac distribution) merged a patch that fixed that behavior.)
- You can put "PKCS11Provider /usr/lib...." in your .ssh/config file (even tied to a specific Host block) to make it load the module automatically instead of having to use an argument every time you run ssh/sftp/scp/etc.
- For windows, putty-cac works well with the built-in smartcard/crypto API (CAPI), even on machines where you don't have administrative access (like my work machine). It even has its own version of pageant, so it'll work with tools like WinSCP as well.
Yep, putty cac works very nice. The only downside I found compared to gpg agent is that cac does not forget PIN when the card is removed (gpg agent does that and I like it).
I've found it a little easier to get going with GPG, especially on different operating systems. IIRC with PKCS you have to tell the SSH client to use a particular plugin? Whereas with GPG you just need GnuPG and have it act as the SSH agent. Plus you can forward the GnuPG socket and then anything you do on the remote server that requires GPG will pass through to the Yubikey -- I find this useful with pass and for signing Maven artifacts, just tap the Yubikey when encrypting/decrypting.
I've been using Krypton[1-4] for 2FA PGP and ssh. It uses a phone as a security token, instead of using a Yubikey.
(I'm not affiliated, or even a paying customer. I just benefit from freeloading off their freemium model.)
This is not in any way to take away from how impressive the OP's work is, how nicely it's written up, or the merits of: understanding this yourself, running on a Yubikey instead of a phone, and running independently of someone else's distribution chain (unless you build the phone app and daemon yourself) and infrastructure. If you're in the subset whose response to OP includes “I wish I could do this with my phone, and that someone else would set this up for me so I didn't have to understand it”, [1] might be of interest; otherwise, not.
AndOTP can also handle u2f keys like this on android. And from the fdroid store, requires as card permissions and open source to boot.
Building on this, in Centos epel, there is a package "google-authenticator" which can generate 2fa for your account. It can also be turned on via a pam policy for all accounts.
There's also LinOTP which has a web service and web administration. If you need something more than just 2fa (like 2fa+salt) then you want LinOTP. And being able to integrate it into API calls is also really handy for re-requesting security access.
The next one I tried was using the YubiKey as a smart card in conjunction with gpg-agent for making ssh connections. This did not work out. I couldn't figure out how to add the certificates loaded into gpg2 into gpg-agent using ssh-add. It might me some quirkiness unique to NixOS. I'm looking forward to trying with a different linux distro. Used this guide here: https://rzetterberg.github.io/yubikey-gpg-nixos.html
Overall I have been a fan of YubiKeys since 2013. I hope they continue growing the product.
It may well be slower, but how is it not scalable? You can always add more servers, or more Yubikey devices.
In any case, I would expect any slowdown to be simply because the Yubikey is slower at doing cryptographic operations, not because of any overhead associated with USB. On my system, generating a 4096-bit RSA signature with OpenSSH takes about 4ms, whereas a bit of googling suggests a no-op USB round-trip is on the order of 200us.
I really like this way of doing 2FA. I worked at my first client that used smart cards and practically speaking it was less annoying than using an RSA token or other generator. Is this overall "cheaper" (hardware cost + implementation) than using hardware token generators? It seems to be a step up from using code generator via SMS, more expensive than say Google Authenticator but can persist phone wipes, and less expensive than other hardware tokens. It's very interesting and seems applicable for corporate applications where you can control what people use to a higher degree.
Don't forget robust! My Yubikey has survived on my keyring longer than I ever expected.
Also, the fact that it requires being plugged (powered) to generate a HOTP token makes it very resistant to my kids who invalidate my work's LCD-with-button keyfob all the time.
What do people use for doing TLS client certificates with the Yubikey? I’ve tried:
- Yubikey as PIV token, works well on Windows, other OSes require OpenSC, doesn’t play nicely if you want to use GPG as well
- Yubikey as GPG token only, and using Scute as a PKCS11 emulator on top of GPG agent.
I’m currently using the scute method, but it doesn’t play that well with Windows (Cryptographic Service Provider), and Scute itself doesn’t seem that well used or maintained. Ideally I’d be able to use my Yubikey as a GPG card and have seemless TLS client auth and Windows Smartcard logon.
> doesn’t play nicely if you want to use GPG as well
I just ran into this a few days ago. I was having a hard time debugging why the token would randomly lock up when I tried to do client auth in firefox/opensc while the yubikey had PGP mode unlocked.
> Scute
Thanks for the pointer! This seems to be exactly what I was looking for.
No worries, there’s also scd-pkcs11 that I’ve had a quick look at, but I think that requires you to upload a cert to the card itself rather than storing it on disk, and for some reason the Yubikey 4 can only store at most a 1.3K cert for GPG, which is not enough if you have a 4096 bit public key and issuer.
