Tracking People from Smartphone Accelerometers

It’s been long known that individual analog devices have their own fingerprints. Decades ago, individual radio transmitters were identifiable and trackable. Now, researchers have found that accelerometers in smartphone are unique enough to be identifiable.

The researchers focused specifically on the accelerometer, a sensor that tracks three-dimensional movements of the phone ­ essential for countless applications, including pedometers, sleep monitoring, mobile gaming ­ but their findings suggest that other sensors could leave equally unique fingerprints.

“When you manufacture the hardware, the factory cannot produce the identical thing in millions,” Roy said. “So these imperfections create fingerprints.”

Of course, these fingerprints are only visible when accelerometer data signals are analyzed in detail. Most applications do not require this level of analysis, yet the data shared with all applications—your favorite game, your pedometer—bear the mark. Should someone want to perform this analysis, they could do so.

The researchers tested more than 100 devices over the course of nine months: 80 standalone accelerometer chips used in popular smartphones, 25 Android phones and two tablets.

The accelerometers in all permutations were selected from different manufacturers, to ensure that the fingerprints weren’t simply defects resulting from a particular production line.

With 96-percent accuracy, the researchers could discriminate one sensor from another.

Posted on April 30, 2014 at 1:05 PM23 Comments


bcs April 30, 2014 1:30 PM

Am I reading that correctly? Did they use 100 different models of accelerometer chips? Or at least different lot numbers?

If so, that sounds like rather weak evidence for the claim.

DB April 30, 2014 2:51 PM

@ bcd it says “100 devices” not “100 different models” but it could be further clarified I suppose…

bcs April 30, 2014 3:15 PM

@DB: “The accelerometers in all permutations were selected from different manufacturers”

Gareth April 30, 2014 5:45 PM

Does that mean a 96% true positive rate? I.e. 4% false positive?

That is not very impressive if you are looking for one device out of millions. You will get tens of thousands of false hits.

However this could still be useful to someone trying to track you, if they could combine it with other sources of information.

Anura April 30, 2014 6:35 PM


96% accuracy doesn’t imply 4% false positives, it could be false negatives and inconclusives. It can also be improved with more research, and possibly combined with other information to create a weighted metric that has higher accuracy than any individual metric.

Wael May 1, 2014 1:30 AM

When you manufacture the hardware, the factory cannot produce the identical thing in millions,

I would say:
“When you manufacture the hardware, the factory cannot produce the identical thing in couples“.
“Identical”? Is there such a thing? What I find questionable is that device fingerprints are also affected by environment conditions such as temperature, surrounding radiation levels, and the rest of the known factors that affect solid state devices’ characteristics… I would imagine they took that into consideration, or perhaps this accounts for the less than perfect accuracy they obtained. Reading the article again, it seems this is a controlled lab environment. It’s not like they fingerprinted the device, then sent it out in the open and identified it. There is a big difference between the two. One is a demonstration of something already known (devices are not identical). The other is demonstrating how to exploit this “imperfection” and identify devices in a non-controlled real world environment. I think there is a lot more to say about this…

JoeLarabell May 1, 2014 3:28 AM

Does this really matter? In order to capture the signals from the accelerometer, you’d need to install software on the phone and, once you allow for that, said software could simply write a UUID into a hidden file in the flash memory that other applications could read and you’d be able to track the phone without going through all the trouble of analyzing the accelerometer data.

This just seems like a ploy to get some research team their 15 minutes of fame rather than something with any practical application.

kashmarek May 1, 2014 7:24 AM

I am curious. Forgive me, but I treat cell phones (“smartphones”) essentially as black boxes, but seemingly with significant enablement. So, tell me, how does one (i.e. spy agencies or other snoops) acquire enough accelerometer data to perform the analysis to “identify” the device and subsequently use that data to identify the user/owner of the device? Wouldn’t it be easier to include chip identification in the data stream (such as a chip id and serial number; this scheme is used in PC CPU chips).

Does a whole butt-load of that data have to be collected, stored, and then shipped somewhere for analysis?

Is the device identifiable by some near-field communication? (like reading RFID stuff)

Does the accelerometer give of signals that are quantifiable external to the cell phone itself?

