PS/2 Keyboard and Mouse via USB?

[jrsm...@gmail.com]

I have a motherboard that I would like to use with Qubes that has no PS/2 ports. I have a PS/2 keyboard and mouse and would like to know if connecting them via a PS/2 to USB adapter is as secure (or nearly so) as connecting via native PS/2.

There are excellent docs describing how to use a USB keyboard and mouse with Qubes, but I haven't found anything that addresses this question, which is a bit surprising. Seems like this would be a commonly asked and answered question easily found in the docs.

[jrsm...@gmail.com]

On Saturday, April 6, 2019 at 6:51:59 PM UTC-7, jrsm...@gmail.com wrote:
> I have a motherboard that I would like to use with Qubes that has no PS/2 ports. I have a PS/2 keyboard and mouse and would like to know if connecting them via a PS/2 to USB adapter is as secure (or nearly so) as connecting via native PS/2.
>
> There are excellent docs describing how to use a USB keyboard and mouse with Qubes, but I haven't found anything that addresses this question, which is a bit surprising. Seems like this would be a commonly asked and answered question easily found in the docs.

I went ahead and ordered one of these: SANOXY PS2 Keyboard To USB Adapter for about $10 from Amazon. It will be here Tuesday and I'll be able to try it out. Even if it "works" - as a fresh install of 4.0.1 will treat the PS/2 keyboard and mouse attached via USB as native PS/2 (I doubt it), that still leaves the question of how much exposure to USB dom0 will have. Anyone know for certain?

[jrsm...@gmail.com]

I just read Joanna’s 2011 article describing the challenges of USB security and I think this answers my question. Connecting the PS/2 keyboard and mouse to a USB device via an adapter still leaves the issue of securing the USB controller, so it offers little or nothing in the way of increased security vs simply using a USB keyboard and mouse. As she described, a separate domain could be used to manage the controller and use PVUSB to allow dom0 access to just the port(s) used by the keyboard and mouse. However, I don’t think this would work in the case of entering the LUKS password at boot time since that domain wouldn’t exist yet and dom0 would not have access to the keyboard.

So if I’ve understood this material correctly, if I want to avoid exposing dom0 to any USB controllers and I want to use passwords for LUKS, native PS/2 keyboard and port are a must.

[awokd]

jrsm...@gmail.com:

> I just read Joanna’s 2011 article describing the challenges of USB security and I think this answers my question. Connecting the PS/2 keyboard and mouse to a USB device via an adapter still leaves the issue of securing the USB controller, so it offers little or nothing in the way of increased security vs simply using a USB keyboard and mouse. As she described, a separate domain could be used to manage the controller and use PVUSB to allow dom0 access to just the port(s) used by the keyboard and mouse. However, I don’t think this would work in the case of entering the LUKS password at boot time since that domain wouldn’t exist yet and dom0 would not have access to the keyboard.
>
> So if I’ve understood this material correctly, if I want to avoid exposing dom0 to any USB controllers and I want to use passwords for LUKS, native PS/2 keyboard and port are a must.
>

Not exactly sure how that keyboard will show up but you have understood
the security warnings correctly. See
https://www.qubes-os.org/doc/usb-qubes/#automatic-setup too; you can use
a USB keyboard for LUKS passwords but there is risk involved.

[jrsm...@gmail.com]

And then there’s this: https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login.

[Tai...@gmx.com]

I have stated this many times before.

The PS/2 thing is from 2011 which is 8 years ago and applies to systems
without more than one USB controller.

Using PS/2 sends your keystrokes out on the ground wire.

It is far better to purchase a motherboard with a second USB controller
with separate IOMMU groups or a PCI-e supporting USB card with one
controller per port and an ACS PCI-e switch to tie them together, of
course all must have libre firmware and preferably made somewhere
trustworthy.

I would only trust hardware Made in USA or Switzerland since both are
the only places in the world right know where you can say no to a demand
to put a backdoor in your product and have nothing come of it. (Heres to
hoping for Xen/Qubes on OpenPOWER for usa made computing) Unfortunately
recent cases have proven the EU majority no longer has freedom of speech
(such as the man who went to jail for criticizing a certain foreign
leader in germany) and code is speech, hdls are speech and freedom of
speech means freedom to be silent (and thus not code a backdoor)

Ideally you would have 4 IOMMU separate usb controllers total.

USB controllers:
dom0/sys-usb-keyboard (you enter your passwords and then it gets
assigned to sys-usb-inputs later which is for your keyboard and mouse)
sys-usb-mouse (off at boot - since I know of no secure mice it should be
separate)
sys-usb-trusted-stuff (off at boot, assigned to sys-usb later) your
flash drives
sys-usb-untrusted-stuff (off at boot, assigned to sys-usb later) other
peoples flash drives

I use a PCL/PS network printer so I don't need a 5th for that.

In terms of USB devices you want stuff without re-writable firmware
which many keyboards have and AFAIK the only OEM that attests to its
products security and lack of re-writable firmware is Unicomp (and of
course the original Model M's can't be re-written either)

The most secure input device is the USB Unicomp Model M pointer which is
an made in usa mechanical keyboard with a laptop style mouse nub in the
middle of the keyboard and two mouse buttons - unicomp makes the rare
high quality keyboard that will never break and never need replacing due
to wear.

[unman]

Ideally, yes, but most people aren't in a position to have the ideal.

I've pointed out before that your comments on PS/2 are misleading. With
some keyboards, (but not all), there can be leakage to ground. But it's
possible to mitigate the effects of this or to clean signal from the
earth (ground) wire.
It's important to make this clear so that people can make informed
decisions about their choices between USB and PS/2.

Incidentally, your touching faith in "Made in USA" components seems
strange to me -I see no more reason to trust that label more than any other.
The USA has a long and inglorious history of snooping and subversion.
(This isn't intended to provoke any discussion on the Qubes mailing list,
so please don't argue the point on list. It's my opinion.)

[jrsm...@gmail.com]

I really appreciate the responses. I bought a new mobo that does have native PS/2 to use with Qubes. It arrived today and I’ll be trying it out after work today. How would I go about determining if my keystrokes are being revealed on ground? I have a storage scope so I think it would just be a matter of hooking one probe near ground on the PS/2 port and the other to ground on something farther away like the power supply. If I see a signal, would some additional decoupling caps do the job to fix it or is there more to it?

[jrsm...@gmail.com]

If there is no signal on PS/2 ground or I can eliminate it, is this the more secure route or is it worth doing the USB shuffle? I have 4 USB controllers available.

[jrsm...@gmail.com]

Yet another approach might be to use a USB to PS/2 adapter to connect a USB keyboard that supports PS/2 signaling to a native PS/2 port. Would that be a good solution to avoid keyboard leaking signals to ground?

[jrsm...@gmail.com]

The PS/2 keyboard leaking to ground risk seems like it would only apply if an attacker had physical access. Is that right or is there a way it could be exploited remotely?

[haaber]

On 4/10/19 9:50 AM, jrsm...@gmail.com wrote:
> The PS/2 keyboard leaking to ground risk seems like it would only apply if an attacker had physical access. Is that right or is there a way it could be exploited remotely?
>

In principle that can be measured far away, with little hw cost Read you
here

https://www.blackhat.com/presentations/bh-usa-09/BARISANI/BHUSA09-Barisani-Keystrokes-SLIDES.pdf

you also see that they use a 150 ohm resistance between refence ground
and the ground wire that the computer connects to. That may help as a
setup to measure at home. Distance? Scheier writes (in July 2009): "The
attack has been demonstrated to work at a distance of up to 15m, but
refinement may mean it could work over much longer distances."

[haaber]

Sorry, I forgot to add: countermeasures could be: (1) a low-pass filter
to remove frequencies > 200Hz and (2) white noise injection in the
"cleaned" (by step 1) ground wire PS/2 frequency range 10-20 kHz. If you
like to solder a bit ... maybe look at "Avalanche Breakdown Diodes" ?

[unman]

On Tue, Apr 09, 2019 at 11:45:02AM -0700, jrsm...@gmail.com wrote:
> If there is no signal on PS/2 ground or I can eliminate it, is this the more secure route or is it worth doing the USB shuffle? I have 4 USB controllers available.
>

If you really have 4 USB controllers I would allocate one to dom0 and 3
to sys-usb (or more than one sys-usb).
Depending on your level of paranoia you might want to permanently attach
the devices to the usb port in dom0 - I mean physically.

[unman]

Or use a ground lifter or work off disconnected UPS as needed.

[John Smiley]

So if you have 4 or more USB controllers isolating one for its exclusive use for kb and mouse is safer than PS/2?

If so that eliminates one of the two main reasons I had for buying a new mobo for Qubes.  The other is that the new one has a hardware TPM and the one w/o PS/2 only has a firmware TPM, which isn’t recognized by Qubes or Ubuntu 18.10

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/uNmSPbt-9L0/unsubscribe.
To unsubscribe from this group and all its topics, 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/20190410102757.dbkavoizsjjt4mm5%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[jrsm...@gmail.com]

