Gyrophone Attack: Q&A part 2

A journalist from the Danish Consumer Council has contacted me recently regarding our Gyrophone attack on mobile devices (published in 2014). I’m posting the questions and my answers to them. Note that I haven’t been keeping up with the most recent developments around gyroscope access on mobile device, so I encourage you to verify
the state of matters nowadays.

Q: Can Android phones with gyroscopes still read up to 200 hertz, being within the spectrum of the human voice?
A: There’s no one Android phone. Android is an operating systems with many versions currently being used by users. The access depends not only on the operating system but on the hardware capabilities as well. As far as I know gyroscope measurements are still accessible without special permissions to applications.
I’m not aware of protective measures taken to limit the available sampling rate by software or hardware vendors. However, as we already noted in the paper, the Chrome browser, and other browsers based on the WebKit framework, impose a software limitation on the sampling rate available from JavaScript, bringing it down to 25Hz. So at least Chrome protects its users from malicious access to gyroscopes.
What’s important to note, is that most of the human speech is beyond the sampling frequency, and the access to it is due to an effect named “aliasing”. Low-pass filtering can mitigate the attack. It seems for instance that Samsung Galaxy use hardware that applies certain low-pass filtering (I’m not sure on what frequency), and our phrase recognition attack did not perform as well on those phones as it did on Nexus 4 devices. As we did not test it on many different models, it remains to be studied how well it can perform on them.

Q: In 2014 the technique was not refined enough to pick up more than a fraction of the words spoken near a phone. What about now? Have gyroscopes in smartphones evolved enough to pick up entire sentences and conversations? From how far away can the gyroscopes pick up conversations?
A: The statement “the technique was not refined enough to pick up more than a fraction of the words” is inaccurate. In the experiments we did we purposely trained the algorithms on small sets of phrases to recognize. Since we did not conduct experiments with larger dictionaries, it remains to be studied how well it can perform for larger sets of phrases.
The task (as many other machine learning tasks) definitely becomes harder as the dictionary grows. Our aim was to show a proof of concept, but the full potential of the attack can only be understood by conducting more experiments.
The distance on which this can work depends on the loudness of the signal. If the signal is coming from a farther source but is loud enough, perhaps the attack can work. In our experimental setup, the source of the sound was pretty close to the device and was fairly loud. What can amplify the attack is a reverberant surface that responds to sound waves and conducts them well.
To calm things down, I believe that this attack won’t work well when the speakers are several meters away from the device with most gyroscopes. However, this is a very general claim, and it all depends on the particular hardware model and characteristics.

Q: Does the user of an Android phone need to give permission for recording before gyroscopes pick up sound and words? Does Google require the user to give permission for recording?
A: Android phones notify the user when an application requires access to the microphone. However (and that’s the point of our work) it doesn’t notify the user when an application accesses to the gyroscope, which is what enables stealthy eavesdropping. I’m not sure what you mean by Google, since that’s a property of the Android operating system (which is mostly maintained by them), and it’s important to not confuse the two. There are many Android distributions that come without pre-installed Google applications, and Google doesn’t have access to the data on those phone. It’s important to be precise about it and phrase it accurately. Since the Android OS is mostly maintained by Google, it might be a natural expectation that they would address such issues, however, since it is an open source system, technically inclined users can compile their own version of it, and mitigate the attack.

Q: Can the user choose not to be recorded (through gyroscopes)?
A: As far as I know, the user of a standard Android distribution doesn’t have an option to block access to the gyroscopes.

Q: What do Google do with the sound data they pick up via gyroscopes?
A: I don’t have any evidence that Google collects such data and does anything with it. And since Google anyway has access by default to Android devices, we need to worry about the general lesson from this attack, rather than about Google in particular. More important, is that any Android application can collect gyroscope data. So more than worrying about Google (that has reputation to maintain), we should be worried about malicious third-parties that have the same access to our data.

