Questions about Yubikey 2fa login

User Support
1

The docs aren’t super specific on a few things so I’m hoping for clarification.

I guess the tool qubes-yubikey-dom0 is an official qubes package and is considered safe to download? Assuming that’s true, I have the following questions.

First, I’m assuming I have to have sys-usb launch at start if I want to use the yubikey at the login screen right after boot? It seems implied but not specifically stated.

Second, I’m not clear on which exact service files I should use. The doc mentions xscreensaver (I know what that one is). But it mentions “login” and “lightdm.” Which screens are those for? And are there any others I should activate as well for general lockdown in xfce?

Third, what threat model is this for? What sort of protections can this provide if the hard drive is already decrypted?

Could someone still harvest data/make OS changes if they’re able to boot the system yet are unable to get past the login screen? (I’m not using a usb mouse or keyboard if that makes a difference for this question.)

And finally, I read in the docs somewhere about the possibility of info leakage with usb devices. Since sys-usb is required at all times if I want to use yubikey 2fa (If I’m understanding correctly), what sort of data could leak if I were to use a usb device later in that session? Could a compromised block device/microphone/camera theoretically detect the key I forwarded to dom0 earlier that day? Or are those not the sort of data that could be siphoned?

(obviously, if the compromised device is plugged in when I sign in, that’s a different story.)

Sorry if these are self-explanatory to some of you. I’m pretty new to thinking about security on this level and want to get it right the first time.

2

Yes, however it probably won’t work due to a bug; consider installing the package from the testing repository instead, which contains the fixed version that also supports NitroKey3 dongles, not just YubiKey.

Yes, assuming you had set up a sys-usb on installation of QubesOS (highly recommended).

The lightdm pam module is for general desktop login, xscreensaver for screen lock and login for non-desktop login (i.e. a simple TTY) IIRC. Thus, if you want to login to your system with your dongle both from lock and boot, xscreensaver will not be enough; you have to include the yubikey line also in lightdm.

E.g. shoulder-surfing…you could have a good passphrase for login (without dongle), but someone might snoop it. Using this package you can set up a weaker (or no) passphrase that requires the dongle, however. That way (as long as you can guarantee the physical security of your dongle) you might feel more comfortable about things like leaving your laptop in the office / class room etc. while you take a little break somewhere else, because now you can lock the laptop and when you return you don’t have to type in some good passphrase in public.

If you disable any other way to log in then it might even help secure your system against more sophisticated threats than some snoopy co-worker / student, but, as you pointed out already, the LUKS container has already been opened, so this is likely not going to be a big hurdle for any high-competence attacker. FWIW, I did try to find out how to extract a LUKS2 key from RAM a while back and came up short, because it’s much better protected than the key under LUKS (“1”) was, but there probably is a way to do it.

See previous answer + it depends on how many other ways there are to log in, e.g. other accounts (admin?) or other passphrases. If the attacker truly cannot log in and cannot extract the LUKS key from RAM (big if) then the login screen might just protect your data. Other answers from more knowledgeable people welcome!

Not exactly; it’s required when you want to use the dongle. If you plug in other devices, you can restart sys-usb once you plug them back out again. In the default configuration sys-usb is a named DVM, so it would be very difficult to persist some malware as a result of using the prior device. Further, the qubes package doesn’t listen for a specific key from the dongle, but rather the correct response to a dom0-provided challenge (YubiKey) or an HOTP, i.e. a sequence of numbers that will vary every time as well, based on an incrementing counter both in the dongle as well as dom0.

1 Like
3

there is the u2f-proxy ; is in the qubes docs website, usually folks start by asking “what is your threat model?”

sys-usb is making things generally more not less secure

maybe, rewrite the question?

4

Talk about an answer. Thanks so much for all that!

Any idea when the fix might be brought over to the stable repository? I don’t really want to bug out my system with testing versions of things if I don’t have to.

5

You’re welcome.

There is no fixed timeline for non-security updates to leave testing, so unknown. But the Qubes lead developer has personally tested this updated version with a YubiKey and I’ve tested it / am using it with a NitroKey3 and it works in these two cases, FWIW.

6

Good to know. Will adding the testing repository have an impact on my other system updates?

7

If you enable it in the global settings (or by editing the relevant file yourself) then you will be receiving updates for all packages from current-testing, which is probably not what you want. The better solution IMO would be to enable it only for the installation of that package:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-yubikey-dom0
1 Like