Guide to Using YubiKey for GPG and SSH
github.com
github.com
For business, it's a better deal to buy new Yubikeys that support FIDO2 then it is to support GPG on Yubikeys.
I had a Yubikey 5 with the first firmware revision and resident keys worked fine.
Because the first firmware revision lacks the credential management API, there's no way to list the resident keys on the device or to delete individual keys. The only way to delete resident keys AFAIK is to reset the FIDO2 application on the key.
"Normal" SSH keys will work for (pretty much) all systems that support SSH. And the ones that don't will certainly never support U2F.
And even that is not true in all cases. I still regularly encounter devices that only support 2048 bit RSA and nothing beyond that. /glances in ubiquis direction.
Since I use Yubikeys in PIV mode with PKCS#11, it works just fine to use its 2048bit RSA.
If the option is 2048bit RSA, passwords, or software keys, then I know what I prefer.
Backing up the secret key material is still an issue with FIDO2.
You should add multiple keys to your logins and have a "backup" key which is separate one.
Especially when you lose physical key, you want to have different one and revoke lost one asap.
The same with private keys generated on a device - private key should stay on the device on which it was generated and never copied. If you need access from a different device you generate private key on another device and transfer public key only to be added to account.
Which in turn also makes physical keys that you can connect to different devices a bit more convenient as private key never leaves key and is not directly accessible by laptop that it is connected to.
Having a strong passphrase makes things a lot simpler. A classic convenience vs security tradeoff...
I can't use it to log in to my routers and other SSH gear, and don't expect to for the lifetime of the hardware.
With OpenSSH U2F it'll be decades before you won't ALSO need a more traditional key. That or use passwords (brrr)
- The guide was mostly written before that was possible
- Many servers are slow to update to newer distro versions with newer openSSH versions. I still need to access at least one server which can’t support it yet. (And just one which doesn’t support it forces me to use the GPG approach so that it’s the same key everywhere.)
- the guide also tells you to use the new approach if it’s available to you :)
- GPG is still used for some other things, like signing git commits
I also disagree with the idea of backing up the private key. Generating secure passwords is hard and it is infeasible to ask people to use diceware to generate and store their secure backup. And if you aren't doing backups you might as well generate the key on device. For the purpose of revocation, you can keep a signed revocation certificate around in the event you lose your key.
This makes the guide much simpler, as you don't have to spin up a live airgapped system with secure boot for each employee's key generation. There's no need to have a complicated backup flow either.
---
YubiKeys in general are problematic as they don't have a display that can show the action being taken, e.g. a compromised host could display one thing while the user is signing/encrypting another. This isn't a problem in modern crypto hardware wallets, which have displays that show precisely what is being signed, to mitigate this exact threat model.
(I already own a Ledger Nano X and a Trezor in case that’s what you mean with “crypto device” and find the GPG experience insufficient).
Unlike a YubiKey, the screen on both Trezor and Ledger mitigate the confused deputy/phishing attack for the purposes of FIDO U2F. I'd recommend them with usage for U2F, specifically the Ledger if you're interested in better hardware security at the expense of open-source.
I can overlook the UX issues when it’s a matter of 1-10 average signs per day and not 100s, like I have with PGP+U2F. I guess they’re all right as backup devices.
The new Nitrokeys look interesting (and not yet available) but I agree, something is missing in the market here.
I'm really interested to hear what you're doing that gives you 100s of signatures a day (or decrypts?)
I have been searching for an openpgp card replacement but I use one with a hardware pinpad, I can't imagine entering my pin 100s of times a day!
I think solving the lack-of-display problem is far easier for FIDO/TOTP than GPG, as with GPG you could be signing arbitrary content that is difficult to validate on a small screen.
But FIDO/TOTP data are more structured and can be coerced into being displayed on the device's screen, as shown in this video [1].
I’m at the moment between keys. I tried to use the new SSH keys which resides on the FIDO key. Problem is that most services I wanted it to use for don’t understand them. Most prominently Ubuntu LTS18.4 because of no official support for OpenSSH 8.2. So I use my old key with an ssh key derived from gnupg and a new one with resident ssh key.
You should have secure copies of your master key. Especially if you've invested time in building up your web of trust. Backing up encryption keys is also useful. If they're lost, data cannot be decrypted later. Signing keys are the only ones which are completely expendable.
Creating a paperkey and storing it in a physical safe is ideal. That way you can keep your master key offline until needed and use subkeys for daily use.
You can encode it as a QR code:
gpg --export-secret-key $KEY | paperkey --output-type raw | qrencode --8bit --output secret.png
zbarimg --raw --oneshot -Sbinary secret.png | paperkey --pubring public.asc | gpg --import
zbarcam --raw --oneshot -Sbinary | paperkey --pubring public.asc | gpg --importWhere can I read to how to do that?
https://www.jabberwocky.com/software/paperkey/
https://wiki.archlinux.org/title/Paperkey
The paperkey tool will produce a human-readable text file that you can print out. I found that to be inconvenient and settled on QR codes instead. They're ubiquitous, machine-readable and have built-in error correction.
Which ones?
For Windows, you need to compile (cf https://gist.github.com/martelletto/6a7cf806c6433ac9ce71d66a... ) then ssh-keygen -t ecdsa-sk
For Linux, if you need to recompile: https://cloud.google.com/compute/docs/tutorials/ssh-with-sk
https://www.schneier.com/blog/archives/2007/11/the_strange_s...
You can read about what is actually done to make ECDSA keys here.
https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engin...
debian 10 backports repository has openssh 8.4 with FIDO2 support builtin so no recompile needed there.
debian 11 has 8.4 in its regular repository.
I also recommend doing what I did: get two Yubikeys, not one. Do everything twice, that way you have a physical backup/fallback device. You can also choose to leave one permanently stored somewhere and carry another one with you. Encrypt your backups for two public keys, add two 2FA keys to critical sites, etc. It buys you lots of options for relatively little effort.
It all appears to be pretty far from being plug and play, often seeming to require a lot of additional software/modules to get specific things working. Is this because the standards don't go far enough or am I just way off the mark?
Everything else - good luck. Proprietary apps. Each one is slightly different. I haven’t bothered to use it for key generation. To be fair, there are hardware design constraints (no clear UI) so it would be hard to get around the learning curve.
So this is why when talking about using hardware keys to unlock local stuff, like a PC, or authenticate/decrypt SSH, GPG, bitlocker etc. this all gets so tricky and often needs extra software?
From their website: “Support for WebAuthn, FIDO2, FIDO U2F, smart card (PIV), Yubico OTP, OpenPGP, OATH-TOTP, OATH-HOTP, and Challenge-Response” [1]
So one key can do all of those things. How user friendly it is depends on the service you’re using and how that is configured. Logging into to a google account? Easy. Logging into Windows? Easy-Medium [2]. As more organizations support the tool, it becomes plug and play in a lot of areas (Okta, centrify, etc). Mac is more difficult with opportunity to lock yourself out [5]. Linux is… Linux.
You can set more configurable options in the manager tool. [3]
But it can get as complicated as you want it to with the developer tools [4].
I’ve been following this for years and have had keys, and I think we’re finally to the point where I could recommend it to a semi-technical person. Get 3 - 1 small form factor that stays in your main computer / pc / chromebook, one on your key ring with NFC, and a backup in a fireproof safe. That will stop any account takeover. If a key is lost or stolen, revoke and replace it. That will cover 99% of attack scenarios for the population.
[1] https://www.yubico.com/product/yubikey-5-nfc/
[2] https://www.yubico.com/products/computer-login-tools/
[3] https://www.yubico.com/support/download/yubikey-manager/
[4] https://www.yubico.com/support/download/
[5] https://support.yubico.com/hc/en-us/articles/360016649059-Us...
I guess that's the crux of it. I'd prefer to find an open hardware alternative if possible, and not have to trust additional software. I know my use case, but don't know which standards apply and are required to make it happen. Knowing that would allow me to pick an open hardware key that, by meeting those standards, would let me do what I need.
It just seems even ticking those boxes isn't much of a guarantee when so much extra software appears to be needed.
The alternative is to either find:
- the open device with the most active developer community and hope the feature comes
- the device that just meets the most standards (as you suggest, a Yubikey)
If I sound confused it's just because I am.
e.g. one of the things Microsoft wants to unlock a (potentially offline) Windows 10 PC is hmac-secret and it is not an essential feature of FIDO since you wouldn't need it to e.g. sign in to Google, or GitHub or whatever.
For products built by the community, you should be able to find someone who has tried your scenario (e.g. "Unlock a macOS 12 macBook") and can say it definitely works with the product before you buy one.
I guess another I noticed was PIV/Smartcard which seems to be kind of long in the tooth and not available on some newer hardware keys. I'm not sure if that's for security reasons and I start to wonder if multi-protocol hardware is more open to a wider array of attacks. But thanks again.
The principle I keep in mind here is that the implementation is the weakest part of crypto and has the most room for error. For me personally, it requires too much time and energy to roll my own, especially knowing I’ll likely screw something up. If it was a side project, slightly different, but I want something I can forget about for a year and come back and it just works. In my case, the risk of an overly complicated setup locking me out is higher than any risk from using yubicos hardware and setting things up.
But I would start with getting a key, playing around, and doing what they other commenter suggested.
When shopping for a suitable device you look for OpenPGP compatibility on the list of features. You can even still get it in smartcard format[1]. Integrated USB devices like the YubiKey that support OpenPGP are effectively emulating a smartcard and a USB smartcard reader.
[1] https://www.floss-shop.de/en/security-privacy/smartcards/13/...
If it’s plugged into a networked system, it's not air-gapped. And if an air-gapped system is connected to any device which has previously been connected to a non-air-gapped system, it's no longer air-gapped.
I hate to nitpick, but this is really, really important.
Every air gapped system has the weakness that you have to eventually get material on and off the system. That connection can be used to attack the air gapped system. The smartcard interface used here to isolate the systems might be considered weaker than other methods but it is intended to provide this sort of isolation.
No, an air gap means that there is a gap of air between the system and any insecure network. By definition, a YubiKey plugged into a networked laptop is not airgapped because there is a direct electrical connexion to the laptop’s USB controller, which has either an electrical or an RF connexion to one or more networks.
> Every air gapped system has the weakness that you have to eventually get material on and off the system.
I really think that you misunderstand what an air-gapped system is. A desktop not connected to a network is an air-gapped system, and can be very useful. For years we computer enthusiasts used non-networked — air-gapped — computers and loved them. An air-gapped desktop publishing system would be very useful for producing samizdat in a repressive regime, for example. I imagine folks did exactly that in the late 80s in the Soviet Union. In my youth, all video game consoles were air-gapped, and they were very useful.
There is no "air gap" in your sense between say a Sega Megadrive and Google's servers, they're both wired to the electrical grid. But you (not unreasonably) disregard that. In contrast there is technically such a gap between my laptop and Google's servers, because it's running on a battery - however thanks to WiFi it certainly isn't "air-gapped" in the sense we usually mean.
Security Keys are indeed often electrically connected (via a USB port) but the design insulates this from the key management problem so in effect they are air-gapped. Any attack that crosses that gap might equally have worked by shining a laser at it through a window, or holding an electromagnet near it.
`PKCS11Provider /usr/lib/ssh-keychain.dylib`
This kind of knowledge is proximate to my own line of work, but I think it could be frustrating for others that have no such alignment.
These days I use the FIDO support. It is much simpler, but software support is a bit on the bleeding edge. You don't get to amortize a GPG toolchain in for commit signing or anything like that, though.
If I am in a small company, I can give everyone a yubikey and have some process that verifies everyone.
Now I want to eliminate cookies / sessions keys. (just go with me). I want to use client certificates - but I only trust the yubikey.
I am noodling ways that I can generate client certs, install them fairly easily and sign them with the yubikey.
The goal here is that client certs are a really good idea- every request can include one, as opposed to every request including a session cookie / nonce that is open to interception / playback etc etc.
And now we have billions of hardware security modules (am including secure enclaves in phones) - so there really ought to be a way through here.
My problems include "generating client certs client side" - not something many browsers support and signing that in some sensible fashion
But is all seems quiet possible
The UI for client certs in browsers are miserable, terrible, horrible and insert every other awful adjective you can imagine. Seriously, it's so broken as to be unusable. Everybody knows it, nobody wants to fix it.
see: https://textslashplain.com/2020/05/04/client-certificate-aut...
With a client certificate the end server knows, you don't need to fuck around with cookies and TLS binding and so on. Add a new end point - great to use that during your "session". it just works.
One day I will work it out.
FIDO2 is arguably a much better way to deal with this provable identity problem. The UI for FIDO2 has been worked out and is good enough, etc. The big problem is, it requires handing people Yubikeys(or similar devices).
Instead of generating client certs client side, generate a elliptical curve key pair who's public key you sign with the yubikey and send to the server. Then, sign every request with that key and the server can verify it using the public key sent previously. All that can be done in js, without a jwt or sending anything other than a request and signature. It's essentially a client cert.
I still don't really understand how much more security it'd get you than bog standard webauthn, especially considering it'd be a custom, less tested system, but you can already do something similar to your idea using standard cryptographic primatives.
It appears to me there are two options :
use out of band method to verify a HSM "belongs" to a given person (which has loads of issues) then
1. Use that HSM to establish a bearer token for future requests
2. use that HSM to establish a client certificate which at least avoids the problems of bearer token.
I may of course be very wrong.
PS To me the problems of "replacing passwords with something stronger" boil down to the fact that the vast majority of web sites out there are not protecting anything valuable. I have 300+ entries in my password vault and if I had to walk down the street to a "PKI office" and get my passport stamped to access each one, I would choose maybe five.
I suspect that the vast amount of crap sites out there trying to find ways to make authentication stronger without actually making it less convenient for people i case they stop bothering to sign in, is just undermining the infrastructure we would need to have trustable authentication.
If it's valuable to you, you will make the effort.
Also, sops (https://github.com/mozilla/sops) works with gpg and so with Yubikeys.
Too bad that there is no flow diagrams of how all physical object connects.
Or key objects relates to each entity being transitioned.
It’s a lot of reading and typing as you go before something clicks in one’s head.
We still use it for SSH and its great!
If someone steals the key, they can't really do anything with it. They can't sudo because the session is locked. They can't use it to log in your web accounts from other computers because websites ask for a password/pin in addition to touching the yubikey.
PS: you should always have a backup yubikey (or, better, two)