Q: Do you know if it is stored someplace or Google use it through voice recognition?
A: Again, there’s no evidence that Google records gyroscope data, stores it or uses it anywhere else except for on the phone itself. The point is that our work shows new implications of having potential to access this data.

PowerSpy: Location Tracking using Mobile Device Power Analysis

Our phones are always within reach and their location is mostly the same as our location. In effect, tracking the location of a phone is practically the same as tracking the location of its owner. Since users generally prefer that their location not be tracked by arbitrary 3rd parties, all mobile platforms consider the device’s location as sensitive information and go to considerable lengths to protect it: applications need explicit user permission to access the phone’s GPS and even reading coarse location data based on cellular and WiFi connectivity requires explicit user permission.

We showed that, despite these restrictions, applications can covertly learn the phone’s location. They can do so using a seemingly benign sensor: the phone’s power meter that measures the phone’s power consumption over a period of time. Our work is based on the observation that the phone’s location significantly affects the power consumed by the phone’s cellular radio. The power consumption is affected both by the distance to the cellular base station to which the phone is currently attached (free-space path loss) and by obstacles, such as buildings and trees, between them (shadowing). The closer the phone is to the base station and the fewer obstacles between them the less power the phone consumes.

The strength of the cellular signal is a major factor affecting the power used by the cellular radio. Moreover, the cellular radio is one of the most dominant power consumers on the phone.
Suppose an attacker measures in advance the power profile consumed by a phone as it moves along a set of known routes or in a predetermined area such as a city. We show that this enables the attacker to infer the target phone’s location over those routes or areas by simply analyzing the target phone’s power consumption over a period of time. This can be done with no knowledge of the base stations to which the phone is attached.

A major technical challenge is that power is consumed simultaneously by many components and applications on the phone in addition to the cellular radio. A user may launch applications, listen to music, turn the screen on and off, receive a phone call, and so on. All these activities affect the phone’s power consumption and result in a very noisy approximation of the cellular radio’s power usage. Moreover, the cellular radio’s power consumption itself depends on the phone’s activity, as well as the distance to the base-station: during a voice call or data transmission the cellular radio consumes more power than when it is idle. All of these factors contribute to the phone’s power consumption variability and add noise to the attacker’s view: the power meter only provides aggregate power usage and cannot be used to measure the power used by an individual component such as the cellular radio.

Nevertheless, using machine learning, we show that the phone’s aggregate power consumption over time completely reveals the phone’s location and movement. Intuitively, the reason why all this noise does not mislead our algorithms is that the noise is not correlated with the phone’s location. Therefore, a sufficiently long power measurement (several minutes) enables the learning algorithm to “see” through the noise. We refer to power consumption measurements as time-series and use methods for comparing time-series to obtain classification and pattern matching algorithms for power consumption profiles.

The PowerSpy project was a joint work with Gabi NakiblyAaron Schulman, Gunaa Arumugam Veerapandian and Prof. Dan Boneh from Stanford University, as part of a series of works on sensor exploitation on mobile devices.

Glass Goggles

So I was naive to purchase Google Glass, hoping that everyone around would want one soon enough. In the meantime I wanted to try to develop something for it, something somewhat useful.  I thought it would be cool if I could walk around, look at something and Google Glass would tell me what is it I’m looking at.
Since Google Goggles (the Android app) service doesn’t have an open API, I decided to use Google’s “search by image” service.

The result is a Glass application that captures a photo using the Camera, uploads it to a temporary storage such that the URL is accessible to Google’s search by image. It then parses the retrieved results and annotates the image with the leading guess provided by Google. Here are two examples, one is for a poster of Daft Punk DJ’ing, and the other is a poster of Hokusai’s “Great Wave” painting (with Mount Fuji in the background of course).

daftpunk hokusai

 

Gyrophone: Recognizing Speech from Gyroscope Signals

My advisor Dan Boneh, colleague Gabi Nakibly and I have recently published a paper “Gyrophone: Recognizing Speech from Gyroscope Signals”.
It was presented at the 23rd USENIX Security conference in San Diego, and at
BlackHat Europe 2014 in Amsterdam.