To be concrete and transparent, the mobo with PS/2 is a Gigabyte X299 Designare ex with four USB controllers and a header for a hardware TPM, which I’ve populated. The other mobo is an ASUS X299 Prime Deluxe II with no PS/2, five USB controllers and only supports a firmware TPM. Both are fantastic boards, but one is going back. If isolating USB kb and mouse to one controller that dom0 has exclusive access to is actually more secure than native PS/2 then I would lean toward keeping the ASUS and do without TPM.

[awokd]

jrsm...@gmail.com wrote on 4/10/19 7:13 PM:

> To be concrete and transparent, the mobo with PS/2 is a Gigabyte X299 Designare ex with four USB controllers and a header for a hardware TPM, which I’ve populated. The other mobo is an ASUS X299 Prime Deluxe II with no PS/2, five USB controllers and only supports a firmware TPM. Both are fantastic boards, but one is going back. If isolating USB kb and mouse to one controller that dom0 has exclusive access to is actually more secure than native PS/2 then I would lean toward keeping the ASUS and do without TPM.
>

I'd keep the Gigabyte after confirming Qubes works on it and lspci lists
those 4 USB controllers individually and sys-usb works as expected. You
could still dedicate a USB controller if you wanted, and keep the
options open for TPM and PS/2. USB vs. PS/2 keyboard is a judgment call.
Check the papers linked to in
https://www.pcworld.com/article/161166/article.html, and Qubes
documentation
https://www.qubes-os.org/doc/device-handling-security/#security-warning-on-usb-input-devices.
Don't know if there's any newer research. Consider too that small video
camera bugs to record keystrokes are inexpensive, or that the entire
keyboard could be replaced with a bugged version, which would make the
PS/2 vs. USB distinction moot. You need to balance the likelihood of
possible attacks with your comfort level.

[jrsm...@gmail.com]

This is great input. This box will be in my home office on my home network (Xfinity), and I have no reason to think that anyone would be interested enough in what I’m doing to invest the resources necessary to enter my home when no one is there and plant surveillance. This is more about understanding risks and getting smarter about protecting my privacy. Plus I just think Qubes and Whonix are among the very few things in this world with noble goals and real solutions and I would eventually like to learn enough to make meaningful contributions.

Just the fact that I’m on my home network precludes any sort of serious attempt at anonymity. If I needed that, I’d use a laptop, hotspot, and bitcoin bought through a cut-out, leave my cell phone at home, find a location far from any place I frequent, and get on a network that has no links back to me. Yeah, I read Kevin’s new book. :)

[jrsm...@gmail.com]

I see now why you phrased it the way you did ("If you really have 4 USB controllers..."). After running `sudo lspci -vv | grep -i usb` and getting back only two hits as dom0 I began digging. After all, my mobo docs and box says:

Chipset+Intel ® Thunderbolt TM 3 Controller:
- 2 x USB Type-C TM ports on the back panel, with USB 3.1 Gen 2 support
Chipset+ASMedia ® USB 3.1 Gen 2 Controller:
- 1 x USB Type-C TM port with USB 3.1 Gen 2 support, available through the
internal USB header
Chipset+Realtek ® USB 3.1 Gen 1 Hub:
- 4 x USB 3.1 Gen 1 ports on the back panel
Chipset:
- 4 x USB 3.1 Gen 1 ports available through the internal USB headers
- 6 x USB 2.0/1.1 ports (2 ports on the back panel, 4 ports available through
the internal USB headers)

so *obviously* there are four USB controllers, right? I can account for one of them not showing up, that's the controller in the Tunderbolt chipset. This shows up in Ubuntu as one of three USB controllers seen by lspci, but Qubes doesn't see it. The fourth could be the USB 3.1 Gen 2 front panel controller, which I haven't populated yet.

Some of the docs I ran across describing lsusb looked promising, but then they would say something like, "you can see from the output above that there are two controllers", but it wasn't clear to me which were controllers vs hubs. I did learn that some controllers have multiple hubs (say USB 2.0 and USB 3.0), but it's much less straightforward to clearly identify the USB controllers than I thought it would be. I'm no longer sure that even that is the correct way to look at it since there could be multiple controllers on the same PCIe bus and the level of granularity we have to work with in Qubes is at the PCIe level.

[Ilpo Järvinen]

You could see if your bios allows disabling USB3/XHCI for the chipset
USB controllers. There are some USB combining tricks on some MBs that
might eat away (two) ehci controllers (and output only one xhci
controller).

--
i.