try kloak anti keystroke deanonymization tool and leave feedback

phabricator-migrator · February 19, 2024, 5:44pm

Information

ID: 583
PHID: PHID-TASK-7ar5yivbiglfplrtpbdy
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: High

Description

Protection tool for Whonix, Tails · Issue #1 · vmonaco/keystroke-obfuscation · GitHub
GitHub - vmonaco/kloak: Keystroke-level online anonymization kernel: obfuscates typing behavior at the device level.

blockers for production use:

Repeating keys, leads to memory error · Issue #1 · vmonaco/kloak · GitHub

Comments

marmarek

2016-12-24 22:20:24 UTC

Patrick

2017-01-01 21:58:47 UTC

Patrick

2017-01-02 18:50:00 UTC

Patrick

2017-01-02 19:16:12 UTC

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.)

HulaHoop

2017-01-02 20:37:41 UTC

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.

Combination of custom native keyboard layout and Whonix can get you deanonymized after VM exploit?

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] Keystroke dynamics - Wikipedia
[3] http://www.ipcbee.com/vol13/32-R007.pdf - sourced from Wikipedia page

HulaHoop

2017-01-02 20:47:13 UTC

Patrick

2017-01-02 21:15:26 UTC

Patrick

2017-01-02 23:34:10 UTC

! In T583#11246, @HulaHoop wrote:
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.

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).)

HulaHoop

2017-01-03 17:01:33 UTC

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.

Patrick

2017-01-04 20:26:12 UTC

marmarek

2017-01-06 01:50:58 UTC

! In T583#11241, @Patrick wrote:
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?!

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).
! In T583#11245, @Patrick wrote:
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
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).

! In T583#11247, @HulaHoop wrote:
Slightly offtopic: The whole idea of keystroke biometrics for security is retarded because of replay attacks. An adversary can capture and spoof this.

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.

Patrick

2017-01-06 18:08:22 UTC

Patrick

2017-01-06 18:25:42 UTC

! In T583#11254, @marmarek wrote:

! In T583#11241, @Patrick wrote:
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?!

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).

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.)
! In T583#11245, @Patrick wrote:
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
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.

! In T583#11247, @HulaHoop wrote:
Slightly offtopic: The whole idea of keystroke biometrics for security is retarded because of replay attacks. An adversary can capture and spoof this.

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.

Patrick

2017-01-10 11:58:31 UTC