I am interested in making FIDO authenticators work in Fedora. There are a lot of possible applications.
I have a Yubikey C Bio and may explore Nitrokeys later.
1 ) For starters, how do I implement FIDO at system start up? “Using YubiKeys with Fedora” in Fedora Docs has a section on pam_yubico. Pam determines password authentication. When Workstation boots and a password is asked to unlock LUKS, is there a way to require the Yubikey to be inserted for 2FA? That’s the “challenge-response,” correct?
. . .
#%PAM-1.0
auth required pam_yubico.so mode=challenge-response
. . .
Then there is a user login. Alternately, could a yubikey be used at an administrator challenge response in Workstation?
If someone could explain more how to use yubikey to unlock at boot, maybe even as a BIOS Password (for coreboot) if not to unlock the drive or user, that would be great.
2 ) I am also wondering about webauthn. The method of web authentication with FIDO probably depends upon the web service. Take web authentication of an email service like Proton Mail for instance. 2FA has to be turned on in settings. The yubikey is the second factor. So instead of a phone and QR code, the yubikey is used in conjunction with an application like ykman, correct? Does anyone know how to add the Proton secret to ykman to enable 2FA and then apply the usb key as the second factor? The documentation that is available could be elaborated upon further.
Thanks!
Multifactorial authentication increases security, but coming up with a new random 20+ character combination of caps/uncaps letters, number, and special characters every month or so can be tedious. Passphrases are still susceptible to dictionary attacks. So what would be the ultimate authentication method? FIDO proposes that passwordless authentication is a strong and secure solution. The encryption keys in a hardware dongle that is like a physical key are very complex. Furthermore, fingerprints or other biometrics are other unique sources of complex information that a person can keep to themselves physically. So a sysadmin could have just one 20plus complex password, a hardware key (yubikey, nitrokey, CAC card, etc), and a password manager to preform all shibboleth functions. That sounds like a strong and manageable authentication solution, doesn’t it?
Thanks! That’s awesome. I think FIDO is a really exciting solution to many computing and account security challenges. I know how crucial it is to get PAM configurations right or anything that changes access qualifications so your article is greatly appreciated.
From what I’ve found so far, there are three methods for authenticating system startup on a local device.
There is no way to lock Coreboot BIOS with a Yubikey that I can find or on any proprietary BIOS. TPM is a 2FA, in a way, with Secure Boot enabled, but the security of 2FA lies in the fact that the second factor accompanies the user and not the device.
One way is adding a FIDO2 module to dracut (a topic raised on this forum). Another, the method I think looks most promising, is switching from grub to sd-boot and then using systemd-cryptenroll. Qubes OS suggests that users add the yubikey passcode to luks and grub through Dom0 which is Fedora based.
Here are a few of the links I think are pointing in the right direction which could be updated to Fedora 37 and 38.
Yubikey + LUKS on Qubes 4.1 - General - Qubes OS Forum
I hope the article will help determine the optimal solution. I think I could make some experiments with trying these options in Virtual Machine instances before trying it on the host system but you may already have an answer.
Then I started musing more abstractly about authentication and protecting access. What does it all mean mathematically and tactically? I’ve had so many unauthorized access breeches take place over the years–even with ~186 bit entropy memorable master passwords and ~196 bit entropy pws generated by a password manager (both methods with guesses log10=20-30)–it is nice to have a solution where even supercomputer in RU can’t brute the authentication. Probably not brute force methods. Probably end node security. But even with keyloggers present, FIDO should make unauthorized remote or physical access much more difficult.
Here is zxcvbn sample calculation of passwords:
“guesses_log10”: 23.999999999999996
“centuries”, “centuries”, “centuries”, “centuries”
“score”: 4
I wonder what is the math on cracking FIDO and 2FA would look like?
There is a set of instructions for unlocking LUKS with a Yubikey on Debian that might require only a few adjustments to work on Fedora also:
I have been testing other methods in KVM. I installed Fedora 38 with KVM hypervisor options set to boot UEFI, not Legacy like the default.
I think there is an issue mounting ESP in the right place. Directions I found for changing from GRUB boot to systemd boot said to move ESP mount to /efi by sudo mkdir /efi. Turns out later on this does not work. Sudo mkdir /usr/lib/systemd/boot/efi does. But after all the steps in between are carried out, the system still boots to GRUB and ends up bash.
I am working on testing this method but I have to figure out how to perform a USB passthrough to the VM on KVM. Probably dracut is a more, universal and direct method than systemd boot crypt enroll.
It looks like -usb is for USB 1 only. For USB 2, you need to use -device usb-ehci,id=ehci. I found an example here:
...
Note that USB 1.1 devices are handled by UHCI/OHCI and USB 2.0 by
EHCI. That means a device plugged into the very same physical port
may show up on different busses depending on the speed. The port I'm
using for testing is bus 1 + port 1 for 2.0 devices and bus 3 + port 1
for 1.1 devices. Passing through any device plugged into that port
and also assign them to the correct bus can be done this way:
qemu -M pc ${otheroptions} \
-usb \
-device usb-ehci,id=ehci \
-device usb-host,bus=usb-bus.0,hostbus=3,hostport=1 \
-device usb-host,bus=ehci.0,hostbus=1,hostport=1
enjoy,
Gerd
--
Gerd Hoffmann <kraxel@redhat.com>
So a passthough has to be configured when a VM is created? it can’t be afterward? I found other directions about configuring the XML but the syntax doesn’t match exactly what I find in KVM virt manager (the section “Managed, using virt manager” does not correlate). So the directions look straight forward but they don’t match my system. I have a “redirect USB” option and no “USB host device,” for example.
Do you think the dracut method from the link above requires systemd boot or would that method work with grub? Could you explain “systemd enabled initramfs?” Thanks.
Sorry, I don’t know. Like I said, I’ve never attempted USB passthrough with KVM and I’m even less familiar with Virt Manager. I used to run a lot of VMs before I converted things to containers. But I’m more familiar with the qemu command line than I am with what buttons do or do not exist on the point-and-click interface.
Ok. Do you have a link for a guide to introducing containers? I just want to find a method of testing before applying the solution to my primary machine. Good thing I am testing because the proposed solutions I tried to implement haven’t been successes on the first try. Have you tried the bpereto/ykfde dracut method above in a container yet? Does that work?
Containers wouldn’t work to test unlocking LUKS encrypted partitions because they bypass that phase of the system startup. Instead, the container host hands-off filesystems for the container to use.
Then I have to figure out how to passthrough USB in KVM. Alternately, I could try doing this in Virtual Box.
If I enter this command in terminal
/usr/bin/qemu-kvm -m 1024 -name f15 -drive file=/images/f15.img,if=virtio -usb -device usb-host,hostbus=2,hostaddr=3
with “-name f38” and “file=/path-to-f38-iso” substituted in, then I get “no such file or directory” because “…path-to-f38,if=virtio” doesn’t have a space where that comma is, right? What do I do about that? I also have to specify an UEFI boot operator in that qemu command because the default is Legacy unless I want to forget about systemd boot and focus on dracut cryptenroll. From what I have read, the dracut cryptenroll method doesn’t require systemd boot.
Are you talking about specifying pci? I need to passthrough Bus 003 Device 004: ID 1050:0402 which is USB C.
No, it is normal for qemu’s options to take multiple values separated by commas. It is more likely that your filename has some character in it that cannot be processed on the command line without proper escaping or quoting. (Or you could rename the file to not have spaces or other special characters and move it to a path that doesn’t include any such characters.)
Tried again. Image format was not specified . . . probing guessed raw . . . specify format explicitly
How do I do that?
Then I had the Yubikey inserted and put in the passphrase to the Authenticator but QEMU it could not open it. failed to open host usb device 3:4 lsusb → 3(bus):4(addr/device)
What do I do about that?
Try adding ,format=raw to the list of values you supply to your if= option.
That I do not know. Sorry. I’ve never attempted USB passthrough before. You might try passing through a “simpler” device just to see if the problem is specific to passing YubiKeys or if it is something more fundamental that is missing.
Cool. That looks like precisely what’s needed.
Meanwhile, I was checking on VirtualBox passthough options.
VM settings → USB → USB 2 OHCI + EHCI
But the yubikey is still not found. USB 3 xHCI is an option that can’t be selected. Is USB C xHCI? VirtualBox looked simpler but there is more that has to be done to enable passthrough.
I started on ykfdeREADME-dracut.md but there are a few points that would be helpful to clarify.
Just run make? Usually there is a file to download and directories are made to build a .sh or a .py and the writer suggests a specific command for Fedora, which is “make MD=markdown_py.” Can someone unpack these directions for the Yubikey consumer audience?
Then, for editing crypttab, where do I find the mapping-name and LUKS-Device? So already I have several questions when I start to implement those directions.
I am going to see what I can do about that QEMU 2FA passthrough or VirtualBox passthrough. Maybe someone could elucidate the yk dracut readme. Thanks!
Yeah. It looks like Fedora Linux has a binary called markdown_py. It is part of the python3-markdown package. So if you don’t have that file, install that package and then make MD=markdown_py should work. (You need to be in the directory that you cloned with git and then the make command will read what it is supposed to do from the Makefile file.)
You’re out of my league with that question. I’d just wait for Alexander’s article to come out.
Oh good. It’s not just me. This is complex. Yes, the article is highly anticipated. I love the idea of having a computer key that I can keep with me even if I don’t have the computer around. Login.gov makes using Yubikey as a 2FA so elegantly effortless. Round Cube mail also has an option like that. I think many services should be developed that support hardware keys like this to increase the security of “parties exposed to the internet” (QEMU usb0u2f article) that would prevent everything from unauthorized access and attacks on password protections to exfiltrating passwords with keyloggers.
