Page MenuHomePhabricator

Keyboard/Mouse Fingerprinting Defense
Closed, ResolvedPublic

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.behaviosec.com/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] https://github.com/vmonaco/keystroke-obfuscation/issues/1
[2] https://stackoverflow.com/a/33134735
[3] https://github.com/Blub/netevent/wiki/Share-devices-over-the-net (GPLv2)
[4] http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html
[5] http://www.cs.wm.edu/~hnw/paper/ccs11.pdf


Related:

Details

Impact
Normal

Event Timeline

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.

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

According to the research:

https://github.com/vmonaco/keystroke-obfuscation

"Identification accuracy is reduced by 20% with a 25 ms random keystroke delay not noticeable to the user."

So I guess that should be the lower bound for this.

HulaHoop renamed this task from Keystroke Dynamics Defense to Keyboard/Mouse Fingerprinting Defense.Sep 1 2016, 7:06 PM
HulaHoop updated the task description. (Show Details)

Update:

Researcher Vinnie Monaco is creating a sampling distribution library that an obfuscating input driver prototype can use or our netqueue solution.

https://github.com/vmonaco/keystroke-obfuscation/issues/1#issuecomment-243433528

For reference, kloak is being tracked here:

  • try kloak anti keystroke deanonymization tool and leave feedback (done): T583
  • keep an eye on kloak anti keystroke deanonymization tool: T596
Patrick claimed this task.

Shipping kloak in Whonix stable for a few releases already.

https://www.whonix.org/wiki/Kloak

That fixes the keyboard part.

For mouse we documented it as known issue here:

https://www.whonix.org/wiki/Keystroke_Deanonymization#Future

For mouse feel free to open a new ticket in the new issue tracker:

https://www.whonix.org/wiki/Reporting_Bugs#Issue_Tracker