Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

Jasper St. Pierre jstpierre at mecheye.net
Thu Mar 24 18:49:37 UTC 2016


I think this should be done at the application level. If an
application is running, it has many other ways to fingerprint your
computer, including listing the files in your homedir, checking cpuid,
MAC address, etc. The issue here is that there is an application
platform that runs untrusted user code, which has tried hard to get
rid of fingerprinting identifiers (however, I believe window size,
installed fonts and GPU rendering differences remain the primary
fingerprint identifiers at this point for ad networks). The randomness
in the event stream should be done in the air-gap between the trusted
code and the untrusted code.

Too many other use cases require completely accurate timing, and I'm
not convinced a generic solution for defeating trusted code is a good
idea. Perhaps a library can be shared between implementations.

On Thu, Mar 24, 2016 at 6:18 AM,  <bancfc at openmailbox.org> wrote:
> On 2016-03-24 12:45, Pekka Paalanen wrote:
>>
>>
>> Hi,
>>
>> that's interesting. Sounds like you are looking for volunteers to
>> implement what you want, right?
>
>
> Yes please. Unfortunately I don't know C or have the skill to code something
> like this myself.
>
>>
>> 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.
>
>
> I originally proposed this on the QEMU/Libvirt lists and we reached the
> conclusion that the Display-server or kernel is the best place for this to
> benefit as many people as possible.
>
> Someone replied with ideas about what an implementation would look like and
> he covers some of the problems you bring up:
> https://lists.nongnu.org/archive/html/qemu-discuss/2016-03/msg00024.html
>
>>
>> Another issue are gamers, who are going to hate you for messing up
>> their key timings, so this system must be user-controlled.
>
>
> Yes having this as an option people can change for specific usecases is the
> way to go. Per app or a global setting - which ever possible could work
> here.
>
>>
>> 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.
>>
>
> I posted on lkml but no one seems to show interest and within a few hours my
> message is already buried.
>
>>
>> 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
>>
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
> _______________________________________________
> 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



-- 
  Jasper


More information about the xorg-devel mailing list