Hi all,
I’m trying to configure single-password two-factor PBA with a YubiKey for two LUKS-encrypted internal drives—fairly standard, with the slight exception of the YubiKey.
The setup process is well documented for single-drive machines. Likewise, single-password multi-drive LUKS setups without the YubiKey are also quite common. My goal here is to bridge the gap with a single-password multi-drive YubiKey-based setup.
Setup
I initially followed the excellent guide in the wiki for a single-drive installation. Then, I partitioned the second drive (to be used for data storage) using the same procedure, so now it also has an unprotected ESP (along with a copy of the /crypt-storage/default file containing the same initial salt and iteration count) and a LUKS container (created using the same password and initial salt).
Attempt 1
First, I tried to bypass the second drive’s ESP altogether and instead generate the challenge for both LUKS containers using the /crypt-storage/default file stored on the first drive’s ESP like so:
boot.initrd.luks.devices."root-crypt".yubikey.storage.device = "/dev/disk/by-uuid/${ROOT_ESP_UUID}";
boot.initrd.luks.devices."data-crypt".yubikey.storage.device = "/dev/disk/by-uuid/${ROOT_ESP_UUID}";
The result: at boot (with the YubiKey inserted), the password prompt appears for the first LUKS container, and password entry successfully opens the container. Then, a password prompt appears for the second LUKS container, but the password fails (probably because a new salt was generated). The boot process cannot proceed.
Attempt 2
So, I tried assigning to each LUKS container its respective drive’s dedicated ESP like so:
boot.initrd.luks.devices."root-crypt".yubikey.storage.device = "/dev/disk/by-uuid/${ROOT_ESP_UUID}";
boot.initrd.luks.devices."data-crypt".yubikey.storage.device = "/dev/disk/by-uuid/${DATA_ESP_UUID}";
The result: at boot (with the YubiKey inserted), the password prompt appears for the first LUKS container, and password entry successfully opens the container (like before). A password prompt then appears for the second LUKS container, and duplicate password entry successfully opens the container (I’m guessing because the untouched copy of the initial salt was used to create the challenge). The boot process proceeds.
Great. The second attempt results in a working system but with two quirks:
- (Not a dealbreaker) A dedicated salt is required for each container
- (Super annoying) A password must be entered for each container, even if all containers were created using the same password. That is to say, it would appear that
boot.initrd.luks.reusePassphrases = true;(the default value) is not respected in a YubiKey-enabled configuration. (If this is the case, should I open an issue on GitHub?)
For the record, I am using systemd-boot and have not attempted this with GRUB over EFI.
Any suggestions to solve these quirks would be most welcome. Thank you for your time!