udisks
udisks copied to clipboard
Unable to open LUKS partitions secured by a single FIDO keyslot
Hi! The issue has been originally reported (by somebody else) to the gnome nautilus repo https://gitlab.gnome.org/GNOME/nautilus/-/issues/3507 but it had eventually been tracked down to udisks.
The problem is that fido2 authentication (in particular with yubikey) doesn't work when opening encrypted volumes with udisksctl unlock. It asks for the password instead.
Copying the full set of steps to reproduce it from the mentioned above ticket
$ dd if=/dev/urandom of=vaultfile.img bs=1M count=512
$ cryptsetup luksFormat vaultfile.img
$ systemd-cryptenroll --fido2-device=auto --fido2-with-user-verification=yes vaultfile.img
$ systemd-cryptenroll --wipe-slot=0 vaultfile.img
$ sudo losetup --find --show ./vaultfile.img
$ udisksctl unlock -b /dev/loop0
Passphrase:
Error unlocking /dev/loop0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/loop0: Failed to activate device: Incorrect passphrase.
$ sudo losetup -d /dev/loop0
During normal operation it should look like this:
$ sudo cryptsetup luksOpen /dev/sdb1 testvolume
Asking FIDO2 token for authentication.
👆 Please confirm presence on security token to unlock.
And should unlock the disk after the yubikey device is physically touched
We currently don't support unlocking LUKS devices with FIDO (or other LUKS tokens). We plan to add support in the future, but right now only passphrase and key file are supported by udisks.
Error unlocking /dev/loop0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/loop0: Failed to activate device: Incorrect passphrase.
Such an awful error message.
We currently don't support unlocking LUKS devices with FIDO (or other LUKS tokens). We plan to add support in the future, but right now only passphrase and key file are supported by udisks.
Are there any blockers for this the community could help with? I'm debating depending on this feature in a project of mine and I am fine to live with a workaround for 1-2 years but if this is further down the line I will have to consider other options.
There is nothing blocking this, someone just needs to write support for it, starting with libblockdev first. As I said, I plan to work on this in the future (I'd like to add support for adding nad managing LUKS tokens as well, including TPM), but I currently don't have capacity to work on this right now. I won't make any promises, but I think there is a real chance I'll find some time to work on this in the near future (aka this year).