Feature Request: Anti-Keystroke Fingerprinting Tool

[HulaHoopWhonix]

Keystroke fingerprinting works by measuring how long keys are pressed and the time between presses. Its very high accuracy poses a serious threat to anonymous users.[1]

This tracking technology has been deployed by major advertisers (Google, Facebook), banks and massive online courses. Its also happening at a massive scale because just using an interactive JS application in presence of a network adversary that records all traffic allows them to construct biometric models for virtually everyone (think Google suggestions) even if the website does not record these biometric stats itself.[2] They have this data from everyone's clearnet browsing and by comparing this to data exiting the Tor network they will unmask users.

As a countermeasure security researcher Paul Moore created a prototype Chrome plugin known as KeyboardPrivacy. It works by caching keystrokes and introducing a random delay before passing them on to a webpage.[3] Unfortunately there is no source code available for the add-on and the planned Firefox version has not surfaced so far. There are hints that the author wants to create a closed hardware solution that implements this which does not help our cause.

A very much needed project would be to write a program that mimics the functionality of the this add-on but on the display server / OS level. Ideally the solution would be compatible with Wayland for the upcoming transition in the near future.

[1] http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/

[2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795

[3] https://archive.is/vCvWb

[adrelanos]

Confirmed. This affects anonymity / Whonix.

A very much needed project would be to write a program that mimics the functionality of the this add-on but on the display server / OS level. Ideally the solution would be compatible with Wayland for the upcoming transition in the near future.

Sounds like a great solution. Unfortunately this is outside my abilities. Help welcome!

[rootkovska]

Looks like this could be a simple modification to Qubes GUI daemon. Of course would have to be opt-in enabled for select VMs only.

[sdffgh]

Unfortunately there is no source code available for the add-on

There is! Chrome Extensions are just are zip files with some added metadata. If we unzip the extension's crx file, all the relevant code is a few lines in js/input.js.

See Tim's comment on https://paul.reviews/behavioral-profiling-the-password-you-cant-change/#comment-2165097313 where he includes a paste of the source code, the discussions below on the choices, and Paul's comment "If you strip away the fundamentals required to make a chrome extension, the code is just 13 lines long".

There is no license mentioned. One of you who knows more about licenses and legality can better decide how to proceed. If it's legal, maybe we could just reconstruct Paul's technique that he described publicly without looking at his code. The javascript basically just adds random delays and other implementation details are only meant to delay the js thread to disrupt timing of keystroke-initiated browser events, but that is unnessary if the delays are introduced outside the VM, and therefore outside the browser. In that case it is sufficient to just add random delays to keystroke times. The tests to confirm that this works against the bank fingerprinting demo are also very simple and can be reproduced if we're not sure that the new code has the same effectiveness as Paul's.

[adrelanos]

Related:

• kloak (anti keystroke deanonymization tool) - https://github.com/vmonaco/kloak
• provide Linux kernel input device so kloak (anti keystroke deanonymization tool) can be used in Qubes-Whonix - provide Linux kernel input device so kloak (anti keystroke deanonymization tool) can be used in Qubes-Whonix #2558
• Keyboard/Mouse Fingerprinting Defense - https://phabricator.whonix.org/T542
• keep an eye on kloak anti keystroke deanonymization tool - https://phabricator.whonix.org/T596

[iacore]

A simpler solution to this is to block tracking scripts using an ad blocker, and visit Facebook in separate VM (or don't visit at all).

Maybe running kloak in dom0 as sudo will work.

[adrelanos]

A simpler solution to this is to block tracking scripts using an ad blocker, and visit Facebook in separate VM (or don't visit at all).

Blocking is a denylist approach and will always be a game of whack-a-mole and miss some things. Hence not a reliable approach. And not limited to facebook. I don't know if facebook does this. Could happen anyhwere.

Maybe running kloak in dom0 as sudo will work.

That would work but the kloak would needlessly apply to dom0 and all other VMs too. Since kloak might cause some (and currently even some nasty bugs such as vmonaco/kloak#31) I wouldn't recommend it.

[adrelanos]

Quote #2558

kloak (anti keystroke deanonymization tool) currently cannot be used inside Qubes.

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

[andrewdavidwong]

@bluesteal: Please note that the issue tracker (qubes-issues) is not intended to be a place for fielding questions. Instead, we have other venues meant for asking questions, asking for help, and having discussions. (By contrast, the issue tracker is more of a technical tool intended to support our developers in their work.) Thank you for your understanding!

[adrelanos]

• enable qvm-service gui-agent-virtual-input-device for Whonix-Workstation App Qubes by default #8534
• Kloak in dom0 #8541

[ArrayBolt3]

It looks like this is just about ready to make work - I was able to get Kloak up-and-running inside a Whonix Workstation VM under Qubes R4.2 by doing the following:

• Launch a terminal in the whonix-workstation-17 template.
• In whonix-workstation-17, install xserver-xorg-input-evdev (this is required for the evdev-based keyboard input to work, if you don't do this your keyboard will be entirely non-functional within the VM)
• In whonix-workstation-17, install kloak.
• In dom0, run qvm-service whonix-workstation-17-dvm gui-agent-virtual-input-device on to enable the evdev-based input driver.
• Shut down whonix-workstation-17 and wait for it to fully shut down.
• Launch a DispVM from whonix-workstation-17-dvm.
• Open XFCE Terminal in the new DispVM.
• Ensure you can type.
• Run sudo systemctl stop kloak && sudo /usr/sbin/kloak -d250 & and ensure kloak starts properly.
• Type a bit in the terminal, you should notice significant lag and randomized timing as what you type appears on the screen.

The primary issue at this point is that we need xserver-xorg-input-evdev to be installed within Whonix Workstation in order to safely fix #8534. Otherwise the keyboard will become unusable in Whonix. This has to be done first, then the other ticket can be solved. Doing this will require a bit of orchestration. I think qubes-core-admin's API can be used for this, by making it so that the evdev input service is only enabled on Whonix Workstation VMs that advertise support for it, and that support is only advertised within Whonix Workstation if the evdev driver is present. But I'm not entirely sure that works, and am also slightly at a loss as to how I should test it.

Any thoughts?