yubikey password
Arnulf Maria Bultmann
I use my yubikey besides other things as a password safe. under windows there is no problem to use the yubikey to type in the password into keepass.
Now I want to use the yubikey for thesame procedure under qubes 4.0.
I use a security-vm for keepass and connect the yubikey from sys-usb to security-vm. It's no problem to use the personalization gui. but how can I use the yubikey in this vm as a kind of usb-keyboard to put the stored password into keepass or for example an editor?
thanks in advance for your help
Arnulf
joev...@gmail.com
I don't think USB keyboards attach to AppVMs normally. They attach to dom0, and use the qubes-gui windows manager to type and control mouse movement and clicks.
So if you were to attach it to an AppVM.. I am not sure it could even type into the session you are viewing. Keyboards and mice have to attach to dom0 in order for it to interact with the windows it renders.
Have you considered using Chal/Resp instead of static password? It is way more secure since you are not using one password for everything... and the secret never gets send across USB. Keepass works with Challenge / Response, and even works with LUKS encryption of Qubes OS. KeeChallenge and OtpKeyProv plugin for Keepass running on mono in a debian AppVM. Then you can attach the Yubikey to that vm, and Challenge Response with something you know.. opens the vault.
http://richardbenjaminrush.com/keechallenge/
Unman
> On Wednesday, 8 August 2018 13:34:14 UTC-4, Arnulf Maria Bultmann wrote:
> > Hello,
> > I use my yubikey besides other things as a password safe. under windows there is no problem to use the yubikey to type in the password into keepass.
> > Now I want to use the yubikey for thesame procedure under qubes 4.0.
> > I use a security-vm for keepass and connect the yubikey from sys-usb to security-vm. It's no problem to use the personalization gui. but how can I use the yubikey in this vm as a kind of usb-keyboard to put the stored password into keepass or for example an editor?
> > thanks in advance for your help
> > Arnulf
>
> I don't think USB keyboards attach to AppVMs normally. They attach to dom0, and use the qubes-gui windows manager to type and control mouse movement and clicks.
> So if you were to attach it to an AppVM.. I am not sure it could even type into the session you are viewing. Keyboards and mice have to attach to dom0 in order for it to interact with the windows it renders.
>
If you have a sys-usb set up, then the keyboard will be attached there,
and not to dom0.
Have a look at :
https://www.qubes-os.org/doc/usb
I suspect op needs to edit the RPC policy rules in
/etc/qubes-rpc/policy/qubes.InputKeyboard
joev...@gmail.com
sys-usb dom0 allow,user=root
Yes, If you have a sys-usb set up, then the USB keyboard will attach there first. More specifically, the USB Host Controller that the USB keyboard is plugged into is attached to sys-usb. But the keyboard device is immediately sent to dom0 per the rpc policy. Because a keyboard that stays attached to sys-usb, can only type into sys-usb. And not the interactive window you see when you open up a terminal for sys-usb... but rather its own session.
dom0 needs the keyboard and mouse. The USB Host Controller still resides in sys-usb, but the USB raw data passes to dom0 upon boot.
Unfortunately, the rpc policy is generic based on all USB devices enumerating as a keyboard. So it may not be able to selectively attach a yubikey to an AppVM.
Unman
and can be treated as a keyboard there. This means that one can
selectively link the yubikey to distinct qubes for input there, and the
sys-usb policy will not be relevant.
The Input.Keyboard policy needs to be set for the qube to which the
yubikey is attached.
joev...@gmail.com
> On Fri, Aug 10, 2018 at 07:39:45AM -0700,
Yeah, that would be nice if it were that granular.
I don't have my yubikey set for a static key, but let me test this with my input stick, which is like a USB rubber ducky. It enumerator as a keyboard, and I have just attached it to the app VM I am typing on.
I am speech to text on my phone, Bluetooth to InputStick USB and typing into here.
It only works with, "sys-usb dom0 allow,user=root" in /etc/qubes-rpc/policy/qubes.InputKeyboard
And it does NOT work with "sys-usb APPVM_NAME allow,user=root".
No USB device attaching is needed, as the rpc rule simple allows dom0 access to sys-usb keyboard.
As I said... Keyboards need to be sent to dom0, or else it cannot type in the GUI.
This will work for all USB keyboards as you cannot specify Yubikey keystrokes only type in a single AppVM. Not the most secure... which is why Qubes recommends PS2 keyboards if running on a desktop and using the built in keyboard on laptops. It avoids the USB blanket rule for keyboards going to dom0. And since LUKS encryption passphrases are entered after initramfs hides usb from boot process, a non-usb keyboard is essential for full disk encryption.
All that said,
it is still a much more secure option to use ykchalresp which comes with yubikey tools. The USB device that does this function is not the keyboard part, and you have to explicitly Attach to the VM you want. Also, no static key to be sniffed or accidentally typed somewhere. I use it for KeePass, LUKS, PAM.d login, OTP tokens, everything.
Unman
If you have passed the device through to a qube, then you need to set
the policy *for that qube*. i.e -
<connected qube> dom0 allow, user=root
I don't use yubikeys so I cant speak for them, but that works for
keyboards. It does mean that the attached keyboard input *could* be sent to
any qube after user error.
Of course, the granularity of passthrough is currently missing, but it's possible
to hack this in various ways.
If you create a HVM and assign it a USB controller, then usb attached
devices can insert key strokes *without* using qubes.InputKeyboard. This
looks like a reasonable approach if you have more than one controller,
and keeps the usb keystrokes confined to the qube.
If you only have one controller, then you could stop the Sender service
in the qube, let the keyboard do it's stuff in that qube, remove the
yubikey, and then re-enable the service. A bit unwieldy but security
always comes at a price, and you could automate this with a key
combination.
It's also possible to use qrexec to directly pass keystrokes from one
qube to another. You can manually run the input proxy service and pipe
it through to another qube. I've hacked this via dom0 (poc) and it works
fine - you also need to process the /dev/input/event input to generate
keyboard input in X in the qube, but that's pretty standard. If it's of
interest I could work this up.
unman
joev...@gmail.com
> On Fri, Aug 10, 2018 at 11:00:30AM -0700, :
Yes, and I did say that before,
"It only works with, "sys-usb dom0 allow,user=root" in /etc/qubes-rpc/policy/qubes.InputKeyboard"
The "device" is attached to sys-usb and the "keyboard" must be sent to dom0 to send keystrokes to any vm normally.
But, "sys-usb <security-vm for keepass> allow,user=root" does NOT work.
> "If you create a HVM and assign it a USB controller, then usb attached
devices can insert key strokes *without* using qubes.InputKeyboard."
I'm testing this, and it doesn't work.
sys-usb is an HVM, it has the USB controller assigned... and qubes.InputKeyboard is NOT allowing to dom0. With a USB Keyboard plugged into this controller, it does not type into an open sys-usb window.
I double tested with another HVM appvm with a different USB PCI card attached to it. Nothing.
The problem is this:
How does an attached keyboard connect to that AppVM's X server? Dom0 does this by default, because it has to be the window manager for all the DomU's.
This is proven by my tests in an hvm I created with an iso, without qubes-gui installed. It is running as full desktop (not windowed). I attached the controller, and all keystrokes do show up in this vm. That's because dom0 is not handling the windows in this vm.
> "use qrexec to directly pass keystrokes from one qube to another"
Yes, that's easy if the source qube was dom0. Any other qube, a usb keyboard won't show up in xinput as a keyboard. X is connected to dom0, and not the actual AppVM that that the USB device is attached to.
Yes, you could get a raw usb keyboard stream from /dev/input/ and pass that through qrexec to the destination vm, decode and type it out using xdotool.
I've used xdotool to type into an AppVM, from dom0. So it should work if you can convert the /dev/input into ascii. A python module is capable of this.
With only 1 USB Host controller, then you may have to run a script as root on sys-usb to send the raw keystrokes through qrexec to the destination.
Unman
not allowed - I advised creating a HVM (Standalone) and you'll see it works.
You refer to this case below.
People have reported using yubikeys in this configuration in the past.
>
> I double tested with another HVM appvm with a different USB PCI card attached to it. Nothing.
>
> The problem is this:
> How does an attached keyboard connect to that AppVM's X server? Dom0 does this by default, because it has to be the window manager for all the DomU's.
>
> This is proven by my tests in an hvm I created with an iso, without qubes-gui installed. It is running as full desktop (not windowed). I attached the controller, and all keystrokes do show up in this vm. That's because dom0 is not handling the windows in this vm.
>
> > "use qrexec to directly pass keystrokes from one qube to another"
> Yes, that's easy if the source qube was dom0. Any other qube, a usb keyboard won't show up in xinput as a keyboard. X is connected to dom0, and not the actual AppVM that that the USB device is attached to.
>
> Yes, you could get a raw usb keyboard stream from /dev/input/ and pass that through qrexec to the destination vm, decode and type it out using xdotool.
> I've used xdotool to type into an AppVM, from dom0. So it should work if you can convert the /dev/input into ascii. A python module is capable of this.
>
> With only 1 USB Host controller, then you may have to run a script as root on sys-usb to send the raw keystrokes through qrexec to the destination.
>
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/853fc45d-fb76-4e5c-9e78-df4596f3464b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
joev...@gmail.com
> not allowed - I advised creating a HVM (Standalone) and you'll see it works.
> You refer to this case below.
It's not InputKeyboard that is the problem, it is Qubes-Gui. StandaloneVMs Not based on a Template, won't have any qubes services running. But attaching a USB keyboard is also not possible.
For my test, my AppVM (Kali) was installed from an ISO (not a template), and I installed Qubes services/agents from deb packages. This allowed USB passthrough, but I never got the qubes-gui installed. So it does work.
> People have reported using yubikeys in this configuration in the past.
I have read a lot of the yubikey / qubes implementations, as I am currently using one.
Are you sure they are using Yubikey's "Static Password" slot? That is the only component that enumerates as a USB keyboard. The normal yubikey setup enumerates as a Smartcard, which is how the challenge/response works. With this, there is no keyboard to attach as an input device and no keystrokes to manage. You attach the USB to the AppVM, and that's it.
brenda...@gmail.com
> Are you sure they are using Yubikey's "Static Password" slot? That is the only component that enumerates as a USB keyboard. The normal yubikey setup enumerates as a Smartcard, which is how the challenge/response works. With this, there is no keyboard to attach as an input device and no keystrokes to manage. You attach the USB to the AppVM, and that's it.
Yubikeys are USB "composite" devices that can have one or more interfaces enabled.
[Note that while a USB *compound* device is a USB device with a built in USB hub that has multiple USB devices attached, a USB *composite* device does not incorporate a USB hub but instead presents as a single device with multiple interface endpoints.]
A stock contemporary Yubikey NEO or Yubikey 4 may be shipped with the following interfaces enabled all on the same single USB device: HID (with superset of keyboard functionality to support a variety of OTP functions), CCID (smartcard running multiple javacard applets), and U2F.
Yubikeys are also configurable such that each interface can been disabled as necessary (for corporate roll out, compatibility with older software* that doesn't handle multiple interfaces well, prevention of inadvertent OTP generation, etc.). One cannot assume that a Yubikey that presents a CCID interface will also provide a HID interface
Therefore "Normal Yubikey setup" is a moving target. :)
Brendan
* if you guessed OpenPGP, you get a star...though my experience with multiple smartcards in use with Microsoft AD products tells me OpenPGP isn't the only badly behaved smartcard client out there...
joev...@gmail.com
Thanks for the clarification Brendan. I actually meant that a normal setup for yubikey,... on Qubes.