Re: sensor calibration fingerprinting

Here's our proposal for what to do in Chromium:
https://github.com/JensenPaul/sensor-fingerprint-mitigation

On Mon, Jan 13, 2020 at 5:39 PM Nick Doty <npdoty@ischool.berkeley.edu>
wrote:

> Regarding DeviceOrientation and research showing persistent
> fingerprintability based on factory calibration of orientation sensors in
> mobile devices; I’ll add some notes to the GitHub issue here [0], but since
> it might be worth longer discussion in PING, especially for how it applies
> to other sensors, I’m writing out these comments for the mailing list.
>
> From my reading of the paper [1], the authors suggest two mitigations that
> they seem to identify as resolving the issue altogether:
>
> 1. adding random noise of -0.5-to-0.5 to each value and then rounding to
> the resolution of the sensor (16 bits, in the case of the iOS devices in
> question)
> 2. rounding the output to the nearest multiple of the nominal gain of the
> sensor (61 or 70 millidegrees per second, in the case of the iOS devices in
> question)
>
> Those mitigations do seem to be hardware specific, so we might not be able
> to include hard numbers in the spec, but could still provide a normative
> indication that sensors should be rounded using the provided algorithm,
> based on their hardware details. If nominal sensor gain and sensor
> resolution are known for each device (*and* accessible to the browser from
> the underlying operating system), then those mitigation algorithms could be
> implemented by all browser implementers.
>
> I’m not entirely clear on this yet, but it also seems possible that we
> could do a survey of the accelerometers and gyroscopes currently in use by
> most mobile devices and then require no more precision than slightly below
> the typical or lowest precision sensor in the survey. Would that be a huge
> detriment to functionality? I’m not sure, but if I’m reading it correctly
> that the iOS devices measure a range of 4000 degrees per second with a
> resolution (and nominal gain) of 0.061, then we’d be talking about an extra
> error of 0.1 / 4000 = 0.0025%. That certainly sounds small, though I’m sure
> it depends on the particular use cases.
>
> We might also chat with Apple folks about the mitigations that they
> implemented in response to the paper; it sounds like they added noise
> before rounding and deployed that for native iOS devices. Did that cause
> functionality problems for iOS apps? Was the implementation different for
> every hardware version?
>
> This is all based on my non-expert reading of the “SensorID" paper, so I’d
> welcome more ideas from implementers or those more familiar with
> gyroscope/accelerometer sensors. I believe there will be some discussion of
> that at this week’s PING call (with regrets, I won’t be able to join, but
> will read the minutes).
>
> Because the authors demonstrated an in-the-wild risk of permanent (across
> factory reset of the device even) identifiers, there are good reasons for
> implementers and spec maintainers to try to implement short-term fixes, and
> some have over the past year in response to previous research (like
> permission gating). But the paper also suggests — and this is something I
> would really value input on from others — that other device sensors are
> likely to have similar risks of persistent cross-origin identification,
> based on being able to detect factory calibrations from a relatively small
> sample of readings. If we can understand what causes that risk, how to
> identify it and how to mitigate it, we can provide more specific guidance
> (in the fingerprinting guidance doc, or perhaps the threat model) and apply
> it to all new sensor specs that come up for review.
>
> Cheers,
> Nick
>
> [0] https://github.com/w3c/deviceorientation/issues/85
> There’s also some related discussion in
> https://github.com/w3c/deviceorientation/issues/57 although that thread
> goes a little off-topic, so it’s not the easiest to follow.
>
> [1] https://www.ieee-security.org/TC/SP2019/papers/405.pdf
> Zhang, Jiexin, Alastair R. Beresford, and Ian Sheret. “SensorID: Sensor
> Calibration Fingerprinting for Smartphones.” In 2019 IEEE Symposium on
> Security and Privacy (SP), 638–55. San Francisco, CA, USA: IEEE, 2019.
> https://doi.org/10.1109/SP.2019.00072.
>
>
>
>
> Previously discussed on public-privacy here:
>
> > On Oct 24, 2019, at 4:38 PM, Pete Snyder <psnyder@brave.com> wrote:
> >
> > 3. I double checked with the authors of the paper I linked to, and they
> say that the functionality they use to fingerprint devices (quote: “the
> DeviceMotionEvent APIs, particularly DeviceMotionEvent.acceleration and
> DeviceMotionEvent.rotationRate”) don’t require permissions to access.  The
> standard needs to be updated so that users cannot be passively
> fingerpritined.
> >
> > Also re the findings: the findings were that devices with high quality
> accelerometers are vulnerable.  The Pixel and iPhone devices they tested
> were all vulnerable; the other android devices they tested just had lower
> quality sensors.  As the avg quality of phones increase, more and more
> devices will be vulnerable then.  So its still an active harm / concern.
> >
> > I’ll open up issues for 1-3 in the repo now.
> >
> > Thanks,
> > Pete
> >
> >> On Oct 21, 2019, at 2:09 PM, Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
> >>
> >>
> >>> On 21. Oct 2019, at 22.40, Pete Snyder <psnyder@brave.com> wrote:
> >>>
> >>> In the meantime though, was wondering if your group was familiar with
> this work [1] on using sensor APIs for permission less fingerprinting, if
> the standard has been updated to fix / prevent these attacks, and if not,
> how the standard should be adopted to fix.  (TL;DR; you can derive devices
> w/ ~67 bit identifiers if they have accelerometers installed, using the
> sensor APIs).
> >>
> >> Thanks for the pointer.
> >>
> >> This paper published after the specs reached CR has not been discussed
> in the group. Other similar fingerprinting vectors brought to the group’s
> attention have been considered, however:
> >>
> >> https://w3c.github.io/sensors/#device-fingerprinting
> >>
> >> We could add this paper to the list of references for completeness.
> >>
> >> Mitigations are discussed in:
> >>
> >> https://w3c.github.io/sensors/#mitigation-strategies
> >>
> >> We could consider adding the other proposed mitigation (add uniformly
> distributed random noise to ADC outputs before calibration is applied) to
> the mitigations section. Permissions is already covered and the specs
> define hooks for prompting.
> >>
> >> As a general comment, it *seems* this particular attack was fixed in
> more recent iOS versions and on most or all(?) Android devices tested there
> was less entropy, so no global uniqueness.
> >>
> >> Suggestions (and PRs) from PING welcome.
> >>
> >> Thanks,
> >>
> >> -Anssi
> >>
> >>
> >>> Refs:
> >>> 1:
> https://www.repository.cam.ac.uk/bitstream/handle/1810/294227/405.pdf?sequence=3
>
>