Keyboard/Mouse Fingerprinting Defense

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

Information

ID: 542
PHID: PHID-TASK-ap6oepvzftem26jv5m77
Author: HulaHoop
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

Attack summary: the timings of and between key presses are unique to each person. They are actively used in the wild to track individuals with extreme accuracy and leads to complete unmasking.

The only choices that seem available is to:

write a custom keyboard device driver [1] Difficulty very hard. Unlikely to get mainlined.
abstract the system keyboard input as an (internal) network stream that we can add random latency to before releasing it back to the system. (Idea inspired by [2])

The second option is best because its display server agnostic, system wide, easier to implement.

How option 2 would work:

Netevent is a program that redirects input events from the host to a specified destination. Naturally we can set the destination as the host too over the loopback interface. Apply the netfilter_queing rules by @ethanwhite on loopback to introduce random delays.

This package would run as service on host out of reach of malicious code in VM and to provide system wide protection.

Testing defense if it actually works:

Keyboard demos:

https://www.keytrac.net/

Mouse demo:
http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html

Mouse pointer motion fingerprinting is also another effective attack [4][5]. Luckily netevent also abstracts mouse input events.

[1] Protection tool for Whonix, Tails · Issue #1 · vmonaco/keystroke-obfuscation · GitHub
[2] windows - How can I introduce input lag (keyboard and mouse) to my system? - Stack Overflow
[3] Share devices over the net · Blub/netevent Wiki · GitHub (GPLv2)
[4] Advanced Tor Browser Fingerprinting
[5] http://www.cs.wm.edu/~hnw/paper/ccs11.pdf

Qubes Feature Request: Anti-Keystroke Fingerprinting Tool
try kloak anti keystroke deanonymization tool and leave feedback (done): T583
keep an eye on kloak anti keystroke deanonymization tool: T596

Comments

HulaHoop

2016-08-19 03:23:55 UTC

ethanwhite

2016-08-28 05:15:47 UTC

The first mitigation that comes to mind is to, similarly to T530, queue up all keyboard input events over a period of time (say, 30 milliseconds), and then process them all at once.

Orthogonal to ticket but as the first C package we are likely to ship, we must think about reproducibly building it and redundant ways to validate this.

According to [[How to comsume a keyboard event on Linux using input subsystem - Stack Overflow StackOverflow question]], we should be able to get exclusive access to keyboard events (i.e. the events won’t propogate past our handler) using only ioctl calls, which can be done in pure Python. Causing those events to be processed is somewhat harder, but one thing to consider is [[https://github.com/python-xlib/python-xlib|the Python X Library]]; if that were the case, we could do this 100% from pure python. One disadvantage to going the X Library route is that we’d need to make 100% sure that this fix is alive 100% of the time the X server is up, and 0% of the time it’s not; otherwise, the system would become unresponsive to keyboard events. A possible solution to that would be to use uinput instead (Python bindings are available).

EDIT: After re-reading the issue description, I realize that netevent is probably the way to go. We could choose two ports on localhost (thus using the loopback interface), and run the same netfilter_queue script, but with a shorter delay (on the order of 15-30ms). If the delay were anything like the 150ms used for external network connections, then the whole system would feel incredibly sluggish.

HulaHoop

2016-08-27 18:56:26 UTC

HulaHoop

2016-09-01 19:10:40 UTC

Patrick

2017-01-10 11:59:47 UTC

Patrick

2020-08-13 08:32:09 UTC