Yubikey/Smartcard backed TLS servers | Hacker News Reader

Yubikey/Smartcard backed TLS servers

blog.benjojo.co.uk

156 pointsbenjojo1244 comments

Yubico also offers the YubiHSM which is more tailored towards this use case (albeit much more expensive): https://www.yubico.com/product/yubihsm-2/

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:

https://csrc.nist.gov/Projects/Cryptographic-Module-Validati...

FIPS certified HSMs cost 10-100x what the YubiHSM does.

Why aren't they competing with established vendors?

If you want a cheap HSM, there is also nitrokey:

https://shop.nitrokey.com/shop/product/nitrokey-hsm-7

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).

Also, if you want to play with an HSM without a physical HSM, softhsm is for you (https://www.opendnssec.org/softhsm/).

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?

Good question. +1 vote.

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.

That’s why there’s a market for $10k+ rackmount versions of these devices (enterprise HSMs).

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.

Well, if you leave the session ticket decryption key off the token, resumption won't be slow. But 2/s is beyond abysmal for new 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.

https://developers.yubico.com/YubiHSM2/Usage_Guides/OpenSSL_... (for the YubiHSM2, but the YK4 also supports PKCS#11 with OpenSC)

P.S. The color caps on those yubikeys in the photo are cool, are they 3D printed?

GPG agent is just a convenience thing. It's already there and usable for most people with yubikey setups,

Yup the caps are 3d printed! https://twitter.com/Benjojo12/status/929445558275756032

/ https://www.thingiverse.com/thing:2641499

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.)

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 did not knew about that, thank you! I instantly changed my SSH key for the generated key in my YubiKey Neo and use it everywhere.

Here is a tutorial is anyone is interested: https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PK...

Yeah, it's cool! A couple extra tips:

- 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.

https://risacher.org/putty-cac/ https://github.com/NoMoreFood/putty-cac/releases

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 tried on both OS X and Linux, works fine, though on Linux it asks for the PIN every time, which is very annoying.

Do you know a solution for that?

I think you can add it to ssh-agent with

ssh-add -s /usr/lib/....

But, it's acting funny for me, particularly if I remove the key.

I did, but it’s still asking the PIN every time :(

I'd be interested in performance figures: how many TLS handshakes can this setup complete per second vs a "normal" one?

Me too. Also thermal figures and lifetime figures, I assume that the yubikey is going to be slowly damaged by work this intensive?

I would be surprised. There is no non-volatile memory being written, this is merely running operations on a processor.

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.

[1] https://krypt.co

[2] https://github.com/kryptco

[3] https://news.ycombinator.com/item?id=14490766 – previous, mostly-skeptical, HN discussion

[4] https://news.ycombinator.com/item?id=16915819 – more recent discussion

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.

Very cool! I have recently begun experimenting with interesting YubiKey projects.

The simplest project was getting the One Time Password working for SSH & Local authentication on my OpenBSD laptop: https://www.romanzolotarev.com/openbsd/yubikey.html

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.

I don't see how this can scale if every TLS negotiation requires the latency of multiple USB transactions.

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.

Smart cards are awesome, but you are really constrained by what the US DoD does, as they are the biggest market.

We chose to go another way because you still need another MFA for many use cases.

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.

We use https://github.com/square/ghostunnel with yubikeys with client certs, on Linux and Windows boxes for client connections.

> 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.

That’s great. I got my GitHub yubikey but never opened it for a year and when I did, it never worked so that was a bummer. Looks like good tech.

Does this work with the basic U2F Yubikey or do you need the v4/NEO?

It requires GPG, so you need a neo/v4

Reply on news.ycombinator.com