Talk:Universal 2nd Factor

Data-at-rest encryption with LUKS

I propose the following change to the Data-at-rest encryption with LUKS section. Torxed (talk) 08:59, 18 May 2022 (UTC)

I don't see a point to the warning. It is not possible to unlock the root volume from /etc/crypttab on real root. Also the (rd.)luks. vs crypttab issue is out of scope and duplicates dm-crypt/System configuration#Using sd-encrypt hook. -- nl6720 (talk) 10:37, 18 May 2022 (UTC)

Fair points, but I'm not sure it's clear tho that having a /etc/crypttab entry would cause issues. At least that is news to me, since with sd-encrypt from my understanding systemd is used to load all the encrypted volumes. To quote dm-crypt/System configuration#crypttab "crypttab processing at boot time is made by the systemd-cryptsetup-generator automatically.", this eludes that any filesystem can be mounted. Also /etc/crypttab.initramfs is mentioned to be baked into initramfs which indicates that perhaps instructions on how to unlock root can be made. /etc/crypttab.initramfs is mentioned frequently and I think it would make it more clear and remove potential issues if there was some mention of these behaviors. The place and wording might be wrong, but it would be a benefit to mention it. I spent a couple of days on this issue and this is something I felt would have cleared up some of the issue. But if that's not the general consensus so be it. But in such a case I would like to argue strongly that the mention of libfido2 stays, because that was highly unclear. Torxed (talk) 11:21, 18 May 2022 (UTC)

There's no issue with having libfido2 installation instructions, but those do not warrant a note. Simply instruct to install the package, see Help:Style#Package management instructions.

/etc/crypttab is parsed after switch root, but the root volume (and also the swap volume when using hibernation) must be unlocked and mounted before that, i.e. in the initramfs phase. The rd.luks and luks kernel parameters are an alternative to crypttab, that's why they conflict in certain configurations.

IMHO it would be best to leave only the systemd-cryptenroll commands here and place all crypttab and rd.luks stuff in dm-crypt/System configuration. The same applies to Trusted Platform Module#systemd-cryptenroll.

-- nl6720 (talk) 12:04, 18 May 2022 (UTC)

Draft

Since version 248, systemd can be use to unlock a LUKS partition using a FIDO2 key.

First, you will need to setup your /etc/crypttab file, or customize your initramfs if you wish to unlock your root partition. The full procedure is similar to the use of a TPM chip for unlocking. See Trusted Platform Module#systemd-cryptenroll.

Note: libfido2 is required before a new initramfs is generated.

Warning: If you intend to unlock the root partition, /etc/crypttab might cause systemd-cryptsetup@.service to fail. In which case setting rd.luks.* or luks.* kernel options and omitting /etc/crypttab is required.

Note: tpm2-device kernel option will override fido2-device kernel option. Use one or the other.

To register the key, you will need to use the systemd-cryptenroll utility. First, run the following command to list your detected keys:

$ systemd-cryptenroll --fido2-device=list

Then you can register the key in a LUKS slot, specifying the path to the FIDO2 device, or using the auto value :

$ systemd-cryptenroll --fido2-device=/path/to/fido2_device /dev/sdX

Then proceed to generate a new initramfs with libfido2 support unless already done.