Tracking a Specific Machine Anywhere On The Net

An anonymous reader writes "An article on ZDNet Australia tells of a new technique developed at CAIDA that involves using the individual machine's clock skew to fingerprint it anywhere on the net." Possible uses of the technique include "tracking, with some probability, a physical device as it connects to the Internet from different access points, counting the number of devices behind a NAT even when the devices use constant or random IP identifications, remotely probing a block of addresses to determine if the addresses correspond to virtual hosts (for example, as part of a virtual honeynet), and unanonymising anonymised network traces."

This can be good...

[TedTschopp]

I have a co-worker who just got her laptop stolen. Now if the computer could be tracked when the jerk logs it into the Internet, that would be helpful in tracking the guy down.

Ted Tschopp

Dangers with licence activation

[Harodotus]

Several Points here, if true, it could be used to devastating effect in licensing / activation programs. Many publishers view download software onto multiple machines proof of violating single machine license agreements, while at the same time allow multiple downloads of that software to ease customer service burden from "It didn't work when I first tried to download it" calls. If a somebody were to buy such a package and then download it to his desktop and then later to his laptop, this kind of fingerprinting would allow the publisher to catch him.

From TFA, it says that:

The technique works by "exploiting small, microscopic deviations in device hardware: clock skews." In practice, Kohno's paper says, his techniques "exploit the fact that most modern TCP stacks implement the TCP timestamps option from RFC 1323 whereby, for performance purposes, each party in a TCP flow includes information about its perception of time in each outgoing packet. A fingerprinter can use the information contained within the TCP headers to estimate a device's clock skew and thereby fingerprint a physical device."

This sounds to me like firewalls would have to be modified to intentionally hide this data and remove this difference in timestamp calculations (the firewall generates both and back translates when doing NAT). So its just a call for yet another firewall patch. Can the firewall vendors patch and globally implement faster than this privacy exploit be exploited? I would hope so at least.

So...

[gowen]

Here's what I don't see. Let's say:
i) most (say, 75%) of internet-connected computers have clock correct to within a couple of minutes.
ii) Few TCP timestamp clocks bother with a click time shorter than 1ms.

That means that 75% of the computers must be mapped to a space containing 4*60*1000 = 240,000 unique items.

Now, surely there are more than a quarter of a million computers on the Net, so how will this enable us to track a device uniquely?

AH!

[kc0re]

So the government has finally figured out a way to track us all no matter where we go, behind any amount of device, no matter what. AFAIK, this is already being done using different methods, (read: not clock skew)

Extremely interesting, and logical. "Microscopic" differences in hardware clock timing. One must wonder if more can be thought of. Chipset timings in nic cards... quantum tcp theory...

for windows user

[Anonymous Coward]

use a simple, free, NTP client and tell it to resync your clock every hour or so, and you are safe :)
Use either the service built-in one in w2k+, else I recommend Atomic TimeSync [analogx.com], check also their other freeware, some are pretty neat!
PS: no, I do not work for them!

Sceptical

[bsd4me]

I am a little sceptical as to how well this works. PC clocks are rather crappy and temperature sensitive. If you look at the ntp.drift file, you will see a diurnal pattern. Plus, I would suspect that if this technology became widespread, that someone would add some dither to adjtime() to throw it off.

NAT

[BradleyUffner]

Couldn't the box doing the NATting just mess with the timestamp of all the packets that pass through it? Add a very slight bit random noise to distort the timing fingerprint.

What are you using to track?

[Evil W1zard]

I am under the assumption that a packet sniffer needs to be somewhere in-line to accomplish this tracking? I mean if person X is sniffing traffic off router Y and then person X moves to another geographic location and uses router Z the person tracking this box won't get squat? And for the purpose of telling how many systems are in a network that is using NAT, well aren't there dozens of ways to do that already? This sounds to me more along the lines of really neat idea that won't have a real practical use. And using clock skews doesn't seem to sound viable either as there are millions of systems online and with different time zones and that amount of systems how many will have the same skew. (I am no expert on clock skews so maybe I am misunderstanding this)

