[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #16110 [Tor Browser]: Improve Time Resolution Defense



#16110: Improve Time Resolution Defense
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:
     Type:  defect                               |  mikeperry
 Priority:  normal                               |         Status:  new
Component:  Tor Browser                          |      Milestone:
 Keywords:  ff38-esr, tbb-fingerprinting-time-   |        Version:
  highres                                        |  Actual Points:
Parent ID:                                       |         Points:
-------------------------------------------------+-------------------------
 Hovav Shacham and Keaton Mowery saw #1517 and emailed to point out some
 papers from the virtualization literature that have tried to deal with
 timing-based side channels. It turns out that simply reducing the
 granularity of the clock can still allow an adversary to extrapolate the
 true time by running a busy loop with a predictable operation in it. They
 provided a simple test that I updated and posted here
 https://people.torproject.org/~mikeperry/transient/tests/timingtest.html.
 It is able to recover the original time value with ~1-5ms accuracy.

 They linked to this paper
 https://cseweb.ucsd.edu/~hovav/dist/xentimers.pdf, and suggested that the
 best approach would be:


 > Pick some nominal granularity x.  Then define a distribution (normal?)
 with mean at x. Clocks available to the program only ever show an exact
 multiple of x, with a clock-edge on transition.  But they are lies:
 Immediately after a clock edge, the monitor draws some value t out of the
 distribution with mean x, and then sets a time-t timer; when that timer
 fires, the clock shown to the program is increased by x, and the monitor
 draws a new value t and continues.


 In other words, we'd still report 100ms steps, but change when we bump
 that step by +/- 50ms or so, based on a random value.

 While I'm at it, I should also see how well using
 window.requestAnimationFrame and setTimeout can reconstruct the clock.

 Firefox 38 also added a bunch more time sources to window.Performance, and
 also added Performance API support to WebWorkers and SharedWorkers.
 There's also a new animation API (https://developer.mozilla.org/en-
 US/docs/Web/API/AnimationPlayer).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16110>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs