Yubikey + LUKS on Qubes 4.1

hackerfactor · July 28, 2021, 9:25pm

Qubes 4.1 prompts for the yubikey password multiple times.

In work: Setup the yubikey. (yubikey-personalization-gui).
In work: Generate a yubikey passcode (ykchalresp -2 mypassword)
In dom0: Add the passcode to luks. (sudo cryptsetup luksAddKey /dev/nvme0n1p3)
Make grub support the yubikey (this is the hard part, so I scripted it)

#!/bin/bash
grub="/etc/default/grub"
echo "Converting $grub to use yubikey"
cp "$grub" "$grub.bak"
cat "$grub.bak" |
  sed -e 's@rd.luks.uuid=@rd.ykluks.uuid=@g' \
      -e 's@rd.qubes.hide_all_usb@rd.ykluks.hide_all_usb@g' > "$grub"

echo "Generating new bootloader"
grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg
echo "Generating new kernel"
dracut -f

After rebooting, it prompts for the yubikey (good!).
I plug in the yubikey and enter my ykpassword. The little progresss bar at the bottom moves a little. Then it waits for me to enter my ykpassword a second time.
I enter my ykpassword again. The little progresss bar at the bottom moves a little more. Then it waits for me to enter my ykpassword a third time.
I enter my ykpassword again. Then it boots up.

Any idea why it’s asking for the ykpassword multiple times?

ymy · July 28, 2021, 10:03pm

Well there is at least your root and most certainly your swap enncrypted maybe even more. and while luks seem to reuse prior entered passwords (dont know if this the case but feels like it) to decrypt all partitios when entered correctly. its mabe not possible in the same way with the yubikey.

hackerfactor · July 28, 2021, 10:11pm

With Qubes 4.0.3, it did not prompt for the password 3 times; it only prompted once. This is new to Qubes 4.1.

marmarek · July 28, 2021, 11:18pm

Why exactly are you disabling rd.luks.uuid= option(s) (by changing them into rd.ykluks.uuid=)? This actually may be the cause of your issue.

You can also review boot log (journalctl -b) and search for “Starting Cryptography Setup” entries - maybe it tries to unlock other partitions too (if you have some?), or it fails to unlock it initially and you can find more details why?

hackerfactor · July 29, 2021, 2:14am

I was following the instructions at GitHub - the2nd/ykluks: Dracut module to use yubikey in challenge/response mode to unlock LUKS partition.
It worked for Qubes 4.0.3 and 4.0.4, so I assumed it would work for 4.1.

In the morning, I’ll put rd.luks.uuid= back and see what it does.

marmarek · July 29, 2021, 2:33am

Ah, I see. That rd.ykluks.uuid may be needed in such case. But inspecting the log should still give more hints what is going on.

hackerfactor · July 29, 2021, 2:50pm

journalctl -b is interesting…

systemd-cryptsetup starts, sets the cipher, mode, etc. Then reports:

