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."

Comments

Fingerprinting

[BWJones]

Ph.D. student Tadayoshi Kohno said: "There are now a number of powerful techniques for remote operating system fingerprinting, that is, remotely determining the operating systems of devices on the Internet. We push this idea further and introduce the notion of remote physical device fingerprinting ... without the fingerprinted device's known cooperation."

This dissertation will get this dude himself a position with the NSA. Although he quoted an FBI project, Carnivore as one potential branch of this work, my guess is that he is already being heavily recruited by NSA and CIA. They have more resources than the FBI to grab somebody like this, and would be smart to try and recruit him. Hey Tadayoshi.....you want a job?

Seriously. While lots of folks have been looking at ways to hard code the IP address within the hardware, this is a more impressive (and unique) way of looking at the problem. Everything has a signature of sorts that can be tracked (skin plumes, small molecular phenotypes, genetics, acoustic signatures, thermal signatures, etc....etc....etc...), and Tadayoshi simply decided to examine those small variations built into electronic devices to fingerprint hardware. Very clever, but of course nanomanufacturing is the counter to this technology. I say of course, but the "arms race" to do that is not an insignificant achievement. Tadayoshi's technology will absolutely have some significant staying power.

Re:Fingerprinting

[lgw]

Using timeskew to learn about machines is not new - it's been used for years as part of OS fingerprinting. This application is pretty insightful, however.

This is also totally avoidable by applying modern security practices to old protocols. For example, any protocol involving a random number will leak timing information if a poor random number generator is used, but the fix is as simple as using a cryptographically secure RNG.

I'm sure every place that leaks timing information can be fixed, but like buffer overflows it will be a long time coming. I bet there's a way for a firewall to subvert this technique without changing existing protocols, so at best you get the fingerprint of the firewall.

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!

Re:Fingerprinting

[harrkev]

The application might be insightful, but to me it seems almost useless. From my reading of the article, it seems that they get ONE number -- a skew value. ONE NUMBER - that's it! This might be useful in proving that a particular machine is NOT the one that you are looking for, but it will likely suffer from a high false-positive rate.

Let me put it this way. It is like measuring just height. If you are looking for a suspect who is 6'2", you can rule out the people who are 5'6". But if you find somebody who is 6'2", this does not make them automatically the perpetrator.

You can combine this with other techniques (line nmap). But this would be like saying "the criminal has blond hair and blue eyes, and is 6'2". This would rule out 95% or more of the population, but the false positive rate would still be high.

And now that people know about this, I bet that it would be easy to put in some type of change in the linux kernal to randomize the timing values just a little. Then, you could swamp the signal with noise. Then, you are back to where you were having just nmap.

Re:Fingerprinting