This report says “accelerometer data signals” were analyzed. For an accelerometer to be useful, the data output must be useful. It would be my observation that the devices produce signals that yield data which is useful for analysis. This report seems to indicate that the signals must be analyzed outside the chip to determine usefulness. This implies that dozens or hundreds of different analysis programs (apps if you will) could produce dozens or hundreds of DIFFERENT identities for the CHIP. In other words, if the analysis code isn’t standardized or subject to any rigid discipline for how the signals are handled, the results are only meaningful for the intent of the app, not specific identification of a CHIP.

Further, the report indicates that 80 standalone chips were analyzed but only 25 actual smartphones. Thus, the 96% success rate is heavily swayed by the analysis of standalone chips, probably not operating in a typical smartphone environments. That is, those standalone chips were likely fed a specifically programmed set of movements, which would generate a known stream of data signals that were predictable. The variances in the data signals might identify the chip, but such data signals from normal use in smartphones might not produce the same types of variances that can be analyzed.

All of this is likened to the business of keyboard emission analysis and video monitor emission analysis, or some such schemes of similar nature, much of which is no longer in vogue since its value at the cost of acquisiton, seems untenable. I tend to put this in the same vein as analysis of body odor as useful for identification purposes, though eventually, the accelerometer chips are likely to also generate a chip model and serial number in the data stream. However, since individual cell phones are ALREADY identifiable by other more certain means already in existence (and being used), why bother with wasting time on using questionable uncertain analysis of acclerometer data signals for identification purposes? Simply acquire the cell phone # and store it with the data.

paul May 1, 2014 9:10 AM

For shared or burner phones, this might be a useful thing. For everyone else, it seems that the patterns of movement might be much more identifiable.

B. D. Johnson May 1, 2014 11:09 AM

They’re a little vague about exactly what their success rate as well as exactly how they got data from the accelerator. The fact that they were using “naked” accelerometers seems to indicate that there was some kind of specialized tool in use linked directly to the accelerometer, not collecting the values provided by the operating system. The tests were also done using a single, uniform motion source, not everyday activity.

The 96% accuracy was reported as being able to “discriminate one sensor from another” not being able to identify the sensor itself which is a big difference.

Somebody May 1, 2014 12:11 PM

Can anybody explain how “Tracking People from Smartphone Accelerometers” makes any sense in this context.

I read the headline and thought they were using the accelerometer as an inertial navigation system, which I immediately dismissed since I know the sensors aren’t that good.

Maybe “Tracking Smartphones from Smartphone Accelerometers” or “Cross app tracking from Smartphone Accelerometers” but how can this be used to track people? What’s the threat here? What can this do that can’t be done using phone numbers, serial numbers and other assorted identifiers that are pretty much inevitable on any smart phone? How many precautions do I have to have taken before this “attack” shows up on the radar?

DB May 1, 2014 1:28 PM

What this research is implying, is that even if we were to remove all the obvious purposeful tracking from phones such as serial numbers and things, that the base hardware itself is still unique enough to be trackable even from anonymized data coming out of it. Obviously nobody’s doing that, because there are much easier ways to track built into the phones like serial numbers! The point is though, that if we really want to have anonymity in any of our electronics, we will at some point have to account for the signatures of the hardware like this too and hide that too.

Gopiballava May 1, 2014 6:33 PM

I worked with a MEMS gyroscope for a little while, at the level of driving the actual sensor element. To get the sensor to resonate, you needed to drive it with a 14 kHz signal. You needed to have sub-hertz accuracy for it to properly resonate, and you needed to track the frequency as the temperature changed. Every sensor had a different resonant frequency.

If you had a known rotational rate, a known temperature, high accuracy sensing (great ADC, very very stable frequency source, etc) then I would be amazed if you couldn’t identify sensors. The real question is, how far below top-end lab grade gear do you need to go and have it still work?

…and the answer is in the PDF here:
(Why didn’t they actually include that in the press release? Seriously?)

They used an Arduino for data collection. No high end test gear or frequency sources. It looks to me like you could reasonably expect to get the same quality data from a smartphone itself – depending on how much filtering the OS offered. iOS for example optionally can simply fuse the output of the accelerometer, gyro and compass and tell you the information you want. (Each of the sensors is better in different dynamic situations).

Gopiballava May 1, 2014 6:52 PM

“Obviously nobody’s doing that, because there are much easier ways to track built into the phones like serial numbers!”

Apple has removed the API for the UDID which used to be used by apps to track devices. The API call that used to give you the MAC address of the WIFi interface now returns 02:00:00:00:00:00.