To get a quick idea of what this research is about the following video should do:

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 (< 200 Hz). 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.
This research attracted quite a bit of media attention and the first one to be published was an article in Wired.comThe Gyroscopes in Your Phone Could Let Apps Eavesdrop on Conversations. They interviewed us directly, and that article is probably the most technically accurate (Engadget and many more others followed and cited this original article).

Here’s our BlackHat Europe talk that explains this work in more detail

We’ve been also addressed with some questions by a French journalist, which I answered quite in detail in an email. So to clarify certain points regarding this work I’m pasting the Q&A here:

Q: What is the best results that you get in term of recovering sound? What are the limit of your work until now? What sort of sounds couldn’t you recover? Could you recover a complete human conversation, for example ?
A: To be precise we currently do not recover the original sound in a way that it will be understandable to a human. We rather try to tell what was the original word (in our case digits) based on the gyroscope measurements. The fact that the recording is not comprehensible to a human ear doesn’t mean a machine cannot understand it, and that’s exactly what we do.
We managed to reach a recognition accuracy of 65% for a specific speaker, for a set of 11 different words, with a single mobile device, and 77% combining measurements from two devices. While that is far from full speech recognition the important point is that we can still identify potentially sensitive information in a conversation this way.
We also outline a direction for potential reconstruction of the original sound using multiple phones, but that requires further research, and we don’t claim yet whether it is possible or not with smartphone devices. Another, not less important result is the ability to identify the gender of the speaker, or to identify a particular speaker among a group of possible users of the mobile device.

Q: Why has nobody worked on and proposed this approach before? Is it because the technical tools (algorithm) weren’t available? I mean, what is really the most performance? What was the most difficult? The algorithm? What are the advantages in comparison to traditional microphones?
A: I’m not completely sure nobody hasn’t but definitely no prior work demonstrated the capabilities to this extent. The fact itself, that gyroscopes are susceptible to acoustic noise, was known. Manufacturers were aware of it but they didn’t look at it from a security point of view, but rather as an effect that might just add noise to the gyro measurements. We think there hasn’t been enough awareness regarding the possibility of sensing speech frequencies, and the security implications of it. In particular in smartphones, access to the gyro doesn’t require any permission from the user, which makes it a good candidate for leaking information, and a such, an interesting problem to look into. That is also the advantage compare to the regular microphone.
The hardest part apart from the idea itself was to adapt speech processing algorithms to work with the gyroscope signals and obtain results despite of the low sampling frequency and noise.

Q: What are the applications for Gyrophone that you imagine for the future? Spying?
A: The application can definitely be eavesdropping on specific words in a conversation, or knowing who is near the mobile device at a certain moment.

Q: What are the next steps in your work? I mean what is your next work now to progress in this direction? Do you plan to publish soon with new results?
A: The next steps in this direction would be to study better what are the limits of this attack: What physical range is possible? Can the recognition accuracy be improved?
Is there a way to synchronize two or more mobile devices to potentially recover sound?Currently we don’t plan to publish new results for this attack but rather exploring more ways to leak sensitive information from mobile phones by unexpected means.

Q: Do you imagine that in the future such system could be used by everybody? To do what?
A: It is not that easy to make such a system work for practical attacks on a large scale, although more research effort in this direction might yield more surprising results.

Q: How could we avoid this spying risk?
A: The attack is not so hard to prevent either by limiting the sampling rate available to applications, requiring specific permissions, or filtering the high frequencies.
Our hope is that the general issue of side-channel attacks will be addressed by mobile device manufacturers in a way that will make it impossible.

The project page http://crypto.stanford.edu/gyrophone provides access to our code and dataset, as well as a link to the published paper.

Linux Audio Conference 2014

