Malicious use of the phone's Gyroscope

[Yossioren]

(I originally opened this as https://github.com/w3c/deviceorientation/issues/30 , but it looks like all the cool kids are hanging out here now...)

Dear Sirs/Madams,

Our team at Ben Gurion University has discovered an attack which takes advantage of a mobile device's gyroscope (either directly or through the Javascript DeviceOrientation API) to exfiltrate data. The attack requires that the adversary place a simple hardware device (basically a high-frequency speaker) next to the device under attack. In contrast to the "Gyrophone" attack from 2014 [1], reducing the sampling rate of the gyroscope does not prevent our attack. To mitigate this attack, we think it's a good idea to limit access to the orientation API. One way to achieve this is to ask the user's permission before enabling this API. Another way is to limit access to web pages delivered from insecure origins, as Chrome does for the Location API [2].

I'd be glad to attach a draft of our technical report to this issue, if there's some way to (temporarily) restrict access to it. Of course I'll be glad to mail the report to anybody on the standards team.

Sincerely, Yossi Oren.

[1] Yan Michalevsky, Dan Boneh and Gabi Nakibly Gyrophone: Recognizing Speech from Gyroscope Signals https://crypto.stanford.edu/gyrophone/ [2] Chromium Security Team, "Deprecating Powerful Features on Insecure Origins", https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

Cross-references:

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1276177 Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=615348 Safari: 641640531 IE: 33653

[tobie]

Hi. Thanks for your report.

To mitigate this attack, we think it's a good idea to limit access to the orientation API. One way to achieve this is to ask the user's permission before enabling this API. Another way is to limit access to web pages delivered from insecure origins, as Chrome does for the Location API [2].

Yes. Both are planned and spec'ed already (see secure context and permissioning).

Does the above alleviate your concerns?

[chaals]

I think we should consider listing the kinds of sensors where a known privacy or security issue may arise. I realise that we won't get all of them, which is something that gives me pause, but at least for the moment I think a number of them are likely to surprise a lot of people into thinking harder…

[tobie]

@chaals: Are you suggesting to list sensor-specific threat models? If so, I suggest these be added to the specs of the relevant concrete sensors rather than end up in the Generic Sensor spec. Thoughts?

[chaals]

I was more thinking of a snapshot of kinds of threats that different sensors allow, to help people ask the right questions. Quite possibly this is the sort of thing that would have a better home in the Privacy Interest Group, but input from experts here would be pretty valuable.

For (pointers to) more detailed stuff on given sensors, yes that should go in the specific specs

[Yossioren]

Hello Tobie, thanks for following up.

Looking at the permissions registry at https://w3c.github.io/permissions/#permission-registry https://w3c.github.io/permissions/#permission-registry I see no mention of orientation sensors. Are you planning to add an “orientation” permission to the registry in the future?

On 8 ביוני 2016, at 1:16, Tobie Langel notifications@github.com wrote:

Hi. Thanks for your report.

To mitigate this attack, we think it's a good idea to limit access to the orientation API. One way to achieve this is to ask the user's permission before enabling this API. Another way is to limit access to web pages delivered from insecure origins, as Chrome does for the Location API [2].

Yes. Both are planned and spec'ed already (see secure context https://w3c.github.io/sensors/#secure-context and permissioning https://w3c.github.io/sensors/#permissioning).

Does the above alleviate your concerns?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/sensors/issues/112#issuecomment-224431620, or mute the thread https://github.com/notifications/unsubscribe/AIkoT6qmGiKWayCoruKS9XSXe36JmX6Xks5qJe3SgaJpZM4IpKeu.

[tobie]

Yes, though I haven't looked into how granular to make that permission (e.g. should the gyroscope, magnetometer and accelerometer be grouped under the same permission or not, etc.). Input on this from a security and user-friendliness perspective would be quite useful, especially taking in account how often these sensors' outputs are fused together.

[Yossioren]

In my opinion adding too many choices (magnetometer, barometer, ohmmeter) is just shoveling the responsibility for security decisions over to the users. “orientation” seems to be the proper resolution at which to address this.

On 8 ביוני 2016, at 9:06, Tobie Langel notifications@github.com wrote:

Yes, though I haven't looked into how granular to make that permission (e.g. should the gyroscope, magnetometer and accelerometer be grouped under the same permission or not, etc.). Input on this from a security and user-friendliness perspective would be quite useful, especially taking in account how often these sensors' outputs are fused together.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/sensors/issues/112#issuecomment-224497344, or mute the thread https://github.com/notifications/unsubscribe/AIkoT4fYef15LidC96kQ3gqhbTZb4d_eks5qJlvagaJpZM4IpKeu.

[richtr]

I'm wondering if there are alternatives to simply putting orientation behind opt-in permissions.

For example, if the spec explicitly states that orientation events must be paused/suspended if the page, tab or browser is in the 'background' whether this could alleviate the security concerns.

If the user must be directly interacting with the target web page and not their bank, phone lock screen or any other service does the security concern still exist?

[tobie]

For example, if the spec explicitly states that orientation events must be paused/suspended if the page, tab or browser is in the 'background' whether this could alleviate the security concerns.

See Browsing Context for this.

[richtr]

It may then make sense to require user opt-in for background-capable orientation in the future if/when such a thing is possible via e.g. Service Workers.

Background orientation could be useful for things like pedometers but, in almost all other cases, web developers tend to usually need orientation events to draw something to the screen - hence why the distinction between foreground and background usage could be very useful.

[tobie]

It may then make sense to require user opt-in for background-capable orientation in the future if/when such a thing is possible via e.g. Service Workers.

Agreed. We've punted on this for the time being, however. We'll tackle it in V2.

[lknik]

@chaals I fully agree to list even potential risks of sensor use. In fact, I am working on doing just that with http://lukaszolejnik.com/SensorsPrivacyReport.pdf and the W3C Note we started to discuss on the list.

I am also wondering if, perhaps, levels of sensitveness would help. Some default arrangement based on default configuration (easy to change later) for a user-agent, i.e. that some "more sensitive" sensors require explicit permissions by default, and others may be used without prompting the user (unless he changes this). More granular, with some old IE-like settings.

[maryammjd]

@Yossioren can I please have a version of your paper?

[tobie]

This seems fixed by requesting permission, secure context and only providing access in a top-level browsing context.

Please feel free to reopen otherwise.