Remote Physical Device Fingerprinting

Here’s the abstract:

We introduce the area of remote physical device fingerprinting, or fingerprinting a physical device, as opposed to an operating system or class of devices, remotely, and without the fingerprinted device’s known cooperation. We accomplish this goal by exploiting small, microscopic deviations in device hardware: clock skews. Our techniques do not require any modification to the fingerprinted devices. Our techniques report consistent measurements when the measurer is thousands of miles, multiple hops, and tens of milliseconds away from the fingerprinted device, and when the fingerprinted device is connected to the Internet from different locations and via different access technologies. Further, one can apply our passive and semi-passive techniques when the fingerprinted device is behind a NAT or firewall, and also when the device’s system time is maintained via NTP or SNTP. One can use our techniques to obtain information about whether two devices on the Internet, possibly shifted in time or IP addresses, are actually the same physical device. Example applications include: computer forensics; tracking, with some probability, a physical device as it connects to the Internet from different public access points; counting the number of devices behind a NAT even when the devices use constant or random IP IDs; remotely probing a block of addresses to determine if the addresses correspond to virtual hosts, e.g., as part of a virtual honeynet; and unanonymizing anonymized network traces.

And an article. Really nice work.

Tags: , , , , ,

Posted on March 7, 2005 at 3:02 PM • 21 Comments

Comments

Filias Cupio • March 7, 2005 4:23 PM

I’ve only read the zdnet article, not the paper, but it looks like this technique determines a single number – clock skew. Describing it as a ‘fingerprint’ seems misleading – it is more like knowing the height of someone you’re looking for.

To know how useful this is as an identifier*, we’d need to know:
1) The precision of measurement of clock skew
2) The range of clock skews in the population of computers. (Technically, it is the ratio of (1) to (2) that matters)
3) The stability of the clock skew of a given computer.

Only (3) is (briefly) addressed in the ZDnet article. (And this all assumes no countermeasures are being taken, which may cease to be the case once this method becomes well known.)

  • i.e. the chances of false positive (identifying two distinct computers as being the same) or false negative (identifying two observations of the same computer as belonging to different computers.)

Zwack • March 7, 2005 4:29 PM

Well, I guess it’s time to hack the network stack to remove the TCP/IP time stamps option from all packets and replace them with slightly modified times… That should confuse his “fingerprinting”

I guess that NAT firewall is going to look like a single server again.

Z.

Bubba • March 7, 2005 5:03 PM

There doesn’t appear to be a need to disable the TCP timestamp…all you need is well placed intentional small random error.

Then again, as the old saying goes: if you shave off your fingerprints, your scars can still be used to identify you.

This is a very interesting piece of work.

Nato Welch • March 7, 2005 5:04 PM

IIUC, anonymizing networks like TOR and I2P aren’t vulnerable to this kind of analysis, since each router node would replace the previous node’s clock skew with its own.

Richard Stiennon • March 7, 2005 8:08 PM

There is at least one company that tried to commercialize a hardware fingerprint for the “something you have” part of two or more part authentication. They did not use info in the TCP/IP headers though. Safe3w used things like MAC address plus hard drive plus CPU.

Then there is TNT http://www.trustednetworktech.com/ that uses client software and gateways to authenticate based on hiding keys in the TTL and other fields.

Steve • March 7, 2005 9:10 PM

Looking at the paper, it looks like the longer you examine the timestamps on your target’s TCP/IP packets, the more precise your measurement of their clock skew is. Based on their very small data set, it looks like you can get more or less arbitrarily precise measurements of a device’s clock skew, but their laptop example had a clock skew that changed by about a part per million depending on where it was on the internet. This 1ppm change was to a clock skew of about 58 ppm, so it looks like you can be fairly sure that two identical skews are the same (better than 95%), but you certainly can’t uniquely discriminate all hosts. Also, they didn’t appear to do any controlled studies about how much one can twiddle one’s clock skew- perhaps temperature plays a large rolle in clock skew, or something. Additionally, making the measurement of clock skew appears to take a fair amount of time (a number of days) to determine. Thus, it appears as though a host could be hard to identify if it kept switching IP addresses frequently (and there was no other way for an attacker to follow a single host). I didn’t completely read and digest the paper, so some of what I say may be false.