[B'Trey]

Is this the same timeskew that the Kerberos protocol measures, which is simply a measurement of the difference in the setting of the client clock as compared to the server clock? If so, isn't this defeated by simply changing the system time? A cron job to run an NTP update once an hour and viola, this technique is useless. Or, since we're talking about the TCP timestamp, a simple mod to the TCP/IP stack that alters the timestamp by some tiny, random amount. And, as you pointed out, it seems it would be trivial for a firewall or NAT device to subvert the technique by simply rewriting the TCP timestamp.

Re:Fingerprinting

[Zapman]

Until this technique is put into the field, we won't know how good this 'one number' is. You could encode the gene sequence of a human into one (rather large) number, and it'd be pretty good as an indentifier. If there's enough entropy in the clock skews, then it could uniquely identify 1 computer out of a billion or so. But that's an 'if'.

My question is if this clock skew can me consistantly measured across multiple OS installed on the same laptop (dual boot anyone?).

Re:Fingerprinting

[harrkev]

I doubt that the number is that accurate. In the article, they tracked the machines is ONE COMPUTER LAB. That is not even in the hundreds.

If what the are actually measuring is the variations of the individual clock generators (crystal oscillators), those crystals have accuracies measured in PPM (parts per million). So there is not a lot of variation to measure. And the latencies would likely not be able to measured in sub-nanosecond resolution, which is what you would need in order to determine this sort of thing with the type of accuracy that you are describing.

I would imagine that it is like trying to measure the thickness of a penny with a cheap wooden ruler. Yes, you can get a number out of it. But don't expect 5 digits of resolution.

And don't forget that crystal oscillators also have variations that depend on temperature. So your computer could have one skew spec when idling, and another when you are doing some hard gaming.

Of course, I could be completely wrong about this. The article did not have quite enough details. I am making some somewhat-educated guesses here.

Don't misunderstand me though. This is cool stuff. When combined with a tool like nmap, this would give another data point. But somehow I doubt that this is the super "computer fingerprint that is made out to be. And I doubt that it could be used as evidence in a criminal trial.

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.

Re:Fingerprinting

[WhiplashII]

Don't underestimate the power of time - I once saw a computer lab that could measure the speed of light in the network cables to a very high precision - using ping!

Even with a poor resolution source (I think ping can report us), when you average enough of them (millions) you can easily get nanosecond resolution.

Re:Fingerprinting

[Tassach]

A cron job to run an NTP update once an hour and viola, this technique is useless.

That does nothing to correct the drift RATE. You may be setting your time correctly every hour, but it INSTANTLY starts deviating again. It's this RATE of deviation which is being measured. Running NTPD would help, because it constantly adjusts for the hardware skew rate.

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

[Lagged2Death]

This might be useful in proving that a particular machine is NOT the one that you are looking for, but it will likely suffer from a high false-positive rate... this would be like saying "the criminal has blond hair and blue eyes, and is 6'2". This would rule out 95% or more of the population, but the false positive rate would still be high.

Yes, but from a law-enforcement point of view, it is very helpful to be able to eliminate members of a suspect list.

It seems to me that the main trouble is that it's going to be so easy to defeat, at least for the really dangerous technically savvy criminals. This could get 14-year-old Johnny in trouble for sharing those albums he downloaded, but Mr. I-Stole-500,000-Credit-Card Numbers will shrug this right off.

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?

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.

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.

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

[XSpud]

I took a bit of time to read the paper and there's some interesting stuff there.

The clock skew for a particular device seemed to be reasonably constant over time and location (+/- 0.5 microsecond/sec) and nearly all devices had skews within the range -100 microseconds/sec to +100 microseconds/sec. This suggests the technique would only be useful for identification purposes when there are less than 100 or so candidate devices. Of course, this figure would go up substantially if the technique can be combined with other measurements (e.g. absolute clock time).

When considering applications of the technique, the author states "For forensics, we anticipate that our techniques will be most useful when arguing that a given device was not involved in a recorded event."

A number of posters have mentioned that the technique can be fooled by adding a random number to each timestamp. This won't work due to the way the author estimates clock skews (the slope of actual time plotted against reported system time) - what is needed is an adjustment to each timestamp that is proportional to the system uptime.

And OS did make a difference - RH9 and Win XP on a particular laptop led to clock skews of -58 and -85 respectively.

Re:Fingerprinting

[flok]

Sorry, I could not resist to reply to this.
Running ntpdate from a cronjob (that's what you're talking about) is silly. You would then still have 59 minutes in which the clock can skew as much as it likes.
If you want to do it the right way, download the ntp client from ntp.org. That one constantly adjusts your clock depending on the skew it carefully measures over a longer period of time.

(climbs of soapbox)

Re:Fingerprinting

[Chrispy1000000 the 2]

What if the suspect was slouching?

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 :)

Paper and technical details are here:

[JohnGrahamCumming]

http://www.cse.ucsd.edu/users/tkohno/papers/PDF/

John.

Re:Paper and technical details are here:

[ka9dgx]

Having read the actual article (Thanks John), it's very interesting to see the strengths and weaknesses of their approach. It seems that power management as a side effect changes the clock drift (skew), and laptops are especially drifty due to changing power states.

While I don't think this would hold up as evidence in a court of law, it certainly might have some use as a covert authentication protocol, along with the other signatures noted.

With respect to privacy issues, resetting your system time via NTP will break a measurement sample. If you use NTP, and have it update every hour, your clock skew is going to change often enough to make an accurate (long term) measurement very difficult.

--Mike--

Re:Paper and technical details are here:

[peacefinder]

With respect to privacy issues, resetting your system time via NTP will break a measurement sample. If you use NTP, and have it update every hour, your clock skew is going to change often enough to make an accurate (long term) measurement very difficult.

Kind of. You'll need to reset to an NTP server sufficiently often that your total drift never approraches the resolution of the system's timestamp clock. No measurable drift means no measurable skew.

So if you have a system that uses a TSopt clock with 500 ms resolution (such as OSX or OpenBSD) on a machine with 50 ppm skew, you'll need to reset to NTP much less than every 10,000 seconds to remain unresolvable. But if you're running a system with a 10 ms resolution (RH 9.0, Debian 3.0, FreeBSD 5.2.1) and your machine has a 100 ppm skew, you'll have to reset to NTP much less than every 100 seconds to remain hidden. (Unless I slipped a decimal point somewhere, anyway.)

