FIDO2 fallback to password

[bjacquin]

systemd version the issue has been seen with

systemd 248 (248)

Used distribution

Gentoo

Linux kernel version used (uname -a)

Linux lady-voodoo.local 5.12.9-stable #1 SMP 2021-06-07T21:43:26+01:00 x86_64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz GenuineIntel GNU/Linux

CPU architecture issue was seen on

x86_64

Unexpected behaviour you saw
This is a follow up from #19842. When FIDO2 authentication fails, there is no fallback to passphrase for a user. Two situations happens here.

1. if the FIDO2 token is not present, systemd waits forever
2. if a FIDO2 token is present but libfido2 itself fails, systemd switch to emergency mode

Is there a plan to allow

1. Observe a timeout before systemd stop waiting for a passphrase or use alternative method available as per luks header ?
2. If libfido2 fails, ask for the passphrase or use alternative method available as per luks header ?

[poettering]

The timeout is already requested in #10739.

What precisely do you mean by "libfido2 itself fails"? Do you have some specific error case in mind? If so, what#s the error you saw? Can you provide the log output of the failure?

[bjacquin]

What precisely do you mean by "libfido2 itself fails"? Do you have some specific error case in mind? If so, what#s the error you saw? Can you provide the log output of the failure?

In case of #19842, libfido2 fails with FIDO_ERR_RX:

Jun 07 21:56:44 lady-voodoo.local systemd[1]: Starting Cryptography Setup for lv-data...
Jun 07 21:56:44 lady-voodoo.local systemd[1]: Starting Cryptography Setup for lv-home...
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[322]: WARNING: Locking directory /run/cryptsetup is missing!
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[322]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-uuid/3d527330-917c-4e07-adad-a89ae3391f1a.
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[322]: Automatically discovered security FIDO2 token unlocks volume.
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[323]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-uuid/681f3095-8955-444f-8543-8a3f7508a3e4.
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[323]: Automatically discovered security FIDO2 token unlocks volume.
Jun 07 21:56:44 lady-voodoo.local systemd[1]: Finished LVM2 PV scan on device 259:4.
Jun 07 21:56:45 lady-voodoo.local systemd-cryptsetup[323]: Failed to open FIDO2 device /dev/hidraw0: FIDO_ERR_RX
Jun 07 21:56:45 lady-voodoo.local systemd[1]: systemd-cryptsetup@lv\x2dhome.service: Main process exited, code=exited, status=1/FAILURE
Jun 07 21:56:45 lady-voodoo.local systemd[1]: systemd-cryptsetup@lv\x2dhome.service: Failed with result 'exit-code'.
Jun 07 21:56:45 lady-voodoo.local systemd[1]: Failed to start Cryptography Setup for lv-home.
..

In such case, no fallback is made to passphrase unlock and systemd switch emergency target. I can provide full log for this use case

[keszybz]

Also https://bugzilla.redhat.com/show_bug.cgi?id=1965482…

[Diaoul]

+1 for that. I can reproduce on 249. No fallback happening there, or I did not configure it correctly.
Fallback to the password keyslot should happen after a timeout when the fido2 key is not detected.

The timeout is already requested in #10739.

I am not sure you linked the right issue?

[poettering]

The timeout is already requested in #10739.

I am not sure you linked the right issue?

#19739 is the right issue. one digit typo

[tchernobog]

I am also seeing no fallback even after setting a timeout on systemd 250.

[wikoion]

If you set the token-timeout option mentioned in the release notes: https://github.com/systemd/systemd/releases/tag/v250
You then have to enter a pin, it'll timeout waiting for a fido device and ask you for your fallback password.

[crahan]

Can anyone confirm that entering an empty pin without the FIDO2 key being present halts the boot process and does not fallback to a password prompt?

The only way for me to fall back to the regular password prompt without the FIDO2 key being present is to enter a non-empty pin value first. The pin can be an incorrect one, it just can't be empty.

[wikoion]

I have to enter something, can't be empty for me either

[vmsh0]

Can anyone confirm that entering an empty pin without the FIDO2 key being present halts the boot process and does not fallback to a password prompt?

The only way for me to fall back to the regular password prompt without the FIDO2 key being present is to enter a non-empty pin value first. The pin can be an incorrect one, it just can't be empty.

On Arch Linux, systemd 251, it now falls back to a passphrase after 30 seconds of no key present. My configuration doesn't have a PIN.

I don't know how or why that works, but I would much like to find out as I would like to change the timeout (or, even better, fix it so I can manually trigger the fallback instead of having it on a timeout.)

[Thaodan]

For me it just fails when the token doesn't work as systemd-cryptsetup just wants to use the token.
the errors I are FIDO_ERR_INTERNAL.
(3 devices same token).

[gertvdijk]

@vmsh0

I don't know how or why that works, but I would much like to find out as I would like to change the timeout (or, even better, fix it so I can manually trigger the fallback instead of having it on a timeout.)

systemd/NEWS

Lines 821 to 825 in 5e81e84

	* /etc/crypttab gained support for a new token-timeout= setting for
	encrypted volumes that allows configuration of the maximum time to
	wait for PKCS#11/FIDO2 tokens to be plugged in. If the time elapses
	the logic will query the user for a regular passphrase/recovery key
	instead.

systemd/man/crypttab.xml

Lines 689 to 698 in 5e81e84

	<term><option>token-timeout=</option></term>
	<listitem><para>Specifies how long to wait at most for configured security devices (i.e. FIDO2,
	PKCS#11, TPM2) to show up. Takes a time value in seconds (but other time units may be specified too,
	see <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
	for supported formats). Defaults to 30s. Once the specified timeout elapsed authentication via
	password is attempted. Note that this timeout applies to waiting for the security device to show up —
	it does not apply to the PIN prompt for the device (should one be needed) or similar. Pass 0 to turn
	off the time-out and wait forever.</para></listitem>
	</varlistentry>

[mcassaniti]

I'm interested in the other direction (removing the password), particularly for systemd-homed volumes. The idea is that activation of a user would always require their FIDO2 token, but a locked screen can be unlocked with a password.

If I need to raise a separate issue then let me know.

[Blub]

It would be nice if there was some hotkey to switch to the regular password - or if entering an empty PIN would do that (for devices with pins...).
Being unable to use a password on UKIs (where I cannot modify the rd.luks.options kernel cmdline) makes FIDO keys unusable for me.
EDIT: Just noticed that typing a dummy PIN actually does that. That's a bit unintuitive, but at least works.

[eickeh]

I'm running systemd 255 now and it still seems to be the same behavior. Would be nice to see this handled a bit more intuitively. My suggestion:

1. In case no token is present, treat an empty PIN the same as a wrong pin such that the passphrase fallback is presented in both cases
2. Provide an option to enter a passphrase even if a token is present, e.g. by entering an empty pin.
3. Print a short explanatory comment before the token pin prompt, e.g. "Unlock disk via FIDO2 token. Press key combo to enter a passphrase instead."
   Or at least a comment to explain the current state, e.g. "Unlock disk via FIDO2 token. To enter a passphrase instead, remove the token and enter an arbitrary non-empty pin first" :D

And thanks for the possibility of fido2 tokens here at all, makes booting a lot less pain :D