I think this work is interesting because data could potentially leak out in ways you simply wouldn’t expect, depending on how easy it is to extract the fingerprint:
a) Some people post videos showing their cars on the race track, along with accelerometer data. If they capture with a phone you could figure out which phone it was

b) People play video games online. If you were playing some sort of sword fruit slicing game in multi-player mode, you’d be sending some data over the network based on the accelerometer. You might assume nobody would send raw accelerometer data, but the Mac game Marathon sent out raw keystroke data. The idea was that every copy of the game on the network would start at the same starting point, and only the keyboard input would change the state of the game. So rather than try to send some sort of fancy sync data expressing how many aliens you’d shot, they just sycned the input. (Supposedly, if you hacked the physics model files and messed with friction, you could have a network game that looked very funny – play while watching somebody else’s screen and it would look totally different…)

c) Fitness tracker apps try to be social. They will record thousands of steps per day. Perhaps some of them will share graphs of the steps – probably just to look pretty. If the graphs are high enough resolution then you might be able to get some data out of that.

I know these are somewhat unlikely examples, but I do think it’s worth being aware of things like this.

Clive Robinson May 1, 2014 10:26 PM

@ gopiballava,

You’ve mentioned the two main points of interest (fitness software and delta freq on the sensor)

What surprised me was how long it’s taken someone to mention, especialy as this blog has talked about both in the past.

For those with short memories a few years ago a Cambridge Labs researcher wrote a paper about tracking the delta freq change of the CPU XTAL that was visable via TCP time stamps that could be used to strip of anonymity of computers.

I found it rather anoying at the time because I’d mentioned it prevously and was actually at the time doing some research into using similar to reveal the use of VM software used in Honeynets and web provider service shared hardware.

The reason being that you could use what looked like a Skriptkiddy network scan using pings etc to enumerate the underlying hardware. A ping scan is so frequent and so expected that seeing it in log files would not raise any eyebrows with sysadmins. However a very knowledgable attacker would quickly see that it was a Honeytrap and this not use a valuable zero day against it.

Likewise a knowledgable attacker going after a website that was hosted on shared hardware would find the other sites hosted on the same hardware. Thus significantly improving their chances of getting sufficient access to get at the chosen website through another web site etc on the same hardware.

It’s being aware of how what seams as being quite trivial can be used against you that is very much lacking in commercial level ITsec in the West. However there are plenty of people in Eastern Europe, Russian, China, India, Israel and similar places that are all to aware of it which might account for the fact that we are missing much of the attacks that cause high value IP to be copied into such places…

B. D. Johnson May 2, 2014 2:48 AM

@Gopiballava “Apple has removed the API for the UDID which used to be used by apps to track devices. The API call that used to give you the MAC address of the WIFi interface now returns 02:00:00:00:00:00.”

For Android users there’s something similar except its granular and optional. You can allow the aforementioned fruit-slicing game to use a network connection (for fruit slicing high score) but disallow it from reading device identifying information and personal data (technically it just returns a non-identifying number and empty set of personal information, but still). At the same time you can allow a device-specific ID if its necessary.

Clive Robinson May 2, 2014 6:37 AM

@ Wael,

Whilst that is relevant it goes back way befor then,

If you look at one of my comments you can see I was very well aware of the problem and that “load” in the OS sense on the CPU had an effect.

I had at that time not just started on the problem but finding solutions to mitigate it which I had developed a long way beyond what I mentioned. I had actualy used a PIC micro to send a taylored low frequency noise signal (like a DS spread spectrum chip to a varicap diode). The tayloring enabled you to not just remove the clock skew it also enabled you to fake other computers skews but also user work/load and daylight effects as well, thus render the process of time stamp observation pointless. I had done this as a commercial contract from a large organisation (that has been mentioned on this blog one or two times).

However a year and some later the Cambridge Labs researchers published their paper,

I said quite a bit more in that blog than perhaps contractual “non disclosure” terms/clauses might have alowed for but the organisation did not appear worried then so probably not now. It did however lead to a series of arguments between me and an “old crumudgin” over at Camb labs which might explaine why for some reason my posts are nolonger accepted there… which if it is the case is a form of censorship which would fly very hard in the face of their more public stance.

Wael May 2, 2014 10:56 PM

@ Clive Robinson,

If you look at one of my comments you can see I was very well aware of the problem and that “load” in the OS sense on the CPU had an effect.

I did. Clever…

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.