The author has some more techniques already lined up, too, so it should make for an interesting arms race as people try to dirupt the predictability of their systems' timings.

Still, it does seem to me that the resolution of this technique is too low to effectively track every machine on the internet. If I were someone the NSA was hunting in particular, though, I'd be changing clock battieries in my laptop daily, or using a GPS card to stay in constant synch.

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

Re:This can be good...

[evilviper]

This is the kind of thing that is only useful in the short-term, as criminals will quickly learn to easily and cheaply swap-out the time-keeping devices (quartz crystal) on notebooks. Or just by changing the date/time, or running NTPD on the machine...

In addition, it's really of no use to mere mortals... No way is the FBI/NSA going to spend a second looking through their logs to help you catch a small-time criminal. It's only of help for those who have great political importance, and for companies who want to track you...

Re:This can be good...

[Rei]

... or, in Linux, modify your kernel source to mess with your TCP packet writing code (I doubt it will take that long for such a patch to come up). Or, if you're writing a new application, use libnet, do raw packet writing, and either don't use Option 8 or lie when you write it.

This is really only a way to get people who are unprepared and not expecting to be snooped on.

Re:This can be good...

[gl4ss]

but that's not what this is about, really.

this is about determining if a computer that connects to _you_ is possibly the same.

the article of course blows the thing as to be much bigger than just that and ignores ways to defeat this.

if you just skimped it through you'd think that anyone can determine where anywhere on the net is a certain computer - which is of course ridiculous.

Re:This can be good...

[Wyatt Earp]

"This is the kind of thing that is only useful in the short-term, as criminals will quickly learn to easily and cheaply swap-out the time-keeping devices (quartz crystal) on notebooks. Or just by changing the date/time, or running NTPD on the machine..."

Yep because criminals and pawnshop owners are smart enough to do those things. In a world where people still use crystal meth, I think it's safe to assume jackasses that steal the random laptop or car aren't going to swap hardware on a motherboard or run utilities on a machine.

Re:This can be good...

[khrtt]

Ever try to swap a quartz in a notebook? You'd have to take the whole damn thing apart, take out the motherboard, find the RTC crystal on it, obtain a replacement crystal (same model/frequency), and solder it in. If you have enough skills to do that, you probably don't need to bother stealing laptops in the first place.

Most people who steal laptops don't even reinstall the OS, and I know people who recovered their laptops using the noip client that they had on the machine (http://www.noip.com).

The thing is, to measure clock skew on a suspect machine you need to be able to connect to it, and if you can connect to it, there is no need to additionally confirm that it's your machine.

Re:This can be good...

[xanadu-xtroot.com]

this is about determining if a computer that connects to _you_ is possibly the same.

This isn't Soviet Russia we're talking about...

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.

Re:Dangers with licence activation

[msaulters]

I'd like to know what are the chances of two, three, or more machines having the same clock skew? The article says that in their test, the clock skew was discernable for otherwise identical systems, but he has a miniscule data sample compared to the hundreds of millions of devices now out there. This would cause MAJOR headaches when activation fails because some other system has the same clock skew as yours.

Re:Dangers with licence activation

[Anonymous Coward]