Re:So...

[Fred_A]

Besides nowadays XP and major Linux distributions seem to enable NTP by default so the clock drift would be way lower than a couple of minutes for most machines...

So while the idea is theoretically interesting, I'm not sure it's of any practical use.

Re:This can be good...

[Reignking]

Like any of these [google.com] products...

Clocks Drift

[baadger]

I was bored once and tried to create a Javascript page that'd refresh and post the visitors system time to the server and calculate the difference between the server and client time to the millisecond (assuming all the reload times etc remain pretty constant), and use it attempt to say "hello ".

I was trying to settle an argument with a friend that I could track him on my site even if he used various proxies.

The technique only worked for a while. And then the difference tended to drift.After a few hours the visitor couldn't be recognised anymore.

I know this is a highly simplified example but wouldn't the clock drift and inaccuracies in time keeping foul up this detection eventually?

Passively obtaining the 'clock skew'/rate of drift etc across the net doesn't seem sufficiently accurate to uniquely identify a machine.

Re:Fingerprinting

[dickeya]

That's if Google doesn't get him first. From the sounds of their recruiting policy they may be right up there with some of the government agencies, maybe even beyond.

I can see it now....
gLocate (beta) - Find Your Computer... Anywhere!

Changing Clock

[iammrjvo]

If it relies on the clock changing slowly over time, then why wouldn't it be possible to randomly change your clock time by a few milliseconds forward or back every few minutes?

Only distinguishes between 1 machine in 30 or so.

[Animats]

Look at figure 3 in the paper, [caida.org] showing clock skew for 69 desktop machines. Each line shows the clock skew measured over a 4-day period. You could distinguish about 20 of those machines. The rest don't have unique enough clock skews. Of course, those are all similar machines; they're all the same model of Micron desktops.

Note how linear those skew lines are. That data looks so good that it needs independent verification. Others have observed more variation in clock skew than that. Computer clocks aren't normally observed to have error that consistent. There's variation with temperature. One wonders if they ran this test during a period when the target machines (a computer lab) were not in use.

Re:Wouldn't it be easier

[Anonymous Coward]

As an aside to this, a few months back we ran into an issue with 2 printers that had the same mac address being on the same network.

Re:Can't you turn this off on Linux?

[spoonyfork]

Purposeful noncompliance is easy to detect.

Another way to obfuscate one's self from this fingerprint technique while maintaining compliance might be to modulate your CPU clock/bus speed on a period (day/hour/minute). Under/overclock yourself to hundreds of new identities!

read the paper

[willCode4Beer.com]

You might want to actually read the paper.
He was able to identify machines even though they were using NTP. Changing the date/time won't help for the same reasons.

I'd be interested in seeing someone pointout the "quartz crystal" in a notebook. You could modify the skew by swapping some chips. The difficulty of this is not great, simply de-solder the old and solder in the new (of course, the avg slashdotter think soldering is some kind of elite skill). The cost on the other hand is another issue.

If someone were really serious, they would as other posters have mentioned, modify their kernel to use a cryptographic randomization of their skew. However, this is only useful if many people were to do it. Otherwise, you are identified as the guy with the random skew.

As for real use. If the FBI were using this to identify the computers used by the guys who craked them. They could then use their "deployed" servers to look for others with the same fingerprint. They would then have a list of suspects to work with.

Re:Fingerprinting

[akad0nric0]

This is definitely beatable, but the individual being monitored would have to know he/she is being monitored. For catching less computer-savvy criminals, it might help.

However, I share one concern with you: just because my clock skew is 2.138ms doesn't preclude someone else from having the same skew. Not having had time to read the whole paper, I would like to see data on the probability that two computers may have the same clock skew. If it's 1 in 1000, that doesn't get you far considering the number of unique hosts sending packets across the ether. Also, remember this is only limited to IP protocols that can provide time data.

Atomic Cocks

[nrlightfoot]