I’ve recently attended LAC’14, the 12th Linux Audio Conference, held this time at the ZKM (Zentrum fur Kunst und Media) in Karlsruhe, Germany. This conference is free and serves as a gathering opportunity for developers of Linux audio tools, experimental electronic music composers and open-source contributors.
I was presenting a contribution to the Faust musical signal processing language compiler. The main maintainers of the Faust project are currently Yann Orlarey and Stéphane Letz.
The joint work with Prof. Julius O. Smith (CCRMA at Stanford University) and Andrew Best (Blamsoft Inc.) added support for various useful features to the Faust VST architecture.
The title was 
Extending the Faust VST Architecture with Polyphony, Portamento and Pitch Bend.
I was initially introduced to Faust during a short workshop Yann gave in CCRMA in 2013.
Later on, while taking the Software for Sounds Synthesis class at CCRMA, I was trying to use Faust in combination with the MuLab DAW that can run on Windows and Mac OS X and supports VSTs as instrument plug-ins. Noticing the lack of some common features I’ve decided to turn it into my class project. The motivation was to enable using Faust to create plug-ins for as many free and commercial DAWs and production tools as possible and making the produced plug-ins functional enough to be useful for actual music production.
It was also exciting to meet open-source contributors for projects such as Ardour, QTractor and other great tools. Currently I’m continuing to work on improving Faust’s VST architecture, debugging and making it compatible with more production tools (like Ardour) out there. Next goal is solving some issues when trying to use Faust VSTs with Ableton Live.

Facilitating energy efficiency on mobile devices

I’ve recently read the Bartendr paper (386f5adade0bd7d0970b5ff555d643c6). It explores an algorithm for increased energy efficiency on mobile devices, based on prediction of good conditions for transmitting data to the cellular network.

Bartendr
The Bartendr  approach to communication scheduling is based on the fact that mobile devices consume more power when the signal is weak to compensate for the low SNR of the transmission channel. Applications should preferably communicate when the signal is strong which is indicative of a good transmission channel.
By anticipating good or bad channel conditions it is possible to determine the periods of time that are favorable for energy-saving communication. Since the signal strength is highly correlated with the user’s location relative to the cellular antennas, moving along a certain route the user experiences changes in signal strength. By learning the signal strength profile as a function of location along a certain route, it is possible to anticipate the time windows that are favorable for energy-saving communication.

While the algorithm was evaluated in simulation as well as on an actual device by incorporating the scheduling decisions into the test application, currently there is no practical framework for an actual implementation of Bartendr, or a similar scheme since it requires changes in the related software architecture. This post discusses several architectural changes that are needed in order to accommodate such schemes.

While it is possible for mobile applications to use timer mechanisms to run callbacks asynchronously at specific times, it requires the application to be aware of the right times to schedule the execution.
We can imagine how it would simplify things for the developer to simply push a synchronization request into a queue from which tasks are popped according to a power efficient schedule, maintained by the operating system. This could be a nice feature for a mobile operating system.
It would also be great to have something like a Strategy design pattern implemented for scheduling – allowing plugging-in a different schedule algorithm according to the user’s choice.

Bibliography

Dropbox Recovery Tools: When Dropbox client goes crazy…

It all started a couple of days before a paper submission deadline – when I really needed my data accessible, and my code available. I store all my academic stuff in my Dropbox folder, so it is backed up to the cloud. Lo and behold, Murphy entered the game and caused my Mac to halt, and when I forced a reboot it apparently resulted in some inconsistent state of the Dropbox client. This drove Dropbox  into deleting tens of thousands of files from my account, causing files to be deleted remotely and locally, under the tips of my typing fingers. The only thing I had is previous remote revisions of the files.
I don’t have Dropbox Pro and therefore don’t have PackRat, which anyway I’m not sure would help in this case. Besides, I didn’t actually care about indefinitely long history, but about quick and convenient recovery. I’ve decided to take a look at the Dropbox API. I found it quite easy, using the supplied Python Dropbox SDK, to write several tools to help me search and recover my deleted files.
The Dropbox Python SDK can be either downloaded and installed using setup.py or using

# pip install dropbox

