We show that the MEMS gyroscopes found on modern smart phones are sufficiently sensitive to measure acoustic signals in the vicinity of the phone. The resulting signals contain only very low-frequency information (<200Hz). Nevertheless we show, using signal processing and machine learning, that this information is sufficient to identify speaker information and even parse speech. Since iOS and Android require no special permissions to access the gyro, our results show that apps and active web content that cannot access the microphone can nevertheless eavesdrop on speech in the vicinity of the phone.
Conclusion
We show that the acoustic signal measured by the gyroscope can reveal private information about the phone’s environment such as who is speaking in the room and, to some extent, what is being said. We use signal processing and machine learning to analyze speech from very low frequency samples. With further work on low frequency signal processing of this type it should be possible to further increase the quality of the information extracted from the gyro.
This work demonstrates an unexpected threat resulting from the unmitigated access to the gyro: applications and active web content running on the phone can eavesdrop sound signals, including speech, in the vicinity of the phone. We described several mitigation strategies.
Some are backwards compatible for all but a very small number of applications and can be adopted by mobile hardware vendors to block this threat. A general conclusion we suggest following this work is that access to all sensors should be controlled by the permissions framework, possibly differentiating between low and high sampling rates.
Some thoughts on privacy if software vulnerabilities are exploited:
Legend:
+++ High risk
++ Medium risk
+ Low risk
Note 1: Wifi and Bluetooth can be used to spy on user with connected device with a microphone (headset, …)
Note 2: Gyroscope/accelerometer can be used to reveal type of vehicle (car, airplane, …)
Why, you can have a sliding switch-board. But I don’t trust switches. It should be sliding patch-board. Removed jumper - no connection. Need to make a call - no probs, shift the board, pick a jumper from the pool, put it in - et voilà !
Some thoughts on this: turning sensors off is absolutely valid, of course.
But don’t overdo it with the kill switches that are placed on the case. Combining some of the ideas mentioned in killswitch design submission, we could have
Keep in mind, software kill switches are perfectly fine as long as you have some basic trust in your device, or at least the kernel. (A watchdog could tell you which sensors are active / have drivers loaded). And if you don’t trust your device, you will most likely just turn most of the internal kill switches off for good and quadruple-check if they are really off.
I think the circle of users who would toggle the gyroscope on a regular basis is really small. To me, it makes a ton more sense to have a browser that does not grant access to sensor data by default.
As you might have noticed, I included the devices with external switches also for internal ones. This way you can turn them off completely, without accidently turning them on. Also, one could turn off BT internally, and this way the WiFi/BT switch becomes a Wifi switch.
I was looking how small internal DIP switches could be. I found these, allowing 12 switches in about 8x16mm.
I also like that slider idea for the camera lens, saving one kill-switch on the side.
Would be extra cool, if the slider would double as shutter-release button when slid open, and of course slide-open would open the camera app. (And un-muting the microphone would accept the incoming call, as somebody suggested before).
