Messages in this thread | | | Date | Sat, 23 Apr 2016 21:49:12 +0200 | From | Pavel Machek <> | Subject | 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
| |