sensor calibration fingerprinting

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