3

I have the following LUKS partitions:

root@precision:~# blkid | grep crypto_LUKS
/dev/nvme0n1p3: UUID="e1ac241d-a91c-4386-9b08-752dc5d0e9b8" TYPE="crypto_LUKS" PARTUUID="91fc5b71-7c22-4e3e-821d-7116a5a46f7e"
/dev/nvme0n1p4: UUID="23c3618e-be44-42f0-812b-bee1b0ac8dfe" TYPE="crypto_LUKS" PARTUUID="a6caf1e1-6ceb-4287-a2e2-45e4bbf1cec1"
/dev/sda1: UUID="396463ed-16f8-4f77-808d-743f35eaa4cb" TYPE="crypto_LUKS" PARTUUID="1cec189b-c43b-4094-a9f2-47d8f589c6d8"

Trying to setup Yubikey 2FA as per:

I run the following script three times, each time changing the target disk within the script before doing so. Each time I sent the same passphrase "123456"

I then check the slots on each of the crypto LUKS disks and see that Slot 7 is ENABLED:

root@precision:~# cryptsetup luksDump /dev/nvme0n1p3 | grep Slot
Key Slot 0: ENABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: ENABLED
root@precision:~# cryptsetup luksDump /dev/nvme0n1p4 | grep Slot
Key Slot 0: ENABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: ENABLED
root@precision:~# cryptsetup luksDump /dev/sda1 | grep Slot
Key Slot 0: ENABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: ENABLED
root@precision:~#

Problem:

When I reboot the Yubikey 2FA appears to unlock nvme0n1p3 however /dev/nvme0n1p4 and /dev/sda1 drives don't get unlocked and I need to enter the LUKS passphrase.

When not using the Yubikey I can enter the LUKS passphrase just the once and all drives are unlocked.

Greenonline
  • 2,081
dross
  • 193

2 Answers2

2

As an alternative to the Yubikey-specific implementation yubikey-luks, you can use the FIDO2 standard (Yubikey 5+, other brands) together with systemd-cryptenroll to unlock LUKS2 volumes.

It is said that FIDO2 "just works", even when using the same authenticator for multiple LUKS2 disks or for other purposes. (This may be simply because compatible smartcards come preconfigured for FIDO2.)

Below are minimal steps for the disk sda5 and the LUKS2 volume myvolume.

systemd-cryptenroll --fido2-device=auto /dev/sda5

Also edit /etc/crypttab to include the option fido2-device=auto in the fourth column.

myvolume /dev/sda5 - fido2-device=auto

Optionally configure, for example, user presence verification which requires touching the Yubikey to unlock.

Several authentication standards are supported by systemd-cryptenroll.

  • FIDO2, with the hmac-secret extension. Supported by Yubikey 5+, and several other brands.
  • PKCS#11. For Yubikey this requires configuring Yubikey PIV/certificate slots. (Similar to using Yubikey slots for HMAC-SHA1 used by yubikey-luks.)
  • Trusted Platform Modules 2.0 (TPM2) support. Uses a TPM2 chip, which basically is a builtin system smartcard.

See more details in Lennart Poettering's blog post Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248 from 2021-01-13. See also related ideas, such as separating system and user home directory encryption and immutable operating systems images.

Note that systemd-cryptenroll support is fairly new, and not all distributions/versions have enabled all features by default. On my Ubuntu 22.04.1 LTS system:

systemd --version

systemd 249 (249.11-0ubuntu3.6)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

Note that +LIBCRYPTSETUP and +FIDO2 are enabled, but also that -P11KIT is disabled.

Joel Purra
  • 202
0

Perhaps your disk setup script accidentally resets the Yubikey?

The steps in the linked question's answer from @seanlano explain that the Yubikey's second slot only needs to be initialized/programmed for HMAC-SHA1 once. If you run the Yubikey slot initialization ykpersonalize command during the setup for each disk, you will overwrite the Yubikey slot's secret key that you used during the previous disk setups.

3. Initialise Yubikey Slot for HMAC-SHA1

Now we need to program the second slot of the Yubikey with a HMAC-SHA1 configuration. This will erase your previous slot configuration, which is empty by default. Again, if you are using HMAC-SHA1 for something else do not issue this command - it will erase your configuration. You can safely use the same secret key inside the Yubikey for this LUKS setup as for your other uses. (For example, with another computer using LUKS+Yubikey).

ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible

The solution during initial setup is to not reprogram the Yubikey slot each time -- once is enough for all disks.

To fix this, you can reset LUKS' slot 7 on each disk, replacing any previous credentials stored there. This is also covered in @seanlano's answer. Since you already have setup your Yubikey, only one command per disk is required.

With the setup given in your question, these are the yubikey-luks commands. Make sure to adjust it to your current setup, if it has changed since, as this will remove your current credentials for that LUKS slot.

sudo yubikey-luks-enroll -d /dev/nvme0n1p3 -s 7 -c
sudo yubikey-luks-enroll -d /dev/nvme0n1p4 -s 7 -c
sudo yubikey-luks-enroll -d /dev/sda1 -s 7 -c
Joel Purra
  • 202