On 14/03/2016 16:54, ban...@openmailbox.org wrote:
Intended for qemu-discuss
/cc/ libvir-list, whonix-devel, tor-dev
***
Hello. I work on WhonixOS an anonymity distro based on Tor. This
feature request is related to the topics of privacy and anonymity. Its
a complex topic and probably not in your area of focus but I think it
has important implications because security and privacy are very much
related in today's hostile computing environment.
Virtualization is useful in presenting an identical environment and
set of "hardware" for each user which goes a long way in creating an
anonymity set of systems. That way a system attacker, advertisers and
online trackers would not be able to fingerprint a user or their
hardware.
The problem: 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 [2].
Keystroke dynamics is a super creepy way to track users based on how
long they press keys (dwell time) and the time between key presses
(gap time). This is extremely accurate at identifying individuals
because of how unique these measurements are. Advertising networks
(Google, Facebook...) that fingeprprint users on both the clearnet and
Tor can deanonymize users. This technique is already actively used in
the wild [6][7].
Potential Solutions:
Since input devices are all emulated its a great opportunity to stop
this profiling technique.
* A security researcher designed a proof of concept plugin for Chrome
browser that mitigates this. Implementing something like the PoC addon
in [1] known as KeyBoardPrivacy. Some random delay in milliseconds in
a 50 millisecond range for dwell and gap times for the emulated
keyboards is enough to skew the values to render this attack useless
while not affecting performance.
* The changes made to Tor Borwser to make JS timers more coarse
grained but constant (250ms for keyboard events) were not enough to
stop keystroke dynamics fingerprinting because a malicious script can
evict the cache and allow extrapolation of true timing events within
1-5ms accuracy .[3][5] Their goal is to instead add jitter to the
timers [4]. A similar solution proposed in [4] can be implemented in
all QEMU-KVM timers to mitigate both attacks.
[1]
https://paul.reviews/behavioral-profiling-the-password-you-cant-change/
[2]
http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html
[3]
https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166
[4] https://trac.torproject.org/projects/tor/ticket/16110
[5] https://trac.torproject.org/projects/tor/ticket/1517
[6] http://scraping.pro/no-captcha-recaptcha-challenge/
[7]
https://nakedsecurity.sophos.com/2013/11/01/facebook-to-silent-track-users-cursor-movements-to-see-which-ads-we-like-best/
Another option, when operating at a low enough level (OS,
qemu or anywhere else outside the browser sandbox) is to
rearrange keystroke events as follows:
Regular keys (letters, digits, characters, F-keys etc.)
are presented as if they are released right after each
keypress (0 or 1ms delay) regardless of actual dwell
time.
The 4 lock keys (caps, num, scroll and unshifted insert)
are similarly filtered as instantaneous presses.
Arrow keys etc. are filtered so short presses are reduced
to a single (0 or 1ms) short press while long
(autorepeating) presses are not (because good browsers
adjust the scroll rate to use the actual scroll speed
rather than the autorepeat time of the keyboard).
Shift keys (shift, ctrl, alt, some uses of the logo keys)
are filtered to appear as if pressed 1ms before the
affected key and released 1ms after. Shift key+mouse button
combinations also need to be handled.
All key times are rounded to multiples of some fixed
granularity clock (e.g. multiples of 50ms), except for the
simulated 1ms and 0ms delays above (which would then be
relative to the rounded times).
Additional considerations are needed for east Asian keyboard
layouts (China/Japan/Korea) due to their complex extra shift keys.
Some non-spying applications (browser and otherwise) may
need to be exempted because their user-oriented purpose is
to do unusual keyboard interpretations. I happen to make
one such application. Qemu itself is another. Games that
use letters as navigation keys (WASD etc.) or require precise
timing of key presses is a third group.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
