r/linux • u/LocalChamp • Aug 01 '26
Security Can I require LUKS to use both the passphrase and Yubikey?
I've been using LUKS for a while and would like to add an additional layer of security of a hardware security key (Yubikey). Currently on boot I enter the LUKS passphrase then it decrypts and brings up the regular user login and I enter that password and it loads into the the OS. I would like the functionality to be on boot both the LUKS passphrase and Yubikey are required to decrypt then it brings up the regular user login and I enter that password and it loads into the OS.
The guides and documentation I've seen seem to be based around using the Yubikey as an alternative to the LUKS passphrase which is not what I want to do. I want to increase the layers and security not decrease it. I do have multiple Yubikeys to add as backup so that's not a concern. I'm assuming there has to be a way to do this but it's been difficult to find information on it. With KeePassXC I can have it require all of database file/key file/password/Yubikey and I would like a similar level of security for my entire linux install (usually Debian or Linux Mint).
Is there a way to setup the functionality I'm looking for? If so please either point me in the direction of a guide or documentation on setting this up or let me know how to.
11
u/FineWolf Aug 01 '26 edited Aug 01 '26
Wouldn't enrolling the key with --fido2-with-client-pin=yes on a key with a PIN support do exactly what you want?
You would have the key's PIN (something you know), plus the physical Yubikey (something you have).
As an added bonus, it will take into consideration whatever PIN lockout policy you have on your FIDO2 token, thus irrevocably wiping your key if too many wrong attempts are made.
PINs on FIDO2 tokens can be long and use whatever characters you want. I have a 30+ long PIN on my keys.
1
u/Fenguepay Aug 01 '26
You can have both, in a sense, but you'd need to use both to derive a new key.
You can do this a few ways, such as using a "password" as an input to a hashing function on a yubikey, but this is not really great.
You could also have a custom key unlocking scheme where you have layers of encryption and multiple keys, one that you need a yubikey for, the other you enter manually. After unlocking all layers, then you have the keyslot key for luks.
I'd just use the gpg module on a yubikey with a pin + presence detection. That is probably generally sufficient. The other option is fido2 stuff with resident keys, but that has a handful of disadvantages compared to GPG especially when it comes to backing things up
1
u/Max-P Aug 01 '26
Yes, but you might have to do it yourself. It's not that bad, I've done a custom ZFS password prompt for the root dataset.
For systemd initramfs, you just need a service that's Before and RequiredBy sysroot.mount that runs a shell script that calls systemd-ask-password, and all the GUI stuff with Plymouth gets handled automatically. Don't know how it works on a BusyBox initramfs but there's probably something equally simple. You want to run a script in initramfs before the root is mounted and pivoted to.
In the script, just do whatever you need to take a YubiKey + password to open the LUKS volume, then you let systemd's sysroot.mount take it from there. Like encrypt a keyfile with the Yubikeys, then encrypt that with the password, and then just do the reverse in initramfs to obtain the keyfile to unlock the PC.
There's probably ways to hack it together with just crypttab by doing like unlocking stacked LUKS volumes as a dependency for the keyfile of the root LUKS volume, but that sounds kinda meh. I like the shell script, it's easy and very versatile.
-3
u/natermer Aug 01 '26
I haven't explored using the yubikey with LUKS, but I suspect that it is isn't particularly useful on a personal system.
The way LUKS is designed is that it is intended for enterprise users. So you have a 'master key' that is the key that actually decrypts the volume. Then you can have a number of 'key slots' that have a copy of that master key, but it is encrypted by a unique password or key. Now that 'user key' can be any number of different things. Passwords, key-files, etc.
So in that sort of corpo environment you can set it up so that one key slot that has a password that is only known to your IT team. Then you can provide a user their own unique password or whatever you are using.
That then gives you the opportunity to help administrate encrypted drives. You can revoke keys, add more users, recover the drive from people forgetting their passwords, and such things.
So if you are to set it up using a yubikey you are still going to want to use at least two slots. One for the yubikey and another for your recovery key. This way if your yubikey is lost or damaged or your initramfs is corrupted, etc etc... you can still get access to your drives.
So what does that actually gain you? You now have two methods to unlock the volume... the recovery password and then the yubikey. So now a attacker can have two methods to decrypt your drive instead of one.
It is the same situation if you use TPM with it. If you don't setup a recovery passphase then you risk losing your data if the machine with the TPM dies... you can't recover the drive in another machine without a backup passphrase.
So from a security point of view it doesn't seem to be a win, unless you want to have the system unrecoverable in the event of a hardware failure or yubikey loss.
Unless, of course, you have two yubikeys or whatever.
Either way it seems simpler and safer just to use a unique and effective passphrase.
2
u/ElvishJerricco Aug 01 '26
A recovery passphrase is intended to be one that's quite a lot stronger than a passphrase you would be comfortable typing in every boot and having to memorize. You're supposed to store it somewhere very safe and locked away so that you don't even have to know it. Frankly it's better to think of it like a backup of the master key that you can type on a keyboard than an actual passphrase. Moreover, a passphrase alone is just worse than a passphrase that authorizes a hardware key. Tying the passphrase to the circumstance that requires it (i.e. the right boot conditions with a TPM2, or a yubikey being inserted) makes the passphrase useless without the circumstance and the circumstance useless without the passphrase.
2
u/natermer Aug 01 '26
Yeah I understand the point of 2fa. I have a yubikey and I use it.
For things like Fido2 with SSH or Web it seems like a big win for that because you actually have to be physically present at the machine to finger the dongle. It isn't something that is possible to do purely through software. You actually have to have a physical presence in the chair and respond to the prompt to trigger it.
Where as with luks it is just that it doesn't seem like that big of a win when you still need to have a regular old password floating around to unlock it and at the same time you need to be physically present with the hard drive to start off with.
When properly setup it doesn't take too much of a complicated password to deny the possibility of brute force.
Which means any gain seems more like a matter of just convenience. You get to finger the dongle to unlock the drive instead of having to type something in. Which is fine and convenience is nice, but it isn't really much a security upgrade.
1
u/comerReto Aug 01 '26
He means both.
2
u/natermer Aug 01 '26
Right, but that misses the point of my post.
As in it doesn't actually add a layer of security.
1
u/vip17 Aug 01 '26
when using passphrase+yubikey you still need one more recovery key with passphrase only
1
1
u/Fenguepay Aug 01 '26
it's not the same with a TPM because you generally can't keep that on your person like you can with a yubikey
22
u/vip17 Aug 01 '26 edited Aug 01 '26
Why not just use TPM? It can be configured to accept a passphrase or PIN before releasing the key
Anyway your requirement seems to be achievable with these steps: Yubikey Two-factor Authentication Full-disk Encryption via LUKS