Steve

Davi Ottenheimer • March 7, 2005 10:59 PM

Brilliant approach to rethinking an old problem. All these years of trying to reduce skew through more reliable trees, leaves, etc. and now we have a good reason to like the differentials. Although as Steve rightly points out, it takes an awful long time to gather enough data to have a reliable perception of time between two relatively different clocks.

Roy Owens • March 8, 2005 7:07 AM

If by ‘clock skew’ they mean accumulated clock drift, then I think they imagine this is a constant for any clock. In the real world, all clocks drift, and do so unpredictably. Ancient Chinese proverb: “Man with one clock know time; man with two clocks never sure.”

Davi Ottenheimer • March 8, 2005 10:00 AM

Clock skew, drift, dilation…it is all about the notion that elapsed time as recorded by two systems, even with identical clocks, will differ.

Kind of funny to think about what happens if one of the systems is traveling at a velocity v with respect to the other. The amount of skew becomes more noticeable (changes) as v becomes a larger fraction of the speed of light, right? Might be “time” to experiment with a satellite-linked laptop on a jet…

Bubba • March 8, 2005 10:05 AM

I guess a real question would be “Will this stand up in a US court of law?”

I would guess no. Using a handful of imprecise machines to measure other imprecise machines is kinda…well..I wouldn’t want to send someone to prison with that type of measurement.

Phil • March 8, 2005 10:16 AM

A few years ago in the ham radio world, there was a similar technology called “transmitter fingerprinting”. It took advantage of the fact that due to minor variation in the actual values of analog transmitter components, the signal transmitted during transmitter startup was slightly different from transmitter to transmitter (even among different units of the same brand and model) but consistent for the same transmitter, and these differences could be used to tie together different transmissions from the same transmitter.

Clive Robinson • March 9, 2005 7:07 AM

@Phil

The earliest use of transmitter @wine@ that I know off was during the second world war, where it was used by the X stations (Listening points for Bletchly etc) to identify the transmitter by it’s “tone”. In one case it clearly identified that the Germans where running a deception to make the Alies think that they where building up large numbers of troops.

Another asspec was recording an operators “fist” this was used to identify the person sending morse code by the delays and rythum of their sending.

There are two books that give details, 1: The Secret War by Prof RV Jones (about 1973)

2: Silk or Cyanide, I cant remember the author but it was late 90s.

Anonymous • March 9, 2005 3:12 PM

Steve is correct. Moreover, there is no guarantee that the clock drift characteristics of a device will remain constant (temperature, noise, EMI, etc.). Of course you can also get a good random number source and distort your clock drift to hide the base behavior. However, this is a very good example of the fact that given processing power you can extract surprising information from all kinds of things.

Clive Robinson • March 10, 2005 5:10 AM

Having finally had the chance to read the document (it sure takes a long time to print) it appears to be a very very simple issue to deal with in hardware but not unfortunatly in software.

The time offset is caused by the master clock Xtal being either high or low of the frequency it is supposed to be on this causes the accumulated time change. The reason for this is that the manufacturers of the motherboards have decided to save a few tenths of a cent by not fitting the capacitor on the Xtal so it has the incorect capacative loading and is therefor on the wrong frequency.

This acutually makes the system clock gain someting like 4 seconds (from the paper) a day or around 25 minutes a year !!! (Would you by a digital wrist watch that gained this amount of time). Oddly the Real Time Clock using a 32KHz watch Xtal only gains / losses around 2 mins a year on most motherboards I have come across.

Hardware solutions

THe simplest would be put a temprature compensated variable capacitor on the Xtal and tune it into the correct frequency, that way the accumulated clock drift is very very small and therfore cannot be easily fingerprinted.

