Proposal for Anti-Keystroke Fingerprinting at the Input Driver Level

Proposal for Anti-Keystroke Fingerprinting at the Input Driver Level

[bancfc]

== 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 OS 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.

GenodeOS a security centric microkernel OS has already implemented a 
solution: https://github.com/genodelabs/genode-world/issues/12

QubesOS a security centric OS based on Xen will add a fix to deal with 
it.

A widely deployed Linux 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 kernel ensures absolutely everything consuming input events on 
a workstation is protected.


[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

Re: Proposal for Anti-Keystroke Fingerprinting at the Input Driver Level

[Pavel Machek]

On Wed 2016-03-23 23:40:49, bancfc@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 OS 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.
> 
> GenodeOS a security centric microkernel OS has already implemented a
> solution: https://github.com/genodelabs/genode-world/issues/12
> 
> QubesOS a security centric OS based on Xen will add a fix to deal with it.
> 
> A widely deployed Linux 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 kernel ensures absolutely everything consuming input events on a
> workstation is protected.

/proc/interrupts is world-readable on my machine. That's where you'd
need to start.

Now, introducing random delays into input... I'm not sure I'd like
that... how long delays would you need?

OTOH: currently applications can easily get both keyboard presses and
keyboard releases. We could probably randomly delay releases by a
small ammounts without any ill effects. Would that help?

Oh and you probably want to cc: input mailing lists for such stuff.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html