- Package:
- cryptsetup-initramfs
- Source:
- cryptsetup-initramfs
- Submitter:
- Peter Wienemann
- Date:
- 2024-11-21 17:36:02 UTC
- Severity:
- normal
Dear maintainer,
inspired by [0] I am trying to unlock a LUKS volume using a FIDO2 token
on a system running bookworm/testing using systemd 252-2.
The relevant line in /etc/crypttab looks like this:
--------------------------------------------------------------------
rootfs /dev/nvme0n1p3 none luks,discard,fido2-device=auto
--------------------------------------------------------------------
After running
systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p3
and adding the "fido2-device=auto" option in /etc/crypttab, I obtain the
following warning during updating the initramfs image:
--------------------------------------------------------------------
cryptsetup: WARNING: rootfs: ignoring unknown option 'fido2-device'
--------------------------------------------------------------------
As a result, it comes as no surprise that unlocking the volume using the
FIDO2 token does not work as desired.
Best regards,
Peter
[0] https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html
I've tried the same thing, and get the same results. It appears that the systemd support is there, the cryptsetup support is ithere, but just cryptsetup-initramfs is not somehow there also. It would be a shame to release bookworm with just the initramfs feature missing, when all the other pieces are there. Do you have any idea what might be blocking this? For what it is worth, dracut does work.
The old/regular cryptsetup is a different binary than the systemd-cryptsetup. Only systemd-cryptsetup supports fido2 unlocking. dracut works because it's based on systemd, so it uses systemd-cryptsetup. See https://www.guyrutenberg.com/2022/02/17/unlock-luks-volume-with-a-yubikey/. Thanks, Guy
I've just run into this as well. FWIW, there's apparently been some progress on the similar issue of adding TPM 2 support to cryptsetup: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031254 https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/39 In addition to Guy's solution of switching to Dracut (which, according to his blog post, still needs some additional hacks to get FIDO2 disk unlocking on boot working), there's also this project: https://github.com/bertogg/fido2luks But it would obviously be great to get official, non-hacky, native Debian support for FIDO2 disk unlocking on boot.