Jul 29 10:22:56 dom0 kernel: usb 1-5.1.2: Product: YubiKey OTP+FIDO+CCID
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.2: Manufacturer: Yubico
Jul 29 10:22:56 dom0 kernel: input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.0/0003:1050:0407.0003/input/input14
Jul 29 10:22:56 dom0 kernel: hid-generic 0003:1050:0407.0003: input,hidraw1: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input0
Jul 29 10:22:56 dom0 kernel: hid-generic 0003:1050:0407.0004: hiddev96,hidraw2: USB HID v1.10 Device [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input1
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: new full-speed USB device number 8 using xhci_hcd
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: New USB device found, idVendor=04e6, idProduct=5116, bcdDevice= 2.04
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: Product: SCR3310 v2.0 USB SC Reader
Jul 29 10:22:56 dom0 kernel: usb 1-5.1.3: Manufacturer: SCM Microsystems Inc.
Jul 29 10:22:56 dom0 kernel: input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.0/0003:1050:0407.0005/input/input15
Jul 29 10:22:56 dom0 kernel: hid-generic 0003:1050:0407.0005: input,hidraw1: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input0
Jul 29 10:23:09 dom0 systemd-cryptsetup[453]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/1fe9df1b-1ef5-49e8-8012-00d0c2629ecf.
Jul 29 10:23:13 dom0 systemd-cryptsetup[453]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Jul 29 10:23:21 dom0 systemd-tty-ask-password-agent[454]: Invalid password file /run/systemd/ask-password/ask.0kuQ2t
Jul 29 10:23:21 dom0 systemd-tty-ask-password-agent[454]: Failed to process password: Bad message
Jul 29 10:23:21 dom0 kernel: input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.0/0003:1050:0407.0006/input/input16
Jul 29 10:23:21 dom0 kernel: hid-generic 0003:1050:0407.0006: input,hidraw1: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-5.1.2/input0
Jul 29 10:23:24 dom0 systemd[1]: Reloading.
...
Jul 29 10:23:27 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dracut-initqueue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 29 10:23:27 dom0 systemd[1]: Reached target Remote File Systems (Pre).
Jul 29 10:23:27 dom0 systemd[1]: Reached target Remote File Systems.
Jul 29 10:23:30 dom0 systemd-tty-ask-password-agent[454]: Invalid password file /run/systemd/ask-password/ask.rzEmMo
Jul 29 10:23:30 dom0 systemd-tty-ask-password-agent[454]: Failed to process password: Bad message
Jul 29 10:23:30 dom0 systemd-cryptsetup[453]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/1fe9df1b-1ef5-49e8-8012-00d0c2629ecf.
Jul 29 10:23:30 dom0 systemd-cryptsetup[453]: Device luks-1fe9df1b-1ef5-49e8-8012-00d0c2629ecf already exists.
Jul 29 10:23:30 dom0 systemd-cryptsetup[453]: Failed to activate with specified passphrase: File exists
Jul 29 10:23:30 dom0 systemd[1]: systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf.service: Main process exited, code=exited, status=1/FAILURE
Jul 29 10:23:30 dom0 systemd[1]: systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf.service: Failed with result 'exit-code'.
Jul 29 10:23:30 dom0 systemd[1]: Failed to start Cryptography Setup for luks-1fe9df1b-1ef5-49e8-8012-00d0c2629ecf.
Jul 29 10:23:30 dom0 systemd[1]: Dependency failed for Local Encrypted Volumes.
Jul 29 10:23:30 dom0 systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Jul 29 10:23:30 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jul 29 10:23:30 dom0 systemd[1]: systemd-cryptsetup@luks\x2d1fe9df1b\x2d1ef5\x2d49e8\x2d8012\x2d00d0c2629ecf.service: Consumed 9.547s CPU time.
Jul 29 10:23:30 dom0 systemd[1]: Reached target System Initialization.
Jul 29 10:23:30 dom0 systemd[1]: Reached target Basic System.

(I’m sure that I typed the password correctly. It’s a test system so the password is “123”.)
I’m suspecting that it starts with an invalid /run/systemd/ask-password/ask.0kuQ2t file, then it recreates it and it works. (Race condition?)

hackerfactor · July 29, 2021, 3:04pm

Tried with rd.luks.uuid instead of rd.ykluks.uuid.
Nope – rd.ykluks.uuid is critical. Without it, the boot screen (black page with “Q” and text box) does not prompt for the yubikey. And if the yubikey is plugged in, it isn’t accessed to validate the passphrase. (The yubikey’s light doesn’t blink.)

hackerfactor · July 29, 2021, 3:14pm

@marmarek I think I found the cause of the 3 password prompts (black “Q” luks page with Yubikey).

The first password is always wrong. Doesn’t matter if you type it correctly, it’s always wrong. Maybe a bad character buffer? Acts like an uninitialized buffer, or something initialized with junk. (Failing the password clears the buffer, and gives the second password prompt.)

The second password is the real password. It checks and gives a message about receiving a response from the yubikey and the luks drive being unlocked.

The third password prompt is a bug. It doesn’t matter what you enter, it is ignored. (I intentionally entered a bad password, it didn’t care.) But you must enter something to get past the prompt. Then the OS boots.

Update: Reconfirmed

The first prompt says “Disk password”. Just press enter. This password is ignored.
The prompt changes to “Password”. Enter the yubikey passphrase. (Received response from Yubikey. Luks device opened.)
The third prompt says “Disk password”. Type anything; it is ignored. Then the system boots.

hackerfactor · July 29, 2021, 3:59pm

Possibly related: if you enter the wrong yubikey passcode at the “Password” prompt, then no number of re-entering the passcode will permit you to login. It looks like it wrote a temp file and is failing to overwrite it with the re-entered passcode.

The solution is to hard-reboot and do it again.

Update: Grrr… this is inconsistent. Sometimes a second password works, but sometimes a bad password cannot be recovered. (File locking issue? Permissions? Uninitialized buffer? Where’s the source code for this?)

deeplow · August 5, 2021, 7:31pm

Maybe this deserves a formal bug report?

hackerfactor · August 5, 2021, 9:19pm

Good idea! Done: 2FA with Yubikey prompts for unused passwords. · Issue #6823 · QubesOS/qubes-issues · GitHub

Szewcu · March 5, 2022, 6:40am

What is the status of that issue? You don’t write anything about installing ykluks into dracut. Does it mean it is now installed by default?

hackerfactor · March 5, 2022, 12:48pm

It’s still an open bug, as far as I know.

51lieal · March 5, 2022, 4:17pm

after looking into the code, i found that it’s complicated, and the warning issued by the author doesn’t make sense to me.

if you look into my guide in the detach header, i only modifying how cryptsetup detect the uuid.

if you really want to get yubikey work, i suggest to do research alone, by reading how luks, cryptsetup, and dracut works in the manual.

finding solution in the net really wasting time, because none of them using dracut.

initialize · May 16, 2022, 9:12am

@hackerfactor Could you please explain a bit more how you came up with creating or changing the script like this?

I wonder if it is also necessary to run initramfs generator according to use FIDO2 (e.g. with Yubikey) to unlock Qubes LUKS because here it says:

Before we can unlock the volume with this at boot, we need to allow FIDO2 unlocking via /etc/crypttab.
Unlocking LUKS2 volumes with TPM2, FIDO2, PKCS#11 Security Hardware on systemd 248

Can anyone give a hint as to what steps or adjustments are necessary to set up 2FA for Qubes LUKS with FIDO2 devices or refer to any source?

hackerfactor · May 16, 2022, 10:00am

How I came up with the script:
There were instructions for using Yubikey on Qubes 4.0.x. They were manual “type the following”. All I did was automate those instructions.

Whatever broke Yubikey support happened when Qubes 4.1 came out.

estoner · October 7, 2022, 1:01pm

@hackerfactor , Has this issue with Yubikey been further investigated? Did you ever get it working consistent with LUKS?

Qubiosity · February 26, 2023, 1:51am

So you followed the original instructions for Qubes 3.2 from this.

The mechanism for handling the auth is built into the dracut module that is built from those scripts. So if anything, something in 4.1 changed that probably has a new version that makes the script break.

You should probably submit an issue with the2nd’s ykluks repo.

Erica.vH · April 29, 2023, 6:42pm

What about other keys, like OneKey, or the very good TrustKey
https://www.trustkeysolutions.com/security-keys/g320h/