All you need to do to stop this is run your computer on an atomic clock. Instead of measuring your time shift, it will end up measuring that of the computer analysing the data, because your clock will be more accurate. Also, once many computers have atomic clocks, the time shift differences would be too miniscule to detect, and you'd never be able to pick out which computer with an atomic clock you were tracking.

Re:Can't you turn this off on Linux?

[flu1d]

Can't you turn this off on Linux with
echo 0 > /proc/sys/net/ipv4/tcp_timestamps Can't you turn this off on Linux with
echo 0 > /proc/sys/net/ipv4/tcp_timestamps

This is very true, however if you read the paper linked in the article.

TCP Timestamps option from RFC 1323 [13] whereby, for performance purposes, each party in a TCP flow includes information about its perception of time in each outgoing packet. A fingerprinter can use the information contained within the TCP headers to estimate a device's clock skew and thereby fingerprint a physical device. We stress that one can use our TCP timestamps-based method even when the fingerprintee's system is maintained via NTP [19]. While most modern operating systems enable the TCP timestamps option by default, Windows 2000 and XP machines do not. Therefore, we developed a trick, which involves an intentional violation of RFC 1323 on the part of a semi-passive or active adversary, to convince Microsoft Windows 2000 and XP machines to use the TCP timestamps option in Windows-iniated flows.

I wonder if the same or similar exploit can be done under OSes.

Open BIOS needed

[behindthewall]

I guess we really need those Open BIOS projects so that we can introduce jitter into our clock values at an appropriately low level.

Course, I guess portions of the OS might not like that.

Re:Fingerprinting

[Fjornir]

How about rigging my TCP stack to add/subtract a random number to the timestamp in my headers?

Re:Fingerprinting

[pla]

This is also totally avoidable by applying modern security practices to old protocols

Even easier than that - Just run an NTP server on your LAN.

RFC1323 specifies a resolution down to 1ms. Below that, the proposed fingerprinting method can't tell anything. Now, I keep one internal machine as a stratum-3 timeserver, and the rest get a feed off that directly over the local ethernet. "ntpq" -p tells me that I have (as of 22 seconds ago) a jitter of 2 to 7ms compared with the outside world. On the inside... Oooh, 0.082ms. Guess what snooping technique will reveal absolutely nothing about my LAN (or any LAN with all machines sync'ed to a common internal source)?


In general, this technique will fail absolutely miserably. The author acknowledges the non-uniqueness of time offsets, but makes the mistake of assuming a more-or-less uniform distribution within a small range of true. In reality, the distribution will fit very tightly inside the 25ms range (oddly enough, thanks to Microsoft including their hack-of-an-NTP-client in Windows XP, and having it on by default), with only one or two percent of machines straying beyond 100ms drift. If this technique can only see down to 1ms, it effectively ends up lumping somewhere around 100 million machines into 200 buckets. Not exactly what I'd call a positive ID, when even a fully-populated class-C would almost certainly result in offset collisions...

Re:Fingerprinting

[hurfy]

Is he sure he's not fingerprinting the CMOS battery or something ;p

I know changing mine changed the rate of error on the clock.

Re:Fingerprinting

[good-n-nappy]

a simple mod to the TCP/IP stack that alters the timestamp by some tiny, random amount

Aren't our current random numbers generated from the clock? If so, then adding random numbers to the timestamp won't change the essential nature of the problem will it?

this could help free services

[harlows_monkeys]

We had a free online chat server at work, and one of the problems was dealing with jerks. If we banned someone by name, they could just come back with a different name, and with dynamic IP addresses so common, also a different IP address.

If we could have used something like this to ban by computer, that would have been great.

Re:Fingerprinting

[larytet]

If you have direct Ethernet connection clock of the peer can be measured very well.

the problem started when between peer and you 2 NATs, 8 routers and 2 or 3 Ethernet switches.

The only value you can count on is timestamp of the packets in the QoS protocols, RTP, TCP, etc. but this is logical stuff and can be fighted very easy using human driven random generator, prompting you from time to time to "move your mouse inside this window" or some kinetic driven things - small USB plug collecting all movements of yours (i think the last is patented).

