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.
It’s not mentioned because it’s not required, yubikeys in general mostly leverage pre-existing “smartcard” facilities
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.
