Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1385720 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Proposal for Anti-Keystroke Fingerprinting at the Input Driver  Level Pavel Machek <pavel@ucw.cz> - 2016-04-23 21:50 +0200

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

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

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web