Further to that use a variable capacatence diode instead and drive it from a high impeadence (to RF) voltage source, vary this from time to time to give a different fingerprint value.

Better still use similar technology to modern TCXO’s and use a PIC microcontroler to generate the voltage, also monitor various status lines (like reset etc) and change the voltage each time you reboot the machine, thus giving a different fingerprint each time you turn the laptop etc on.

This “attack” is a form of tempest attack, and the old addage about the information “energy and bandwidth” apply. Interestingly looking at their paper they have missed a couple of things that might provide more information about the computer. Basically the resonant frequency of an Xtal oscilator is decided by the elctrical and physical charecteristics of the circuit. These means that the frequency changes with the applied voltage, temprature, mechanical vibration. So it there is sufficient bandwidth in the time detection method it might well be possible to tell things about the environment the laptop is in and how much it is being used (heavy calculation take the temprature up and drops the powersupply voltage slightly).

Roastbeef • March 11, 2005 8:40 AM

Not a good approach… They rely upon the target clock not being reset over a long enough period to accurately measure the skew, and we can argue whether or not a “newbie” users machine is open to this. However its clear that this both circumventable (think frequent time updates to WWV) and spoofable (i.e. measure someone else’s skew and mimic)

dave • March 13, 2005 6:37 AM

All well and good while there’s no L4+ proxy sitting inline. That is, a plug gateway, an http proxy, a socks proxy, etc. Most ISPs allow (and some just transparently do it anyway) users to browse via their caches, and at this point their TCP Timestamp when browsing is replaced by the ISP proxy – that is assuming that the proxy hasn’t got timestamping disabled. Most large corporates don’t allow direct tcp connectivity across their network edge either.

Spanner intheWorks • March 14, 2005 7:35 AM

Very interesting on first read ! Please don’t take this the wrong way, but i find it hard to accept as is. Because clock speed and pulse width etc are NOT consistant at ALL and can vary randomly microsecond by microsecond. And usually minute by minute, and most certainly hour by hour !

This is due to a number of factors including, Temperature – Device Precision – Power Supply Flucuations – etc etc. All these and more are ALL non linear and therefore when you multiply All the possible variables together, any skewing is going to off by the same amounts. So as the Total Clock Cycle Effect, TCCE, is a large inconsistant variable i can’t see how it could be pinned down by a Time/Date/Stamp exercise, never mind Precisely, but even Anywhere near close !

Not only that, but the Data Bits that are clocked in our computers and exit into www. land are ALL re-clocked and cleaned up Many times on their journey, and also back again to, and into our computers.

So how Exactly is someone going to inspect a computer and find the Precise same possible effect that may have been made at one moment in time after being subjected to at the Very least ALL the above ?

Definately a nice idea though,

Regards,

Spanner intheWorks – http://www.wilderssecurity.com

Adrian Lopez • March 17, 2005 8:43 PM

This is an interesting (and somewhat frightening) technique. I wonder if it’s possible to defeat it by calculating a random number X and skewing the results by that amount (lose X ticks every so many actual ticks). This artificial skew number could be changed whenever the client wants to make it seem as if he’s using a different computer. Would timing artifacts remain that would allow detection of the real clock skew?

I wonder…

X the Unknown • October 26, 2006 1:09 PM

@Bubba : I guess a real question would be “Will this stand up in a US court of law?”

Actually, the real question is whether this is good enough to narrow down where the NSA/FBI/Etc wants to install their port-monitor. In the old days, the question would be “is it good enough to get a warrant?” – but those days are past.

Wael • May 2, 2014 9:35 PM

@ Clive Robinson,

Silk or Cyanide, I cant remember the author but it was late 90s.

I liked the title (and the description)! Just got the kindle edition. It’s called “Between Silk and Cyanide: A Code Maker’s War 1941-45 [Kindle Edition]
Leo Marks (Author)”. May be a good weekend reading… Unlike your other recommendation that made me sleep within 5 minutes 😉
@Bruce Schneier,
Book titles do make a difference. Choose wisely 😉

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.