Originally published at: News - Whonix Forum Tracking techniques have become more sophisticated with time. They advanced from simple cookies to browser/device fingerprinting (which Tor Browser focuses on defeating) to user behavior fingerprinting. The latter is about profiling how a user types on a keyboard or uses a mouse.
Keystroke dynamics have been around for a while but the massive scale of deployment is new and comes with serious implications for anonymous users. This technology is already used by PRISM partners, banks and massive online courses.
Note that even if a user’s destination does not itself surreptitiously record biometrics, anyone observing the network traffic of SSH in interactive mode or JS applications (functionality like Google suggestions) can generate a model for your biometric statistics.
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. A Firefox add-on was planned but nothing has surfaced so far.
We don’t know how effective VMs are at blunting the threat. Read more if you are interested in helping out.
A very much needed project would be to write a program that mimics the functionality of the this add-on but on the OS level.
When someone is using ssh / vnc, one is specifically vulnerable (and ignorant) about keystroke fingerprinting, right?
Any way to work around the keystroke fingerprinting? ssh / vnc to server one, and from there ssh / vnc to server two perhaps?
I don’t think so because the connection from servers 1 to 2 will receive them in time delayed order they were sent.
*Never sending anything except over authenticated HSs. Thats a good idea for many reasons because exposed VNC/SSH services are large security holes. Tor’s encryption/anonymity properties should conceal the size and timing of keystrokes sent.
*In the case of SSH described in the paper (Spoofing key-press latencies with a generative keystroke dynamics model) this applies when interactive mode is enabled so an easy but limiting workaround is to disable it. VNC needs realtime interaction or else it would be terribly laggy and unusable.
*The proposed anti-keystroke tool should help wit all these usecases even if the communication is sniffed and without disabling functionality.
If that was to work, we could have some instructions on how one can VNC to its own locally running VNC server over Tor. I am very skeptic though, this does not actually open up more issues than it fixes. If it fixes any issues at all.