I just recently started using my Yubikeys (in Challenge-Response mode) w/ LUKS to unlock my drives at boot -- it's pretty neat!
On my primary system (a workstation, at home), I use the Yubikey to house my GPG keys and I use the "derived" SSH key that lives inside of it for authenticating to everything at $work. It was a bit of a PITA to get working -- points at gnome keyring -- but it works great. I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently.
> I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently.
Do I misunderstand the purpose of a Yubikey/U2F device here? Is not leaving it plugged in permanently effectively reducing the strength of the second factor?
With TOTP codes behind my iPhone lock screen I can be reasonably confident that stealing my laptop isn't enough to break into my accounts (buying time until I can contact our SIRT team), but with a device plugged in permanently I lose that. Obviously an attacker would have to know my password, but that assumption is a primary reason for multi-factor auth to begin with.
I believe its like using it as an HSM; keys are protected against a remote intruder copying them, but physical access is another issue - you should still use it in conjunction with something-you-know, then it doesn't matter if the laptop is stolen.
Leaving it in permanently is mostly for convenience. The keys are still protected (by a "PIN") even if the laptop and/or Yubikey is stolen. There's also FDE on the laptop itself, protecting the data.
This is important. Physical action outside the computer should be required to access keys, otherwise a root access is enough to completely compromise the system.
Where by "completely compromise" you mean "an attacker can use your second factor while they have access to your computer and it's plugged in", which is pretty far from actual complete compromise (i.e. "an attacker can use your second factor at any time without needing to access anything of yours")
No. He still needs the PIN to actually use the Sign-Key. However that can be key-logged if your computer is compromised, so the extra 'touch' does add quite a bit of security.
The U2F needs touch by definition anyway. GPG/PIV do not, this capability was added with the Yubikey 4.
Imagine an employee works for a company where they can log into the company network with just a password (or alternatively, just an SSH key or TLS certificate). If an attacker gets their hands on this credential, by any means, then the attacker can use that credential to log in. These kinds of attacks can happen remotely in a variety of ways. Phishing is just one way. Malware is another - perhaps the employee downloaded apparently legitimate software that had a credential stealing trojan within it (e.g. keylogger or SSH key slurp). Or maybe the employee used their same password at another website that's been compromised, despite being told not to. Or maybe the password is just a bad password and the attacker brute-forced it.
An attacker who gains sufficient access to the right system can obtain your employee's credential, copy it, take it elsewhere, and use it later. They could use the employee's credential months later from anywhere in the world, and you could have difficulty identifying exactly how the credential was compromised originally, especially if time has passed and the attacker covered their tracks.
Now imagine a different employee who works at a smart company where logging into the company network (and accessing all company systems) requires multi-factor authentication using U2F or OTP in addition to a password. The attacker might be able to steal the employee's primary credential, through whatever means, but they have absolutely no way to obtain the employee's U2F or OTP codes remotely and electronically. The attacker simply cannot get into the company systems without having access to the MFA. This substantially raises the bar for a successful attack, and provides a great defense against attacking the company network and systems.
Yes, it's true that if you leave your MFA token in your laptop, then you could misplace your laptop and lose the token with it. In that scenario, though, the random attacker who discovers a random laptop in a cafe by chance won't know who it belongs to, or what company, and won't know the owner's password. Security is still preserved. The most plausible bad guy will sell the laptop to a pawn shop, not try to attack the owner's network. Furthermore, the employee should have been trained to call the IT helpdesk as soon as they realized their laptop and token were missing, cutting down the window for a successful attack.
To mitigate the risk of random loss, you'll want to employ full disk encryption, and disable the username auto-fill. This way an attacker can't get anything from the device without signing in, and has no information about whom it might belong to. Employ a policy that locks the screen after a few minutes of inactivity to make it difficult for attackers to swipe idle but still signed in laptops. These precautions all together make it incredibly hard for an attacker to get in the front door.
The only scenario in which security is compromised is if the employee's login credential has been compromised, and the same attacker has also physically stolen their MFA token. An attacker that is actively attempting to steal physical belongings from you in order to penetrate your organization is getting into Hollywood spy movie stuff. It's a real life concern for people doing certain types of work, to be fair, but those people usually mitigate the concern by keeping their equipment in secure facilities, and not taking their laptops to cafes to begin with.
If the adversary gets root access to the workstation, they can verify at will. Removing the key, even just to place it next to the screen, prevents this to some degree and only allow the verification to happen while you're using the computer.
But I still believe that proper 2FA require you to physically push a button on the YubiKey for it to give out keys. That enables you to control completely when it provide keys.
I use a smartcard with an RSA key with a LUKS-like format to encrypt my disks -- uses AES256-XTS for the actual dm-crypt, the smartcard's key is used to encrypt the symmetric cipher key.
gnome-keyring replaces gpg-agent and ssh-agent (on the system) but doesn't actually include all the functionality... basically, disable GPG/SSH agent support in gnome-keyring (if it's running -- and it's quite often automatically launched, even if you aren't aware of/expecting it), and explicitly use the real agent instead.
You can find the details on Google, but it's one of things that you wouldn't even know was a problem to be aware of.
Edit: Sorry... for LUKS, write a custom initramfs hook (shell script, in my case) to prompt the user for a "passphrase", use that as the challenge sent to the Yubikey, read the response from the Yubikey, write that to /crypto_keyfile.bin (in the initramfs, so not on disk), and the "encrypt" hook should use that file as the key to unlock the disk. You'll have to do it by hand once so that you can add the key (response) to a slot in LUKS. There's examples on Github of this but of course I didn't find them until I had already figured it out myself.
On my primary system (a workstation, at home), I use the Yubikey to house my GPG keys and I use the "derived" SSH key that lives inside of it for authenticating to everything at $work. It was a bit of a PITA to get working -- points at gnome keyring -- but it works great. I have a Nano I'm about to set up the same way and just leave it in my primary laptop permanently.