Re: [qubes-users] Re: yubikey password
On Tuesday, 14 August 2018 07:04:09 UTC-4, Brendan Hoar wrote: > On Monday, August 13, 2018 at 5:47:06 PM UTC-4, joev...@gmail.com wrote: > > 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... Thanks for the clarification Brendan. I actually meant that a normal setup for yubikey,... on Qubes. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d0217304-aafe-4b3b-a7a1-df09882194a5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Monday, August 13, 2018 at 5:47:06 PM UTC-4, joev...@gmail.com wrote: > 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... -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/56682592-e1e1-4bb2-a6a8-b392cb86ebbd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
> That's a TemplateBasedHVM and InputKeyboard is running, but (as you say) > 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. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9c4f62c4-4fa6-4be8-9c02-4d5681d30e5b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Sun, Aug 12, 2018 at 08:59:12AM -0700, joevio...@gmail.com wrote: > On Sunday, 12 August 2018 09:59:57 UTC-4, Unman wrote: > > On Fri, Aug 10, 2018 at 11:00:30AM -0700, : > > > On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > > > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should > > > > > say something like this. > > > > > > > > > > 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. > > > > > > > > > > > > > But the point is that the yubikey will be attached to a different qube, > > > > 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. > > > > > > 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. > > > > > > > > > > What you say about connecting keyboards isn't quite true. > > If you have passed the device through to a qube, then you need to set > > the policy *for that qube*. i.e - > > 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 > >
Re: [qubes-users] Re: yubikey password
On Sunday, 12 August 2018 09:59:57 UTC-4, Unman wrote: > On Fri, Aug 10, 2018 at 11:00:30AM -0700, : > > On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should > > > > say something like this. > > > > > > > > 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. > > > > > > > > > > But the point is that the yubikey will be attached to a different qube, > > > 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. > > > > 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. > > > > > > What you say about connecting keyboards isn't quite true. > If you have passed the device through to a qube, then you need to set > the policy *for that qube*. i.e - > 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 > "If you have passed the device through to a qube, then you need to set the policy *for that qube*. i.e - dom0 allow, user=root " Yes, and I did say that before, "It only works with, "sys-usb dom0 allow,user=root" in
Re: [qubes-users] Re: yubikey password
On Fri, Aug 10, 2018 at 11:00:30AM -0700, joevio...@gmail.com wrote: > On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say > > > something like this. > > > > > > 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. > > > > > > > But the point is that the yubikey will be attached to a different qube, > > 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. > > 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. > > What you say about connecting keyboards isn't quite true. If you have passed the device through to a qube, then you need to set the policy *for that qube*. i.e - 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 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180812135954.t34vte37fare3gcq%40thirdeyesecurity.org. For
Re: [qubes-users] Re: yubikey password
On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say > > something like this. > > > > 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. > > > > But the point is that the yubikey will be attached to a different qube, > 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. 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. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/150e4742-af7f-4b9c-84b6-4a52faf600e9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Fri, Aug 10, 2018 at 07:39:45AM -0700, joevio...@gmail.com wrote: > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say > something like this. > > 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. > But the point is that the yubikey will be attached to a different qube, 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. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180810153105.lkoo4vi6a3bduqtk%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say something like this. 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. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7615fd30-64e4-4594-bd7c-be4b58ecd5c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Fri, Aug 10, 2018 at 02:39:21AM -0700, joevio...@gmail.com wrote: > 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. > This isn't quite right. 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 > > 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/ > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180810141751.r3n3pfjvo3i2m2yt%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: yubikey password
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. 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/ -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/225ee7fe-639a-4099-b307-ff4a2718d73a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