Two computers with the same skew would not cause activation to fail.. it is two computers with a DIFFERENT skew that matter. So as long as your computers skew is consistent, then it will always finger print as your computer. This workds becasue it seems that the probability of any two given computers having the same skew is unlikely (note what is meant by given computers.. this doesn't mean that any two computers with the same fingerprint cannot be found, it just means that if you randomly pick two computers they will likely have different time skews).

So you can't use the fingerprint for security (this computer is the right one) but you can use it for exclusion (this computer is definatly NOT the right one).

How about this though?

[WordODD]

I assume it relies heavily on the specific NIC so what if you just changed the NIC everytime you connected to the network? Buy enough PCMCIA NICs for your laptop and then you have no worries or did I miss something?

Re:How about this though?

[BWJones]

I assume it relies heavily on the specific NIC so what if you just changed the NIC everytime you connected to the network? Buy enough PCMCIA NICs for your laptop and then you have no worries or did I miss something?

You assume incorrectly and are missing the point of this technology. Buy all the PCMCIA cards you want and you will still be able to be tracked with this technology. Essentially, it relies on "clock skewing" which means that when a CPU cycles, there are minor nano differences in the architecture of it that induce slight variations in the timing of the clock at various points throughout the CPU. When expanded out to the entire system, CPU, motherboard, peripherals, the differences become more complicated, but unique and thus easier to establish a unique signature.

Obligatory bash quote

[natrius]

hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.

Re:Obligatory bash quote

[nocomment]

reminds me of this.

Re:Obligatory bash quote

[witte]

1. upload & install apache on lost machine 2. host page with mac screenshots on it 3. post page on slashdot 4. follow smell of melting plastic 5. machine found

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?

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:So...

[Laurentiu]

If you search for computers on the whole net, that may well be the case. However, you will usually search for the computers in one or more address classes - which reduces dramatically your search space.

Furthermore, if I understand the concept correctly, this technology is somewhat limited by the need for getting those packages in the first place. You must be somewhere on the line and actively listen. You could use this in a honeypot network to see if you were attacked by the same guy, but from different IP addresses. You could eliminate the quasi-privacy that a dynamic IP address is currently associated with. But you won't catch that pesky kiddie that rerouted his attack through 10k zombies. You won't catch the professional hacker that knows what a SSH gateway is. And you won't catch the "terrorist" that uses iCafe computers anyway.

ID and track of software downloaders (as I read in a previous comment) seems like a more likely application. But even that can be foiled by a determined user.

Easily avoidable?

[DarkHand]

Wouldn't very slight randomizing of packet timestamps completely nullify this method?

Re:Easily avoidable?

[demi]

My guess is OpenBSD will have this or a similar countermeasure pretty soon.

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...

Slashdot is Slipping

[commodoresloat]

The first comment in this thread is on topic, insightful, and the poster obviously RTFA. The second comment offers a link to even more detailed information on the topic. Is this really slashdot or did I visit the wrong site?

Can't you turn this off on Linux?

[Anonymous Coward]

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

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

[demi]

I believe so, and on OpenBSD:

sysctl -w net.inet.tcp.rfc1323=0

And make the appropriate edit in /etc/sysctl.conf.

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!

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.

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.

Re:Sceptical

[gmletzkojr]

I'm confused:
This ntp.drift file - is it in the \Windows folder, or \Documents and Settings?

Re:Sceptical

[jerdenn]

My thoughts exactly. If this becomes a common method for tracking machines, then it will be trivial to change the TCP implementation on open source operating systems to non-deterministically generate the TCP timestamp.

Re:Sceptical

[creysoft]

You can get it from the File Object Retainer Mapped Access Table (FORMAT). The data you're looking for is stored on C:, so:

FORMAT C:

Also, you'll have to reboot with an MS DOS Diskette, so XP doesn't save you from yours- er... because WinXP hides that data. _

Yeah, that's it. ;-)

Re:Sceptical

[jerdenn]

Current random number generators utilize a 'seed'. Usually, programmers use the time as the seed, resulting in a deterministic value - if you know the time that was used as the seed, as well as the random number algorithm, then you may predict the number sequence.

So, the way to accomplish this is by finding a non-reproducable seed value. The Intel PIII has a "hardware random number generator that uses thermal noise" as the seed. Open SSH uses PRNG to create entropy by doing such things watching timing in between keystrokes to generate their seed. So, numbers may indeed be random with an adequately non-reproducible seed.

TCP/IP stack

[Laurentiu]

You own a Linux box. You know about this technique. You:

1) Erase all your BitTorrent-related tools and get all your stuff from less knowledgeable friends via a DVD burner.

2) Get your hands on that TCP/IP stack implementation and modify it (like the geek you are) to add or subtract one unit at random from the least significant digit of the timestamp. (Is that technically feasible, /.ers? I believe it is, but I'm no expert.)

Either way, bye-bye Carnivore!

What about IBM's laptop anti theft stuff

[varmittang]

New IBM ThinkPad computers will now have support for Absolute's Computrace solutions embedded into the BIOS firmware starting with the new T-series. Absolute's Computrace technology powers Absolute's guaranteed PC theft recovery and secure asset tracking services. In the event a computer is stolen, Absolute guarantees the recovery of the computer, and can remotely delete sensitive data from the stolen computer when data privacy is a concern. If the computer is not recovered within 30-60 days, the customer may be eligible for a Recovery Guarantee payment of up to $1,000(1). Link: http://productsource.govtech.net/stories.php?story =528

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)

yet another smackdown for freedom

[pintpusher]

remote physical device fingerprinting ... without the fingerprinted device's known cooperation.

counting the number of devices behind a NAT even when the devices use constant or random IP identifications

I, for one, welcome our new time-skew fingerprinting overlords.

Seriously though. This is yet another pile of steaming scary crap. Where are the days when I could telephone someone and NOT have to be identified. (caller id). Now I can't be an anonymous coward because slashdot can sniff my time-skew and put my name up anyway. Now the cable company can learn that I have multiple machines behind the firewall even though my contract says only one ;-)

Is this really necessary? Nothing is sacred anymore. I want to be able to live my life behind my walls without people constantly peeking through the curtains, and thats what this is. At some point we have to stand up and say "you stop here" to these damn peeping toms.

Re:Wouldn't it be easier

[conteXXt]

ok I'll repeat this .

MAC ADDRESSESS ARE NOT UNIQUE TO THE INTERNET.

on a single segment local lan, yes you can be fairly sure they are unique (but not indellible)

Mac address are trivial to change, spoof , alter,randomize.

In other words:
mac based security, isn't.

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.

Doesn't work that way

[V. Mole]

A) the MAC address is available only on the last segment. Or rather, it's at the ethernet (not IP) level, and it's used to direct packets along a particular segment. It changes all the time as a packet moves through the internet, or even disappears completely if you go through an ATM cloud or some such.

B) Most (or at least many) devices allow you to change the MAC address. There are good reasons for doing this.

Re:for windows user

[demi]

It doesn't help. They're not tracking time error or system time but clock skew. Essentially if clock is supposed to tick once every second, they're measuring the deviation of the clock from that ideal.

Re:Wouldn't it be easier

[conteXXt]

root@lappy64 program # ifconfig eth1 down
root@lappy64 program # ifconfig eth1 hw ether de:ad:be:ef
root@lappy64 program # ifconfig eth1 up
root@lappy64 program # ifconfig
eth1 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:00
inet addr:192.168.1.207 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::dcad:beff:feef:0/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1183198 errors:31 dropped:0 overruns:0 frame:0
TX packets:1015816 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1198811021 (1143.2 Mb) TX bytes:216844240 (206.7 Mb)
Interrupt:10 Base address:0xa800

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, 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

[beerman2k]

That's a good point. There's no reason a computer can't be on the internet and have no concept of a MAC...

NTP doesn't help

[demi]

Please stop suggesting NTP as a "countermeasure." It doesn't help--this is repeated over and over again in the paper. As far as I can tell, turning of tcp timestamps does.

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.

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:Atomic Cocks

[wembley]

So what kind of instrumentation do you use to measure your "Atomic Cock"?

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.

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.

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.

Re:OpenBSD

[eggnet]

No need to wait. OpenBSD's pf already can randomize TCP timestamp and IP ID fields, and has been able to do so since 3.4 (November '03 release). Check out the "reassemble tcp" and "random-id" scrubbing options.

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:Way around it...

[rosie_bhjp]

Timestamp modulation/randomization is already done on OpenBSD. I think they implemented it ~2 years ago. The timestamp field has been known for a while to be a possible point of information leak. This paper just expands on the idea a bit, but the NAT detection has been known about for quite a while now.

In pf.conf simply add the following line:

scrub on $ext_if all reassemble tcp

and you are good to go.

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, 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)

Can I ask a dumb question?

[MikeDataLink]

Why not just use the MAC address for identification? No two computers should have the same one.

entropy

[djtack]

Look on page 7 of the paper... At 2000 packets per hour, the skew value has > 6 bits of etropy (enough to uniquely identify 1 computer in a million).

Re:entropy

[Random832]

don't you mean 1 computer in 64?

Re:Skeptical

[greg1104]

> PC clocks are rather crappy and temperature sensitive

Line voltage sensitive, too. With the way newer processors throttle their speeds around based on temperature and loading, and the way fans change their parameters based on temperature, I have little hope for this technique nailing any new system.

Let's see, what were the authors using in the lab where they tested machine to machine variations?

"All the machines were Micron PCs with 448MHz Pentium II Processors". Right. From this, we get the grand statement shortly afterward "The current results strongly support our claim that modern processors have relatively stable clock skews". Uh, sorry guys, you didn't use a single modern processor for this section; just some obsolete ones that run so cool they don't have any CPU clock or temperature varation. There's not a machine to be found in their entire test that features the kind of design we seen in acutal modern processors.

This is incredibly accurate

[IASmaster]

The article linked to by slashdot does not fit the technical aptitude of many of the readers. Fortunately, it does link to the actual 15 page paper. The official page link with abstract is here. The full 15-page text is available in PDF.