i agree with your doubts regarding reliability of this technology.

Simple question: Why?

[Catbeller]

Why does the government need to find individual computers?

Not so simple:

What is the danger to the world that an individual PC is unidentified?

Compared to that danger, is the loss of anonymous free speech worth it?

If the answer is yes, then do we ourselves get to identify the PC's of CEO's, congressmen, celebrities, and other Upper Class members? Or is anonymity reserved for those who are rich enough, famous enough, powerful enough, or connected enough to hide?

And if they get to hide, but not us, isn't the very security we buy with our freedom to be anonymous then a sham? A method of control, the way Scott Ritter the ex-Marine weapons was slimed with kiddie-porn allegations from law enforcement that were just happening to be monitoring his habits just as he was being vindicated in his proclamations that the war's justifications were fake? BTW: the charges were dropped after his cred was ruined. Nice job burning the witch, Rove. Power to monitor coupled with the power to accuse and charge is the power to silence anyone, anytime for any reason and suffer NO CONSEQUENCES. Who was charged with sliming Ritter at such a politically convenient time for the Bushites? No one. And in the future, when they come for you, no one will save you or punish your accusers. Who themselves are anonymous and untouchable.

Are YOU safe from ruin is someone monitors you 24 hours a day?

If they can justify monitoring your internet usage, or track anyone they like, the legal precedent is set to monitor anyone, anytime, for any reason or non-reason, such as political/economic personal assassination. Not just your PC. What would stop them from establishing cameras on poles in front of your house to monitor your comings and goings? Microphones? They can already "sneak and peak" with a judges rubberstamp and no subpoena. They are establishing precedent to track your car with devices planted without warrant.

The current administration is currently using security laws to crush lawsuits about the detention and torture of people taken secretly after 9/11. Tom Delay used Homeland Security, illegally, to track down the Texas Democrats last year to bring them home to force a vote to disenfranchise Texas democrats - no penalties for him, and a precedent and example was set. The security apparatus established during the hysteria is being used to crush political oppostion to the President and his party; they have shown that they are abusing their power, and care nothing that anyone knows.

The internet is the last, only hope for anonymous gatherings and free speech left in the world, and they, the amalgamate they are desperately shutting down the last means of mankind to speak to power without getting arrested or ruined for claiming their birthright.

I've not the skills to fix this technically. But we need a new communications system, asap, that is not under U.S. control or capable of being traced or monitored. I've got zilch. Is there a way of making a new pipe that CAN'T be subverted or controlled by the power mad? This is a serious question, and we may need an answer really soon.

Firewalls?

[whoever57]

If I read this article correctly, it requires the target to respond to TCP packets. Now, a stateful firewall is likely to prevent such repsonses ever being sent if they are unsolicited, so unless such a system were installed in every ISP or at Akamai's servers, or similar(and used connections initiated by the clients) it is not going to work.

Re:Fingerprinting

[lgw]

1) Yup, and I was agreeing with him. :)

2) Right, and older techniques to do different sorts of fingerprinting measure timestamp skew by looking at random number output instead. My point was: for any exploit there is a fix, if you care enough.

3) You mean it *is not* blocked by firewalls today. *Cannot* be blocked is nonsense. A firewall (or even a clever NAT box) can just alter the RFC 1323 TCP timestamps in the passing packets to disguise the source. It's easier than many of the tricks stateful firewalls use today.

Re:Fingerprinting

[lgw]

That's a good point! So you could either:

• Mess with the timestamps in the packets at the border to your network (similar to some other modern firewall techniques), disguising what's in your network without having to change the machines, or
  
  
• Simply sync all your machines, making them indistinguishable, without having to change the firewall (plus having an NTP server is useful in other ways too)

Nevertheless, Kohno's technique is still pretty good because it will work today on many machines, and we all know how long it takes exploits to get fixed in the wider community.

I see some interesting uses, and limitations

[lazlo]

OK, there are some interesting things here... First, there are limitations. Off the top of my head, those limitations are:

