Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

[Pekka Paalanen]

On Wed, 23 Mar 2016 23:49:03 +0100
bancfc at openmailbox.org wrote:

> == Attack Description ==
> 
> 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 a JS application (or SSH in interactive 
> mode) 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.
> 
> 
> == Current Measures and Threat Model ==
> 
> While the Tor Browser team is aware of the problem and working on a 
> solution, current measures [6] are not enough. [4][5]
> 
> It's very useful to have it fixed on the host OS (display server) level 
> so even compromised VMs could not perform keystroke fingerprinting. 
> Another reason is, that other applications (chat clients come to mind) 
> and others that implement javascript one or another way, may be leaking 
> this also. So having this fixed in Tor Browser is nice but non-ideal.
> 
> This is valid for systems running in VMs or on bare metal such as the 
> TAILS Anonymous distro.
> 
> 
> == Existing Work on Countermeasures ==
> 
> 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 USB device that implements 
> this which does not help our cause.
> 
> A widely deployed libre version only makes sense and would have the 
> greatest impact for security of most free/open systems out there.
> 
> 
> == Proposal for a System-wide Solution ==
> 
> A very much needed project would be to write a program that mimics the 
> functionality of the this add-on but on the kernel level. Implementing 
> it in the display server ensures absolutely everything consuming input 
> events on a workstation is protected.
> 
> Ideally the solution would be compatible with Wayland for the upcoming 
> transition in the near future.

Hi,

that's interesting. Sounds like you are looking for volunteers to
implement what you want, right?

I skimmed through [3], and I got the impression that what the software
does is to round key press and release times to the nearest multiple of
50ms or something along those lines.

I can immediately see one problem with that approach: key repeat.

Key repeat is based on a timer. On Wayland, that timer is currently in
the application, not in the kernel nor even in the display server. If
you skew the timings, you may screw up the repeats. For the record, it
seems the default repeat on Weston is 40 Hz, which means 25 ms period.
Rounding to nearest 50 ms sounds like a pretty big difference.

Another issue are gamers, who are going to hate you for messing up
their key timings, so this system must be user-controlled.

I suppose there is also a practical issue of synchronizing key events
to other input events. E.g. if you want to ctrl+click something, you
have to synchronize multiple input event streams under the same timing
fudging system to avoid the case where sometimes the key is not
accounted for when clicking.

All that makes me wonder if the kernel is a sensible place for this.
For a machine specifically built to be more secure at the expence of
usability by ignoring all the above issues, then perhaps.


Thanks,
pq

> 
> [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
> 
> [4] 
> https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166
> 
> [5] https://trac.torproject.org/projects/tor/ticket/16110
> 
> [6] https://trac.torproject.org/projects/tor/ticket/1517
> 
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160324/fab96497/attachment-0001.sig>