Requiring smartcard/multifactor for qubes main login?

It just occurred to me the issue with using smartcards/yubikeys/multifactor for logging into a qubes system.

If login happens on dom0, and dom0 has no access to usb since usb is in sys-usb, and I don’t believe that the sys-usb qube has been started till after login, I don’t see how we’d be able to use smartcards, or biometrics or similar since I believe they all use USB.

It would be possible to put usb back in dom0 (which has obvious security problems)

It might be possible to start sys-usb before login (possibly by creating a new “start qube automatically on boot and before login” option for qubes similar to the current “start qube automatically on boot” option )

However, even if we did that, forwarding the usb device to dom0 seems like a bad idea.
How would we get the authentication information back to dom0 in a safe way?

1 Like

I believe that you can use yubikey for luks encryption, you may look in my featured topic to get hint and do a little research to implement yubikey.

3 Likes

Qubes 4.1 has a seperate “sys-gui”, so does that mean the login user is now a sys-gui user, not a dom0 user? If so, that changes things.

Start from a hardware root of trust where the key signs that.

Heads Firmware - your BIOS/firmware is validated by your hardware attestation device and TPM chip to not be tampered with.
Heads firmware stage 2 - your /boot partition is GPG signed by your hardware attestation device to be not tampered with with.
Heads firmware stage 3 - ask for your password and use that, with TPM chip, to unlock the decryption key to your storage drive/OS drive. Luks, thank you.

edit ive removed some irrelevant content which was not relevant to your question and was more about me venting :wink:

1 Like

Not exactly what you’re looking for but related: YubiKey | Qubes OS

i see, thanks info,

in case my understanding is wrong, please let me reconfirm,

so do you mean that,
the BIOS authentication and Luks decryption,
happen between the Yubikey and TPM chip ?
and does not happen betwen Yubikey and sys-usb or dom0 ?

correct
that because the BIOS authentication and Luks decryption happen before dom0 and sys-usb start

qubesctl state.sls qvm.sys-usb
  • Have hide all usb kernel option, so your usb drive, usb keyboard, etc, will not work. It mean, your yubikey will not work for luks encryption or qubes login.
qubesctl state.sls qvm.usb-keyboard
  • All usb controller will work before sys-usb is started + auto enable keyboard to dom0 after running.

The reason I had scoped the question to the login screen is that I was only interested in what potential there was of extending qubes to multi-user.
(The answer ends up being that multi-user is already planned though having multiple sys-gui qubes.)

correct
that because the BIOS authentication and Luks decryption happen before dom0 and sys-usb start

nope, i think not 100% correct,

  • BIOS authentication happens between Yubikey and firmware - correct
  • but, Luks decryption does not happen between Yubikey and firmware
  • Luks decryption happens between Yubikey and dom0,
  • therefore, if we need Yubikey for Luks decryption, then we could not hide USB controller from dom0
  • so, the potential security problem still remain, since the USB controller is attached to dom0
  • actually, i’m not sure whether Yubikey can be used for Luks decryption,
    can we use Yubikey for Luks decryption ?
  • the doc yubikey is about Qubes user login and lock screen login, and not about Luks decryption

also, USB keyboard and Laptop keyboard may have different way to connect to motherboard

  • USB keyboard is connected externally to the motherboard, via USB controller
  • Laptop keyboard is connected internally to the motherboard, without USB controller
  • but if not mistaken, maybe some laptop keyboard are connected externally to the motherboard
  • we can use lsusb command on dom0, to see whether devices are connected to dom0 externally

hmm, are those understanding above correct ? anything wrong ?

idk if this correct
but how does this make sense when you are decrypting disk using a software that on the part of the disk that encrypted?
the bootloader is the only thing not encrypted and
dom0 is encrypted (right?)
so this should happen between grub (bootloader) and yubikey

so this should happen between grub and yubikey

what is grub ?

okay, the disk including dom0 is encrypted, before Luks decryption,
so Luks decryption happens between Yubikey and firmware

note: bootloader is not firmware because it installed on the disk

okay, if grub / bootloader is not firmware,
then is it part of Qubes OS ?
which is not being encrypted by Luks, and being used for booting after BIOS only ?

yes

so, if bootloader is part of Qubes OS,
and we want to use Yubikey for Luks decryption,
then does it mean, we could not hide USB controller from dom0 ?

actually, idk whether we can use Yubikey for Luks decryption

also, if we use Yubikey for OS login and lock screen login,
then the same, does it mean we need to attach USB controller to dom0 ?

i don’t understand

yes, search the web

@plexus would you have information or a link to instructions on how to implement state 3 on Qubes OS? Thanks.

If anyone is still curious about how Qubes OS does all of that decryption stuff on boot, all of that is in the initial ramdisk that accompanies the kernel on the boot partition.

The kernel is a single binary program that always runs whatever is in it.

When you build it, depending on what you are building it for (a mainframe or a toaster), you might want certain parts of the kernel running all the time, or running only when needed, to save system resources. In this case, these parts of the kernel are created as modules.

A fully-loaded 5.19 kernel with all the stuff baked into the actuall kernel instead of modules (the vmlinuz file in /boot) is well over 2GB, it would be incredibly stupid to have that big a file in your boot partition, not to mention having it chew up 2GB of your RAM simply by having your machine powered-on… :laughing:

So you build a “barebones” kernel with just the things that you know your machine will need all the time. This is why the Qubes OS dom0 kernel is <10MB

So where’s the rest of it, then?
It’s all stored in /lib/modules :slight_smile:

But how does the kernel load these modules if my disk is encrypted…?
There’s another file called the initial ramdisk (the initramfs*.img file in /boot) that contains the kernel modules required to boot the machine. When GRUB loads the kernel, it also puts the initial ramdisk into the system’s RAM.

So the modules needed to decrypt the hard drive (the sexy Plymouth boot splash screen, the algorithms, the method of decryption, YubiKey drivers, etc.) are all already in the RAM before you even enter your password :sunglasses:

I hope that I have expanded someone’s knowledge of how a computer boots :slight_smile: