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.
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.
It’s not mentioned because it’s not required, yubikeys in general mostly leverage pre-existing “smartcard” facilities
Progress report 1
- I’m ruling out HMAC-SHA1, because:
- Plain vanilla HMAC-SHA1 uses a shared secret. I don’t want the PC to have a copy of the credential. It may also be susceptible to MITM/relay attacks.
- Rolling-code HMAC-SHA1 only partially solves the problems of ordinary HMAC-SHA1.
- 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:- It avoids the flaws of HMAC-SHA1.
- It’s supported natively in
systemdso should be “future-proof”. - It’s a more widely-supported standard, than OpenPGP, with more HST vendors to choose from, including cheaper options than NitroKey or Yubikey. This could be useful in environments where each sysadmin (or colleague! or family member!) needs an HST.
- It’s compatible with QubesOS.
- Otherwise, OpenPGP:
- TBD: Clevis/Tang:
- Permits remote/network-based unlocking.
- I’m ruling out HMAC-SHA1, because:
