Suggestion: Virtual keyboard to defend against audio keylogging

Just a quick suggestion: A virtual keyboard that one clicks would go a long way in fending off attackers with an ear on the target.

As most of you probably already know, it has long been possible to replicate a user’s keystrokes just by using the audio from typing alone. With recent advances in machine learning, this is even easier and more deadly.

One simple way to dealing with this is to have a virtual (on-screen) keyboard that’s clicked on–this high-effort method would at least allow users to enter their passwords and other urgently sensitive things in peace.

Is it possible to implement this in dom0?

Yes, I have it on an x230t.
Install xvkbd in dom0 - then toggle script bound to F12 key.
You can run with -secure option: this may be available in other
virtual keyboards.

1 Like

There is also another side of the story: entering passwords on virtual keyboard is easier to sniff by nearby people / cameras.
But also, allowing password entry with only a mouse (especially unlocking the screen) means a malicious mouse (or anything connected to sys-usb) can try to do that (by default USB mouse is allowed but not USB keyboard on assumption that mouse is not enough to unlock the screen). Some more details here:


Just tested this and it’s exactly what I wanted. The -secure option is the icing on top. Thanks, unman.

This is good to know, but I see audio as the hardest side channel to protect because it’s omnidirectional and penetrative (passes through objects).

Though it’s easier to sniff my input on a virtual keyboard if I’m working in a public space, the problem can be solved by blocking vision one way or another–queue the weird looks from the other patrons of the cafe when you suddenly flip the back of your jacket to create a secure enclosure. With sound, you need thick, specialized insulation to block the vibrations to be entirely safe, since people have even found ways to read sound from the vibrations of window panes and empty potato chip packets using lasers. Another option is to use obfuscation to drown out your sound, but this is highly technical and risky.

Not producing the sound in the first place (or not producing identifiable patterns of sound that can be used for audio keylogging) is best. Based on my comparatively limited knowledge of infosec, USB mice seem like an extremely minor risk since a USB mouse that’s able to know where the virtual keyboard interface is on the desktop, what size it is, the mouse sensitivity settings, etc. is one that probably needs its own operating system–but since I’m using a touchpad (as I believe most Qubes users are), this point is moot.

Are these correct ?
To prevent keylogger, we use virtual keyboard.
To prevent audio keylogging, we use xvkbd.

How about RAT (remote access trojan) ?
How to prevent RAT ?
RAT allow attacker to see what we click on virtual keyboard.
Can RAT penetrate Qubes ?

Please help me with xvkbd installation steps in the link below.

A virtual keyboard will not necessarily defeat keyloggers.

You go some way to preventing a RAT by exercising good security measures
within Qubes.
Use disposableVMs where possible; limit exposure to the network; use a
variety of templates, and limit package installation to only what is
Use offline mail readers, and file viewers.
Limit your exposure to malware.

Learn how Qubes works to protect you - that way you wont undermine those


pardon me, some things I don’t understand, with the discussion above,

what’s the difference between:

  • virtual keyboard that one clicks, and
  • virtual (on screen) keyboard that’s clicked on

why the 1st one is vulnerable to audio keylogging ?
why the 2nd one can prevent audio keylogging ?
why xvkbd can prevent audio keylogging ?

is it compulsory / preference to bound xvkbd with F12 key ?
regardless compulsory or preference, is there a specific reason why we choose F12 key ?

Anyone know pros and cons between xvkbd and kvkbd ?