Yes, they do - but it requires both client support and server support to work. Older servers can’t do it, and for example the provided openssh version with windows doesn’t support it either. And adding GPG keys to a yubikey may be interesting to people using pass or similar password managers.
Certainly, but if both server and client supports it (Ubuntu has shipped with it by default for a few versions now), it's much, much easier to use it instead.
> "Normal" SSH keys will work for (pretty much) all systems that support SSH.
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.
Yes, the practical impossibility of recovering a private key from a security device is a feature. This implies you can't change security devices without changing public keys.
Yeah, I just didn't know how it works; didn't know it was stored there, but assumed it was just encrypted with the secret in the key, i.e. in the presence of the old and the new security key, it could be decrypted and re-encrypted with the new one.
Not every Yubikey supports the resident keys. All my Yubikey 5 keys have too old firmware, which AFAIK cannot be updated, so this is not a viable solution for lots of people even if they own the hardware. GPG just works, and can be used for many other things while one's at it already.
Absolutely. We're trialling this for our SSH bastion server. The security keys don't need any setup at all, which makes it much easier to handle backups and replacements.
Let me rephrase: GPG is possible to get working, the resident keys are not, regardless of the amount of setup. Though the other comment seems to suggest it might not be the case, so maybe there is hope.
You should be able to just use a website that uses resident keys (such as Microsoft Passwordless login). I don't think the UI is any different, it's just that the key will actually get stored on the device.
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.
- 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 didn't mean my comment as criticism of the guide, just to say that the method it uses is very complicated, and that there's a simpler one. If you can't use the simpler one, this is a great guide!
Note that the linked guide describes the cruise/air/tilt version that includes a master identity scheme. Most people don't need to do something as complicated as all that and can just use the defaults for everything and in the end dump the private keys to the device.
Backing up the secret key material is still an issue with FIDO2.
I think idea is that you don't backup secret key material.
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.
In PGP land it makes a lot of sense to back up your secret key material. That is because the passphrase that the user enters encrypts the secret key material. So a strong passphrase means you can backup that key anywhere and everywhere ... and probably should.
Having a strong passphrase makes things a lot simpler. A classic convenience vs security tradeoff...
I disagree with the recommended key generation flow in this guide. I think the private key should be generated on-device, so it can never be extracted without faulting the YubiKey hardware.
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 also disagree with the idea of backing up the private 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.
A vast majority of people should create paperkeys. I will just note that if one creates a paperkey by printing it out, they are transmitting their secret key over the network to likely an internet-connected printer that also sometimes stores documents in its cache for a while.
>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.
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.
I did exactly this minus the backup key. Problem is that the backup is nearly meaningless since it is just a second totally different key. For most services that is fine as they allow to setup multiple keys (GitHub, Gitlab, etc). But some services don’t. My first Yubikey is partially broken. I only wait for the day the usb connector breaks out. I already have new yubikeys and it would be awesome to just put the same key on them to have no fuss.
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.
Unfortunately it does not look like the security key industry has caught up to the hardware wallet industry.
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’ve tried both. Unfortunately the U2F as well as the PGP are clearly afterthoughts on these devices - the key management is lacking (doesn’t tie in well with the recovery phrase otherwise used for crypto assets) and the UX is cumbersome.
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.
Unfortunately I don't think anyone has done this yet.
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 have been using this setup for about three years now and it works very, very well. It's useful for GnuPG (so, encrypted backups), SSH and 2FA for multiple websites. I highly recommend this setup.
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.
Could someone explain, all hardware based around FIDO2 and U2F standards is equally compatible with software right? Put another way, Yubikey, Solokeys and others based on those standard should be equally compatible with gmail, SSH, VeraCrypt, sudo etc. and so interchangeable, is that correct?
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?
The stuff the article is talking about is based on the OpenPGP smartcard standard, not FIDO2 or U2F. Basically what is happening here (when thought about in messaging terms) is that the YubiKey is being used as a portable air gapped system.
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.
> … the YubiKey is being used as a portable air gapped system.
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.
Well, it is an air gapped system that depends on a possibly insecure input and output device. The decryption and signing is done exclusively on the device under the physical control of the user. No one has access to the secret key material, not even the user.
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.
> Well, it is an air gapped system that depends on a possibly insecure input and output device.
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.
Right but, did you spot that in your answer you allowed for a situation where there isn't actually that gap of air at all, just because it felt intuitively reasonable to do so?
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.
The FIDO2 two factor auth portion is pretty seamless. It’s plug into USB port when the two factor prompt comes up, it will light up, touch the button, and good to go.
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.
Okay, sorry if this is obvious. So FIDO is intended for authentication on the web/cloud only (and requires compatibility from both the website/site and the browser to work).
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?
This guide mostly isn't about FIDO. It's about the however many other features a Yubikey carries. One of those fancy pocket knives with sixteen tools is also a bit of a handful to work with, and if you've used one and relied on its specialist tool for cracking walnuts, you may be disappointed by a cheap four way multitool that does not crack walnuts. However, it would be wrong to say "Why are knives so tricky to use?" when it's not really the knife's fault.
I’m by no means an expert in this area (and expect someone here could speak to it better than I can), but the Yubikeys have a lot of capability.
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.
Sounds like a good option. I've been finding it hard to understand how this all fits together. For example, which of the standards listed above is the mechanism used to unlock a PC or a mac? Which one applies to allowing sudo?
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)
It’s not easy and there may be a solution out there that I’m not aware of, but yubico met my needs (and Feitan) so I stopped.
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.
For your "Unlock a PC" need you may be looking for the FIDO optional feature hmac-secret.
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.
That (a feature name) is what I'm talking about. Thanks a lot.
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.
Just discovered that macOS supports Yubikeys in PKCS11 mode natively now. So no extra libs, like OpenSC needed and it works very stable (no repeated PIN requests). Lib and config line in .ssh/config is just:
I used this set-up for about a year. It was fine, I even used it on Windows, Mac, and Linux. I found that you'd definitely have to know way more about the principles of the ssh-agent system and smartcards (and GPG's need for a long exclusive lock on the card to cache safely) once in a while to avoid getting stuck, especially since other parts of the operating system or, on Windows, multiple usable implementations of SSH (e.g. one via MSYS, one on win32/native, one in WSL1, or one in WSL2) may be involved. Learning this on Windows was especially "fun."
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.
Silly question: (I have been meaning to dive deeper on this but ...)
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
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.
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.
eh. Client certs are better in theory. Client certs have lots of complexity that's not necessarily easily solved. If you control both ends, then most of the complexity is easily solved, but if you don't, then client certs get much harder.
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).
You may be able to go the Webauthn route instead. It won't completely eliminate sessions, but you could instead sign short lived JWTs. The main benefits would be the ability to use any compatible device (ios and andriod natively support it backed by a secure enclave) and the ability to attest that the authenticating device is from a trusted manufacturer, such as Yubico, Apple, Google, etc. I'm not sure if it's possible to sign a request without user input, but if so, you could include a signature with every request.
I cannot trust JWTs - look the maximum I want to send from a client to a server is a single nonce. Anything else is just adding attack surfaces. Add that one 128bit number has too many already :-)
What in the world is your threat model? You need some concept of sessions somewhere, even if it's just a list of which client certs (aka sessions) are valid in case someone looses a yubikey. Those certs should also be short lived, since they don't live in the yubikey itself. And a TLS client cert absolutely adds more than just a nonce.
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.
I am guessing you are suggesting this as an absurdist argument (even if it is feasible !?!!) but I don't get why using client certs is bad? The downsides to session keys in cookies is immense and I don't see JWTs as being materially different.
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.
Is there a way to encrypt a file with a Yubikey? I want to encrypt a GitLab token in a file that can only be decrypted when I tap my Yuibkey. Maybe I’m just being dumb, but I haven’t found a straightforward way to do it
With GPG you typically use assymetric cryptography, so you would be using the public key of the recipient, so you don't need the yubikey for that. However, the yubikey can be used when decrypting the message later.
Yes it's possible ( https://www.ha-obsession.net/2017/05/u2f-sudo-fedora-25.html... and some other guides exists ) and I used it for about a year. I stopped using it. I was so annoyed to plugin the key every couple of hours that I simply kept the yubi key plugged in all the time - free to be picked by anyone and def. not increasing security.
Leave the yubikey plugged in all the time. It's fine with respect to most threat models, provided you lock the graphical session when you are away from the computer.
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)
You can also set the yubikey to require a pin before touching. The yubikey auto wipes it’s memory of the presented pin is wrong too many times in a row. So just leaving it plugged in is much more sensible in that case.
https://www.stavros.io/posts/u2f-fido2-with-ssh/