Yubikey + LUKS on Qubes 4.1

[procShield]

@hackerfactor

so I scripted it)

#!/bin/bash

What do you do exactly at this step? What do I input into Dom0 terminal? Can you unpack this scripting part please? Thanks!

Also, do you have any thoughts about this discussion:

FIDO and Fedora - Yubikey C Bio

[gonzalo-bulnes]

@procShield

Can you unpack this scripting part please?

@hackerfactor

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

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

1. Stores the path to a GRUB file in a variable called grub for future use (the name could be whatever, it happens that grub makes sense in this context when you’re used to using variables)
2. Prints exactly Converting /etc/default/grub to use yubikey. Uses the variable defined above to do that. If you’re reading this in color in the forum, you can notice in the snippet above how the color of $grub is different to indicate that a variable is in use. This kind of printing is only for you to be able to know what’s going on while the script runs, it will be printed in the terminal in which the script is executed.
3. Makes a copy of /etc/default/grub called /etc/default/grub.bak. The latter is a common naming scheme for backups. The idea is that /etc/default/grub will be edited, but if you later on want to revert those changes, you’ve got a copy of the original file and can do the opposite operation to overwrite the changes: cp /etc/default/grub.bak /etc/default/grub.
4. Read the contents of the file /etc/default/grub and pass them as text to the next step
5. in that text, replace all occurrences of rd.luks.uuid= by rd.ykluks.uuid= and pass the result as text to the next step
6. in that text, replace all occurrences of rd.qubes.hide_all_usb by rd.ykluks.hide_all_usb and replace the content of /etc/default/grub with the resulting text
7. Print exactly Generating new bootloader
8. Uses a program called grub2-mkconfig to generate a file called /boot/efi/EFI/qubes/grub.cfg. That’s a configuration file that GRUB uses to show entries you can boot from. From the logic of the script you can infer that the program grub2-mkconfig uses the contents of /etc/default/grub to generate the config file. If you change those and run the program again, you get a new config file. (grub2-mkconfig manual – it’s half a page long, worth a look!)
9. Prints exactly Generating new kernel
10. Runs a program called dracut with the -f option to generate something called an initial image that is used by the kernel. From the logic of the script, you can infer that the initial image that dracut generates is different when /boot/efi/EFI/qubes/grub.cfg has changed.
    Here is the summary of what the dracut manual says (follow the link for more details):

dracut creates an initial image used by the kernel for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem.

Options

-f, --force
overwrite existing initramfs file.

[procShield]

Thank you.
This is what I am most interested in:

@hackerfactor

Converting $grub to use yubikey

That all depends on the previous steps. Is ykchalresp the only authentication method? I have a Yubikey C Bio and ykchalresp does not work, only FIDO2, I believe. How would you modify your directions for C Bio?

FIDO and Fedora - Yubikey C Bio

Since Qubes is building off of Fedora for base functions, it should be easy for you to tell me how modify the directions of the Fedora article to work on Qubes.

[gonzalo-bulnes]

Disclaimer: I don’t know myself. That being said, searching about systemd-cryotenroll in the forum lead me to this post, that seems to suggest that performing the initial LUKS unlocking using FIDO2 during startup is not yet possible as of R4.1. Again, I may be reading that wrong, and that information might be incorrect, but I think you’ll find some information on the forum starting from there.

[qubes-users] Yubikey LUKS with Qubes?

am 31.01.2023 um 10:24 in Nachricht <2d985c80-a4d0-45a6-b0d2-512c62335dfb@Canary>: I’m trying to figure out the things required to use my Yubikey to decrpyt my LUKS root filesystem. As I understand it, dom0 in 4.1.1 doesn’t have the functions require in cryptsetup. It looks like systemd in Fedora 36 added Hi! It depends *how* you want to use the YibiKey: In the simplest mode the key enters a constant string (password) via an emulated USB keyboard. So iy you can enter the pass phase …

[procShield]

Dom0 is not F37 as of latest? Alexander’s article cited above is addressing current Fedora. FIFO2 authorization is possible with all series 5 keys. I am going to try it, but maybe I should get a non-bio Yubikey for ykchalresp since a lot of the complexity is already worked out smoothly and the script looks solid. But then anyone with the hardware key can unlock. They don’t need a fingerprint. So what is the point? Carrying the key is more portable? Its not like HEADS is verifying hardware measurements with a Purism key.

[gonzalo-bulnes]

The latest release R4.1 sports Fedora 32 in dom0 (release notes). R4.2 will change that but is not released yet.

[procShield]

Then you could be right about not up for FIDO U2F, systemd cryptenroll, crypttab, and dracut . . . but all that has been around for awhile. F32 is not pre-systemd.

Dom0 can change it’s boot from GRUB to EFI which means systemd boot is possible.

But if Dom0 requires installation or updating, that is a problem. Update Manager asks me to update Dom0 but if that is compromised, all is lost so I don’t. FIDO U2F locking LUKS mught require networking access that bypasses even Update Manager security measures.

Probably should get a non-bio series 5 Yubikey with ykchalresp.

Do other keys like Nitro or Feitian have something like ykchalresp that can be installed in Work qube and connected to GRUB?

[procShield]

Still wondering what to do for F37 Dom0 on R4.2 if anyone has any pointers.

Unlocking LUKS2 with a usb key

Someone in the Fedora community should have the answer. I have been testing on F37 before trying Dom0. Good thing. It looks like I will have to cycle though in and out of emergency shell a few times to find the right disk nomenclature for crypttab if there isnt some other missing step like forming sym links. Until then, a psychic malevolent fire department could steal our Centuries strong passwords and frame our computers if we leave them unguarded at home our when they are out of our watchfu…

I wonder whther the GRUB script method or dracut crypttab is better…