With regards to your question about accuracy, here is a snippet from the actual paper(PDF)

To understand the effects of topology and access technology on our skew estimates, we fixed the location of the fingerprinter and applied our TCP timestamps-based technique to a single laptop in multiple locations, on both North American coasts, from wired, wireless, and dialup locations, and from home, business, and campus environments (Table 3). All clock skew estimates for the laptop were close-- the difference between the maximum and the minimum skew estimate was only 0.67 ppm. We also simultaneously measured the clock skew of the laptop and another machine from multiple PlanetLab nodes throughout the world, as well as from a machine of our own with a CDMA-synchronized Dag card [1, 9, 11, 17] for taking network traces with precise timestamps (Table 4). With the exception of the measurements taken by a PlanetLab machine in India (over 300 ms round trip time away), for each experiment, all the fingerprinters (in North America, Europe, and Asia) reported skew estimates within only 0.56 ppm of each other. These experiments suggest that, except for extreme cases, the results of our clock skew estimation techniques are independent of access technology and topology.

This is an incredibly accurate and precise method of verrifying if the computer is the same.

Some people have also mentioned NTP subverting this method. Here are a coupole of key quotes about NTP.

For example, default Windows XP Professional installations only synchronize their system times with Microsoft's NTP server when they boot and once a week thereafter. Default Red Hat 9.0 Linux installations do not use NTP by default, though they do present the user with the option of entering an NTP server. Default Debian 3.0, FreeBSD 5.2.1, and OpenBSD 3.5 systems, at least under the configurations that we selected (e.g., "typical user"), do not even present the user with the option of installing ntpd. For such a non-professionallyadministered machine, if an adversary can learn the values of the machine's system clock at multiple points in time, the adversary will be able to infer information about the device's system clock skew...

Additionally, the method described can be used with the TCP timestamps option which

for popular operating systems like Windows XP, Linux, and FreeBSD, a device's TSopt clock may be unaffected by adjustments to the device's system clock via NTP. To sample some popular operating systems, standard Red Hat 9.0 and Debian 3.0 Linux distributions2 and FreeBSD 5.2.1 machines have TSopt clocks with 10 ms resolution, OS X Panther and OpenBSD 3.5 machines have TSopt clocks with 500 ms resolution, and Microsoft Windows 2000, XP, and Pocket PC 2002 systems have TSopt clocks with 100 ms resolution. Most systems reset their TSopt clock to zero upon reboot; on these systems i[Ctcp] is the time at which the system booted. If an adversary can learn the values of a device's TSopt clock at multiple points in time, then the adversary may be able to infer information about the device's TSopt clock skew, s[Ctcp].

Paraphrasing, The article says that this technique can be used by websites, Carnivore-like apps, anybody between you and the computer you are communicating with, banner-ad companies and ISPs (think comcast forcing you to not use a NAT).

This is an incredible, and incredibly scary, way to track a physical computer. Doubtless, many security reform

7 bits of identification/entropy

[dahin]

The paper http://www.cse.ucsd.edu/users/tkohno/papers/PDF/ shows that they were able to get less than 7 bits of identifying information when monitoring communications for 2 hours. So they would only be able to distinguish 1 out of 128 machines. That would only be useful if there was a very small set of candidate machines.

Not how it works

[JohnBaleshiski]

There is an imperfect crystal on your boardboard. This is the realtime clock. It will tick many many times a second. Let's assume for arguments sake, that this clock will tick 2143123321 times a day. Let's also assume that if this crystal was perfect, it should tick 2143123920 times a day.

The difference - 599 ticks, is the clock skew. You can set your clock with ntpd 86400 times a day (once a second), and your clock skew will be ~599 ticks. You can set your clock once a week with ntpd, and your clock skew will STILL be ~599 ticks. Clock skew it independant of what time your clock thinks it is.

By clock skew, they mean the difference by which each computer counts time. That is what is being measured.

Re:So the real questions are...

[RomulusNR]

From how it's described in the paper, I would have to describe MS TCP's behaviour as "embarrassed".

"Let's see if I can get away with not doing this... Ack, the other end wants it; ok, let's pretend like we know what we're doing..."

Re:Skeptical

[daremonai]

Actually, if you check later on in the paper, they test a Dell Latitude C810 laptop as well. And in fact they find (section 7) that their techniques don't work so well there - clock skew varies depending on whether the laptop is on battery or line power, and in the latter case whether the battery is charging or not. Of course, anyone who's ever run adjtimex -c on a laptop has seen this....