Description
Details
- Impact
- Normal
Related Objects
Event Timeline
The above application grabs the input device, randomly delays the key
events, and writes the events to a user-level input device via uinput.
FWIW this approach should work on Qubes (i.e. should be compatible with
qubes-gui-agent).
Wondering... Where are we going to install that tool? Wouldn't the anti keystroke deanonymization tool be better installed on the host / dom0 rather than inside Whonix VMs?
- a) Having it installed inside the VM defeats keystroke deanonymization by remote servers (ssh, web, ...). Would be great!
- b) Having it installed on the host / dom0 defeats a) as well as defeats keystroke deanonymization after VM compromise? Would be even better, no?!
Why not combine a) and b)? Or would using kloak twice perhaps mess something up?
Wondering what your thoughts are and depending on that we may follow up asking the author of kloak for advice.
Related:
this recent concern on native keyboards vs exploited VMs and keyboard layout based deanonymization
Haven't tried kloak myself yet. Will do so soon.
b) however when using clearnet (using non-Whonix connections) would lead to servers (ssh, web, ...) that are doing keystroke fingerprinting, these servers knowing that an anti keystroke fingerprinting tool is being. (For example when using a clearnet VM for banking or so.)
- In the best case we could say - never mind, they can do loads of other fingerprinting techniques anyway when not using Tor Browser / Whonix.
- In the worst case services that do keystroke fingerprinting for security purposes (such as banks) could trigger a false positive (user unable to log in due to triggering the fraud detection system). How likely is that?
Currently trying inside Qubes-Whonix-Workstation using kloak usage instructions. However, reached a dead end for now.
sudo ./eventcap /dev/uinput
Reading From : /dev/uinput (Unknown) read(): No such device
There is no input device in /dev/input folder either. Where is the "/dev/input/event4" keyboard device file equivalent in Qubes VMs if any? @marmarek
(Compilation of kloak was super simple. Just run make.)
Wouldn't the anti keystroke deanonymization tool be better installed on the host / dom0 rather than inside Whonix VMs?
Yes. System wide protection and resistance to being disabled by root malware in a VM.
Why not combine a) and b)? Or would using kloak twice perhaps mess something up?
Combining them would needlessly introduce longer delays and impact UX. As long as one instance works anything more is redundant.
Non-English typist fingerprinting:
- A keylogger compromised VM + typing in a rare native language will narrow down the anonymity set.
- non-English words have a higher fingerprinting success rate. [1] But given how efficient it is for English too I wouldn't say it matters also if the comment ends up published on the internet in that language then this threat model doesn't matter and is part of the general problem of Tor adoption.
- According to a non-cited statement on the Wikipedia keystroke biometrics page [2] - The way a person types their native language's common sequences even when they are writing entirely in a different language, is just as revealing as an accent is in spoken English.
- Have not found anything on keyboard layout fingerprinting. What I've seen mentioned as background information is different keyboard (hardware not layout) do alter an individual's keystroke fingerprint but there are techniques to compensate for this.[3]
Conclusion: Picking the virtual hardware keyboard's layout to match the most common one is good practice. Since kloak randomly delays all presses it should be enough to destroy these other characteristics and to muddy the waters.
[1] https://www.comp.nus.edu.sg/~tsim/documents/keystroke-dynamics-published.pdf
[2] https://en.wikipedia.org/wiki/Keystroke_dynamics
[3] http://www.ipcbee.com/vol13/32-R007.pdf - sourced from Wikipedia page
In the worst case services that do keystroke fingerprinting for security purposes (such as banks) could trigger a false positive (user unable to log in due to triggering the fraud detection system). How likely is that?
Generally its ok if they know fingerprinting is used. However in situations where you are absolutely compelled to provide a fingerprint for access you would temporarily disable it for banking.
Slightly offtopic: The whole idea of keystroke biometrics for security is retarded because of replay attacks. An adversary can capture and spoof this.
Commented initial feedback here:
https://github.com/vmonaco/keystroke-obfuscation/issues/1#issuecomment-270020900
Yes, that's what I had in mind.
Why not combine a) and b)? Or would using kloak twice perhaps mess something up?
Combining them would needlessly introduce longer delays and impact UX. As long as one instance works anything more is redundant.
If one runs on the host, the one in the VM is redundant indeed. However, we need to think through what happens in such cases. Running kloak on host and VM at the same time could actually make keystroke deanonymization easier. So if we go for installation of kloak on the host, perhaps if the package is installed in the VM it should do nothing. (systemd ConditionVirtualization=false [untested]) (Forethinking here, if that package ends up in Debian repository and gains popularity and users install it in the VM as a "want to have".)
On the other hand, if kloak is not [easily from distribution package repository] available on the host, having it installed inside the VM would be better than nothing. (Not defeating b), but at least defeating a).)
So if we go for installation of kloak on the host, perhaps if the package is installed in the VM it should do nothing. (systemd ConditionVirtualization=false [untested]) (Forethinking here, if that package ends up in Debian repository and gains popularity and users install it in the VM as a "want to have".)
Yes that's the right way to go about this.
On the other hand, if kloak is not [easily from distribution package repository] available on the host, having it installed inside the VM would be better than nothing. (Not defeating b), but at least defeating a).)
I am counting on it being available in Whonix repo so I can install it on the host. Long term plan is to get it in Debian as this deserves to be used everywhere possible. For Qubes I'm sure you can work out including it in Dom0.
I asked anyway because it would be good to know anyhow. This can be tested too against keytrac.
While indeed having it host-wide would be better for anonymity, it will significantly degrade UX. For example it will make interactive games mostly useless. So, if we want it in default configuration - do that only in Whonix VMs. We may include it as an _optional_ dom0 package for system-wide installation - if there is rpm packaging (or can be easily added).
Hmm, I was under impression it expect X server input device, not not Linux kernel input device. Qubes GUI agent do not expose the later. It shouldn't be hard to change that, but still it is some code change. Namely, rewrite this function (feed /dev/uinput instead of X input device).
I don't agree here - it greatly depends on the threat model. For example I've seen its use for electronic school register (which was deployed as a web application). Students were highly creative to spy on passwords (small mirrors, mobile cameras etc), but it wasn't enough to reply type pattern accurately enough - at least in most cases. The solution was enough for this use case and much easier to use for (mostly non-technical) teachers than most of 2FA solutions.
Done.
- https://github.com/adrelanos/kloak/commit/db8aa69d975664080da5fb8fcdb15129c5aee263
- https://github.com/adrelanos/kloak/commit/ab75d19d5894c4413488d7b82c6752423226b8a3
- https://github.com/adrelanos/kloak/commit/0815f830ffae193b04cc68a50f2f499889c0c29f
I see.
Perhaps this can become an option in Qubes installer (next to the other Whonix options). But one step at a time...
(... Sorting out Debian packaging with upstream, waiting for upstream to fix the blockers mentioned in the links from my previous comment, perhaps upstreaming the Debian package to debian.org repository, sorting out rpm packaging, making it available as optional Qubes rpm package.)
Hmm, I was under impression it expect X server input device, not not Linux kernel input device. Qubes GUI agent do not expose the later. It shouldn't be hard to change that, but still it is some code change. Namely, rewrite this function (feed /dev/uinput instead of X input device).
Created provide Linux kernel input device so kloak (anti keystroke deanonymization tool) can be used in Qubes-Whonix for it.
I don't agree here - it greatly depends on the threat model. For example I've seen its use for electronic school register (which was deployed as a web application). Students were highly creative to spy on passwords (small mirrors, mobile cameras etc), but it wasn't enough to reply type pattern accurately enough - at least in most cases. The solution was enough for this use case and much easier to use for (mostly non-technical) teachers than most of 2FA solutions.
It's rather about goals. Probably safe to say, HulaHoop is happy with no less than perfect security. Some admins (like banks or universities) decided to be happy using a solution that may only work for a limited amount of time and that only stops most less dedicated abusers since there are not that many dedicated abusers.