Which approach do you think is better, and why?
Or do you think there is an even better way to use a hardware security token to unlock drives having LUKS full disk encryption?
I try to follow a multi-factor, multi-domain model.
So if I am wanting to verify that data is on the system I except it to be then TPM keys and measured boot is what I use. To verify it is on the network I expect I use a Tang server. To verify I have possession of a device I use, a hardware token and password.
You could do all the above, or mix match depending on the system. For example for servers I assume they need to boot without user intervention, so password is set as backup to the Tang server. I still use hardware token to buy just for quick revoktion of verification (i.e. I know a server is compromised or could be soon, I can just pull a USB out).
The same setup works for my laptops, which makes my network because of Tang act as trusted domain as well.
So again multi-factor (something you have, know, are, do) and multi-domain (network, user, machine).
I use Clevis to do the multi-key unlocks.
Progress report 1
- I’m ruling out HMAC-SHA1, because:
- Plain vanilla HMAC-SHA1 uses a shared secret. I don’t want the PC/server to have a copy of the credential. May also be susceptible to MITM/relay attacks.
- Rolling-code HMAC-SHA1 only partially solves those problems.
- Encrypted rolling code HMAC-SHA1 solves those problems, but I haven’t found a reliable source for using it with LUKS.
- If using
systemd, pick FIDO2:- Avoids flaws of HMAC-SHA1.
- Native support in
systemd, so “future-proof”. - Wider support than OpenPGP. More HST vendors to choose from, including cheaper options than NitroKey or Yubikey: useful if each sysadmin (or colleague, or relative) needs an HST.
- Compatible with QubesOS.
- Otherwise, OpenPGP:
- TBD: Clevis/Tang:
- Remote/network-based unlocking.
- I’m ruling out HMAC-SHA1, because:
Thank you for this! That thread is helpful in itself, and also links to other relevant resources - including by Lennart Poettering (controversial guy, but the canonical source on systemd).
wouldn’t doing this require that building a ram disk image with the yubikey software included?
All 3 mechanisms are native to a yubikey, and do not require yubikey-specific software/drivers to function as they use USB standards like FIDO2, keyboard for HMAC, and PIV/CCID for OpenPGP.
FIDO2 is built-in out-of-the-box, HMAC just requires adding the key to HMAC on slot 1 or 2 (tap vs long-hold key-inputs) using the personalization tool, or using gpg(2) to card-edit for OpenPGP.
None of these require YK software to operate.
Which of the 4 recipes I posted are you referring to as “this”?
read them and you will see that only ones mentions initrd at all.
I read them before writing my OP. I’m still not sure what you’re getting at.
I would be grateful if you could say what you mean, instead of initiating an oblique guessing game.
instead of initiating an oblique guessing game.
i don’t understand the hostility.
i asked a question about needing yubikey software in a ramdisk image to enable decryption at boot time and most of the sources you provided don’t mention it at all.
i don’t understand the hostility.
Bystander observation: you were asked to clarify but essentially refused in a way that took more effort than simply doing so.
Oic. They didn’t understand that I was asking a question and thought that I was addressing one of their links
Thanks for helping clarify.
It’s not mentioned because it’s not required, yubikeys in general mostly leverage pre-existing “smartcard” facilities
