#1023700 cryptsetup: Option fido2-device unknown

#1023700#5
Date:
2022-11-08 20:00:14 UTC
From:
To:
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
#1023700#18
Date:
2023-02-24 15:25:29 UTC
From:
To:
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.

#1023700#23
Date:
2023-03-05 19:58:35 UTC
From:
To:
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

#1023700#28
Date:
2024-11-21 17:32:52 UTC
From:
To:
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.