Hello. Due to circumstances I am not able to memorize any password. For this reason, I have decided to use a Yubikey to gain access to my hardware. I’m not using the Yubikey as a 2FA device, but only as a keyboard that spits out a password when I press it. When the key is lost, the device is unrecoverable. For this reason, I don’t even want to store any personal data on the device itself. It’s just an entry to the internet for me and I can wipe it at any point. I just don’t want anyone else to gain access to it if they steal the device, even if they will eventually find nothing if they do
The problem is of course that it’s a USB Keyboard. The installer creates a Qube for it when the OS is installed and when I start the system for the first time, I am asked to give permission to dom0 for my USB Mouse. The same permission is not asked for the Yubikey. Why is that?
When I boot the system, I can decrypt LUKS with the key. I can also log in with the user with the key. When I lock the screen and use the key to log in with in the lock screen, I get a wrong password error message. At this point I can no longer get access so I have to hard-reboot the device and then when I try to enter the LUKS password, no password is entered when I use the Yubikey. I can connect another USB Keyboard and enter a password but the Yubikey no longer works, so I’m stuck
Regarding passwordless, I don’t know if you can leave yk-login-pass as an empty file, but have you tried it? I’m assuming that you’re using the configuration described at YubiKey | Qubes OS. In that page it notes that the relevant package needs to be installed into the template for sys-usb for this to work - if you install it in sys-usb itself then the package will be lost during the reboot and that would explain the problem.
There is already a thread for this topic. Maybe try searching first.
I am sorry to hear you suffer from amnesia or whatever the circumstance might be. Maybe you are so smart you realized FIDO is the best. What is the point of memorizing long random strings of numbers letters cap uncap and special characters when you have FIDO? Password managers store such long, impossible to guess even if you remember them passwords. I memorize 7 or more random words together (passphrase). The math on that is huge. I have tested my passwords with zxcvbn and get “centuries” level 4, which is the highest. No one is guessing. But why is brute memorization so important? If people don’t brute memorize liturgies then they are stupid so they must have done what they were framed with? There is FIDO! All the professionals use it. No one memorizes gpg blocks. Have you seen those? You think all the cryptography is stupid because it is not memorized? I don’t. Everything should have the ability to be locked with FIDO keys which can be kept on your person and thereby deny an adversary remote access.
From what I have found over many months of exploring locking LUKS with FIDO is that this method is useless because supposedly boot parameters can bypass crypttab meaning that FIDO is not if and only if but a non-essential key which is no key at all.
How do adversaries “just guess” Centuries level 4 passphrases? They don’t. There is some way they have to break it other than guesses (Telepathy? Impossible. Nothing written down) which they could not do with FIDO.
Maybe sys admins on the site side find the plain text of passwords and then change it to something easy they then say they “just guess.” There is a salt hash that prevents that? I have no idea how it is possible, but FIDO would stop that.
I have configured my Yubikey in Static Password Mode, not in Challenge-Response mode, so it just emits a static password when I press it. That’s the password (which I could also just type in using the keyboard (but don’t, because I don’t want to know it)) that I want to log in with.
When I install the system, I press the Yubikey to enter the password for:
Creating the filesystems with LUKS
Creating the user account and setting it’s password.
When that’s finished the device reboots and asks me for a password and I use the Yubikey for:
LUKS
User account.
Then I get into the QubesOS system for the first time and then when I lock the screen:
I use the Yubikey and it DOESNT work. It says I entered the wrong password .
Then I reboot the system by holding the power button and:
I get the LUKS password screen and I use the Yubikey and it DOESNT work .
Oh, I didn’t realize you could configure the YubiKey that way. I’ve never used it like that. My understanding is that for this workflow, you would need to connect the YubiKey to dom0. There are instructions here for that: USB qubes | Qubes OS
At least, I assume that this applies to YubiKeys. I get a notification that keyboard access was denied whenever I plug mine in.
It is possible to create a policy that allows input from a USB keyboard, which looks like this (note that the name of the policy makes a distinction for keyboards vs input devices that would include a mouse):
# Name of the file:
# /etc/qubes-rpc/policy/qubes.InputKeyboard
# Content:
sys-usb dom0 allow
That is described in the Manual setup for USB keyboards section of this page of the documentation:
In the section immediately before a semi-automatic method is described, which states:
This command will take care of all required configuration, including creating a USB qube if not already present.
If I am reading that correctly (I may not, I haven’t verified), “all required configuration” includes creating a policy like the one described in the manual steps.
Now, with that in mind, I suppose that the semi-automated procedure could run automatically during the Qubes OS installation if a USB keyboard is detected. (If all your input devices are USB devices, you need at least one to be allowed to authorize the other.)
That is an guess though (if somewhat educated, it’s still a guess): one way to confirm that hypothesis may be to check if your system contains the policy file. Does that make sense to you?
So do I because I get that notifucation too, and I believe the difference between our setups and @Industrial’s may be that we otherwise have a keyboard that is not a USB device, so there was no need to allow USB keyboards access to dom0 during the installation.
Hi thanks for your reply. I’ve added the file /etc/qubes-rpc/policy/qubes.InputKeyboard and I see that this is for the login after LUKS so I also tried the qubesctl state.sls qvm.usb-keyboard command and saw that it had a step for allowing usb on dom0 on UEFI.
The thing is though, that I don’t have a /boot/efi/EFI/qubes/xen.cfg file.
I did find the grub config files in /boot and those didn’t contain any USB references except for usbcore.authorized_default=0 and I even tried removing that and rebooting but that didn’t work as well so I’m giving up.
I’ve decided to just memorize a phrase for the LUKS password.
I can probably run a VM with “my own stuff” on it and just encrypt that as well
Yes, FIDO key to Dom0 (F37). But crypttab has to be precisely defined (disk nomenclature) or the machine will fall to dracut. I tested this first on Fedora alone.
@Industrial is saying he just plugs in a yubi at install if I am reading him correctly. Then the reason it is not working is because nothing has been done to bind the key to LUKS. USB keyboard is another topic. Except if you are thinking about how Dom0 can connect to USB (security key i/o). Dom0 can connect to networking pci for secure updates (no need to involve the dedicated qube for ether or wifi module pci) and templates so it must be able to access USB in a secure way (might require development).
There is also a GRUB-ykchalresp method (which depends on the type of your Yubikey) HMAC secrets or FIDO? There are different tokens and slots. The topic is complex.
This method looks easier but so does everything until you try to implement it. The cryttab-FIDO method was not at all as simple as it is presented. How step 2 moves to step 3 for the GRUB-ykchalresp method is unclear.
In work: Generate a yubikey passcode (ykchalresp -2 mypassword)
In dom0: Add the passcode to luks. (sudo cryptsetup luksAddKey /dev/nvme0n1p3)