In order to access your Dropbox you need to create a Dropbox application that’s linked to your account. It can be done through the Dropbox application console (https://www.dropbox.com/developers/apps) and gets you an application key and application secret which are later used by the Python scripts to obtain a token that enables accessing your Dropbox storage.
I store the application key and secret in a JSON configuration file, and written a tiny helper script to generate this JSON (make_config.sh):

echo "{
  "app_key" : "$1",
  "app_secret" : "$2"
}"

The code to obtain an access token for all further actions looks like that

import dropbox
def get_token():
  config = open(CONFIG_FILE, 'r')
  config_data = json.load(config)
  app_key = config_data['app_key']
  app_secret = config_data['app_secret']

  flow = dropbox.client.DropboxOAuth2FlowNoRedirect(app_key, app_secret)
  authorize_url = flow.start()

  # Have the user sign in and authorize this token
  authorize_url = flow.start()
  print '1. Go to: ' + authorize_url
  print '2. Click "Allow" (you might have to log in first)'
  print '3. Copy the authorization code.'
  code = raw_input("Enter the authorization code here: ").strip()

  # This will fail if the user enters an invalid authorization code
  access_token, user_id = flow.finish(code)
  return access_token

The access token is stored in a cookie file for later use.

def create_client():
  try:
    cookie_content = open(COOKIE_FILE, 'r').read()
    access_token = json.loads(cookie_content)
    client = dropbox.client.DropboxClient(access_token)
  except Exception:
    access_token = get_token()
    client = dropbox.client.DropboxClient(access_token)
    cookie_content = json.dumps(access_token)
    open(COOKIE_FILE, 'w').write(cookie_content)

Once we have initialized a client we have access to all kind of methods such as metadata, revisions,  restore, file_delete, etc. There are several utilities provided:
find_deleted – Finds deleted file under a given path (optionally by date)
ls – Lists files (optionally by date)
restore_file – Restores files. Paths are provided through standard input.
delete_files – Deletes files. Paths are provided through standard input.

Using these utilities I was able to restore all my accidentally deleted files in a matter of hours. One small technical detail I had to apply is to handle rate limiting imposed by Dropbox. Once in a while an operation would result in an exception if too many actions were attempted in a short amount of time. I had to catch this, and retry the operation.

The code is available under https://github.com/ymcrcat/DropboxRecoveryTools.

Registering a specific file-type handler on Android

(My example is in C# since I was working with Mono for Android but the same is applicable for Java applications as well via the usual manifest XML)

While many answers already exist on forums and several tutorials are available, I’ve still encountered a certain problem when I tried to register a handler for my own file type (let’s call it .xyz). I’ve added an IntentFilter attribute, specifying that I’m handling the View and Edit actions and choosing the Default category.
Since there is no existing MIME type for my extension I’ve used DataPathPattern for filtering and a wildcard for DataHost.
Overall the code looked like that

[IntentFilter(new[]{Intent.ActionView, Intent.ActionEdit},
Categories=new[]{Intent.CategoryDefault},
DataPathPattern=".*\.xyz",
DataHost="*")]
public class MyActivity : Activity { ...

The problem is that my application was now taking over all possible intents such as calling and messaging, and when I was browsing my contacts my application icon showed there as a possible candidate for handling the contact entry (i.e. making the call). What finally solved the problem was specifying the DataMimeType as “application/octet-stream”, like that

[IntentFilter(new[]{Intent.ActionView, Intent.ActionEdit},
Categories=new[]{Intent.CategoryDefault},
DataPathPattern=".*\.xyz",
DataHost="*", DataMimeType="application/octet-stream")]
public class MyActivity : Activity { ...

supost.com Chrome Extension

I’ve recently posted a Chrome extension for the benefit of the Stanford community. The SUPost Checker extension notifies the user about new items posted on supost.com. In addition it enables filtering according to user-specified keywords so in case the used is looking for specific items she can list all them in the extension settings and receive notifications about relevant posts. More info about the extension and a link to installation are on http://supost.voicebrowsing.net.