• The fingerprinted machine must be communicating using TCP (or another protocol with timestamps, but there aren't many I can think of other than TCP)
• It must implement RFC 1323 TCP timestamps. For instance, a quick `echo 0 > /proc/sys/net/ipv4/tcp_timestamps` should keep you from being fingerprinted using this technique.
• It must implement timestamps as specified. Filling that option with random numbers, or with timestamps skewed by random amounts, or with timestamps skewed by N number of predetermined time functions (i.e., an offset and a drift, making it appear that you are N different machines) would make it more difficult to do this fingerprinting.

That said, there are some usefull things you could do with this. One example I can think of would be to detect some obfuscated scanning techniques. As an example, nmap impliments idle scanning [insecure.org], which is usually reasonably obvious because of the characteristic SYN->SYN/ACK->RST sequence, especially if the SYN and RST have different TTL's. Adding timestamp checks would make it more obvious (although, just as difficult to track down the original scanner).

Also, if someone used a decoy scan in nmap, it might be reasonably easy to tell which source addresses were really the same machine. You would probably also get enough information to construct a fairly accurate timestamp/skew profile of that machine. If you ever saw those IP addresses again, then you'd be able to check whether it was the real machine.

But, these are just my own ramblings. At the very least it seems to be interesting work (although the article linked is pretty crummy)

Re:Fingerprinting

[djtack]

RFC1323 specifies a resolution down to 1ms. Below that, the proposed fingerprinting method can't tell anything.

It may be possible to get much higher resolution measurements by averaging lots of samples. It's possible to measure the speed of light using 'ping' this way.

Re:Fingerprinting

[The Angry Mick]

Damn, just used my last mod point.

This was exactly what I was wondering. Wouldn't a simple battery swap every now and then mangle the reliability of the drift data? What about the effects of power line conditions, electromagnetic interference, etc.?

If anyone can answer, I'm genuinely curious.

Re:Fingerprinting

[cheese_wallet]

He's measuring the rate of drift, not how far your clock has drifted.

You can sync all you want, but unless you are syncing every few hundred nanoseconds, the rate of drift will be apparent and measurable.

Re:Fingerprinting

[Anonymous Coward]

Most computers these days use clock oscillator chips which slew the high-frequency clock back and forth a few tenths of a percent; this helps to reduce the EMI signature of various components by spreading out the spectrum around the clock center frequency. The chips that do this can often be quite temperature-sensitive, and even with a very stable crystal clock oscillator input they can produce a slew signature over time that is quite distinctive. For example, on one system I am familiar with you could roughly tell the internal temperature in the system case by graphing data from the clock slew messages put out by the debug mode of the NTP daemon :-). (No kidding!).

The TCP timestamps would carry exactly the same information. If you know what clock spreading chip a motherboard uses, and what the fan control algorithms for the system BIOS are, you could probably even figure out what type of motherboard is being used.

Re:Fingerprinting

[apankrat]

a simple mod to the TCP/IP stack that alters the timestamp by some tiny, random amount

No, this won't help as it changes the dispersion of the skew samples, but the mean value (that's what they measure) stays the same.

What you need to do is to make your machine clock to appear run slower or faster to the external observer. You can do that by applying constant skew offset to your true clock gradually.

For example, say clock() returns true machine clock, then

uint my_clock() { return clock + clock()/1000; }

will make it appear to be running .1% faster. Then if at the moment c0 you decided to slow it down, my_clock should look like -

uint my_clock() { return clock() - (clock() - c0)/1000 + c0/1000; }

and it will make the clock slow down to 99.9% of the true frequency.

PS I guess it would still be possible to identify machines that skew their clock skew, but analyzing how they skew the skew, but I generously donate this idea to a post-grad community :)

Re:Can't you turn this off on Linux?

[Anonymous Coward]

They didn't make it work without timestamps, they tricked Windows into sending timestamps even though it doesn't do so by default. *That* is what would have to work on Linux. Even if it did by default, we could patch it so that it did not. Good luck doing that with Windows.