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

[Pr0xY]

he's better off in the private sector, they pay much better :-P

proxy

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

[Nightlight3]

Although one can disable or fake TCP timestamps (with a kernel level code), the timestamping and fingerprinting implemented via the scripts or Java applets would be much harder to block. An applet using various system facilities (e.g. screen) would produce time-profile fingerprint sensitive not just to hardware speed but to video card, video mode, Java and browser VM. Of course, the police, FBI, courts... can get your ID by just asking your ISP.

Re:Fingerprinting

[l1gunman]

Or...

Write a simple device driver extension to diddle with the hardware clock. Doing so at random intervals, with random-like changes (never straying too far from "real-time"), should defeat this fingerprinting completely without rendering one's local clock time knowledge useless.

Kind of like swamping a radar detector with a noise signal...

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

[pjt33]

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

Timeskew on a viola? Hope you don't play in an orchestra...

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

[WhiplashII]

BTW, the math works out this way: Your signal will simply add, so the signal strength of n samples is n times a single sample. The noise strength will add RMS because it is uncorrelated, so the noise in n samples will be sqrt(n) times the noise in one sample.

Re:Fingerprinting

[Country_hacker]

Sounds like a solution for this guy. :-)

Re:Fingerprinting

[Fjornir]

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

Re:Fingerprinting

[badmammajamma]

If you had read any of the information on this, you would know that:

1) He stated that OS fingerprinting is not new. Doing hardware fingerprinting is.

2) His technique has nothing to do with RNG or cryptography.

3) One of the key benefits is that his solution CANNOT be blocked by a firewall, nor does any NAT block his detection system.

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

[torpor]

dude, NSA doesn't need to worry about any of this shit, they're in the silicon, where they belong, in the first place.

Re:Fingerprinting

[Monty_Lovering]

re. "he's better off in the private sector, they pay much better :-P"

This week two Cold War era spies, a Russian coupled who'd worked for the CIA in Russia, been promised support for life, and then been given new lives here, were told in court the government didn't have to pay them any more.

Re:Fingerprinting

[lgw]

I'm sure there are also applications for spyware we'll be hearing about next year, unfortunately.

Re:Fingerprinting

[mr_z_beeblebrox]

So, someone makes a tcp/ip patch that applies a random shift to the timestamp which could be created for each session. No two sessions would have the same time stamp - but all packets in a single session would. Then you have to analyze multiple sessions to try to find your random number seed. This would vary for stronger random number generators.

Re:Fingerprinting

[Hasai]

Everything has a signature of sorts that can be tracked .... and Tadayoshi simply decided to examine those small variations built into electronic devices to fingerprint hardware.

Hmmm; maybe so, but wouldn't the information be lost the instant the device's original datastream hit the first caching device or overloaded router? :\

Re:Fingerprinting

[pVoid]

And I doubt that it could be used as evidence in a criminal trial.

With the Patriot Act and the DMCA as precedents for dubious laws, I wouldn't be surprised if it were.

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

[bbuR_bbuB]

3) One of the key benefits is that his solution CANNOT be blocked by a firewall, nor does any NAT block his detection system.

What about a firewall that dissassembles incoming packets and rewrites them (not just readdressing/forwarding them...)?

Re:Fingerprinting

[raddan]

Yes, but how is the rate calculated? If the tracked machine is only sending out timestamps with the packet, then the person trying to find a fingerprint has to calculate the rate himself. Synching your clock via NTP might not change the calculated skew rate enough to throw off the fingerprinter, but you could probably modify the TCP/IP stack to introduce enough variability in there to throw them off.

Of course, you wouldn't want your timestamps to vary too much, because then you'd stick out. And since the article says that the timestamp feature is optional you could just disable that portion of your TCP/IP stack, assuming that there are enough devices out there that do the same thing. Otherwise you'd stick out again. Oh, and forget about it if you're not using modifiable network code.

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

[arminw]

...Of course, the police, FBI, courts... can get your ID by just asking your ISP...

That assumes a crook doesn't use one of the millions of unsecured public and private access points with a laptop. Even with this new technique, the law enforcers would only know that a given laptop was used from a given place at a certain time. If this identification could be made very fast in real time, they might be able to nab the laptop operator before he/she goes elsewhere.

Re:Fingerprinting

[merlin_jim]

The key is to pick any time for the stamp somewhere in the packet window; it takes an amount of time to send the bits of a packet out, and this time can be estimated reliabily from the packet size and uplink bandwidth.

Pick any time within that window for your timestamp and you've fundamentally defeated their fingerprinting technique.

Either that or just clip the timestamp to the largest window possible to still give each packet a unique and serial timestamp value.

Re:Fingerprinting

[Holi]

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.


I didn't do it, I swear.

Re:Fingerprinting

[gurps_npc]

The fact that it is one number is MEANINGLESS. What matters is their accuracy.{/b>

To use your analogy:

Measuring height as 6'2" rules out 95% of the population.

Measuring height as 6'2.34" rules out 99.99% of the population.

Measuring height as 6'2.34034529123112319038" rules out all but 1 person on the planet.

So what matters is how accurate their current timeskew detection is. If it is far enough out there, they can narrow it down to your specific computer.

Re:Fingerprinting

[AaronW]

If you're setting the time every hour, it would probably be next to impossible to measure the drift since it will be so small and get lost in the normal packet jitter.

Also, at least some operating systems have the ability to detect drift from running NTP and can correct accordingly.

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

[A beautiful mind]

the Grsec patchset (and i believe others) already randomize TCP sequences, pids, i believe it wouldn't be too hard to randomize this aswell.

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

[zangdesign]

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.

But the chances of someone having the exact same clock skew behind a NAT box are very, very small. It doesn't sound like a perfect system, but it is probably enough to narrow down to one or two machines of a couple thousand behind the NAT.

Re:Fingerprinting

[RedWizzard]

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

Linux (and other kernels) adjust for the drift continuously in software, don't they?

Re:Fingerprinting

[wembley]

The author acknowledges the non-uniqueness of time offsets...

Well, except for 3ms clock-drift, which I just patented.

So y'all have to pay me to use it. And I keep detailed records, so when the fuzz comes I'm taking you down with me.

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

[jericho4.0]

If I'm looking for someone who measures 6.89723495 feet tall, I have a better chance of finding them.

Re:Fingerprinting

[jovlinger]

I dunno.

Seems easier to just arrest the first person you come accross who's just under 7 feet tall, call it a day, get some good press for catching the bad-guy, and then go home and bed your wife.

That's what we do with terrorists, isn't it?

Re:Fingerprinting

[Chrispy1000000 the 2]

What if the suspect was slouching?

Re:Fingerprinting

[merreborn]

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

The trick is not to try to measure a single penny at a time, but to take hundreds, or thousand of pennys, stack them, measure their combined length with your cheap wooden ruler, and average them.

Of course if you use even more complex statistical methods, you can create even more accurate estimates. And of course, this doesn't just apply to pennies ;)

Re:Fingerprinting

[KinkifyTheNation]

This is actually a good point. What if the clock is tampered?

Re:Fingerprinting

[Audacious]

But what happens if someone (like myself) uses a single machine with various OSs on it? The Linux part is exactly on time, the Windows98se part is months off due to a test I am doing, the WindowsXP part rarely comes up but has an entirely different date/time on it as do the other partitions. Each OS, basically, has a different time associated with it. Would this, then, cause the verification to fail?

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

[Fjornir]

The courts have always been very conservative with regards to allowing new types of evidence -- observe fingerprints, blood testing, genetic testing, and so on. I'd be very surprised if this was admissable as evidence any time soon.

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

[Fjornir]

Aren't our current random numbers generated from the clock?

No. Not any more. And even back in the day, the PRNG would seed itself once from the clock, not read it again and again. These days you can expect a the PRNG to seed itself based on a sample from the clock, the current PID, size or checksum of a file in /var/log, recent movements of the mouse, and the amount of currently allocated memory. The idea being that your attacker will be unable to get all or enough of these datapoints to guess what's next in sequence. Additionally, when you're using a modern source of randomness, the amount of data it keeps internally is larger than what it returns to you. IE -- even with a simple multiply/modulus random number generator you can increase your security by generating random numbers with 128 bits of internal state -- but only returning the low order 32 bits.

Re:Fingerprinting

[B'Trey]

Well, that was my question. The only place I've seen clockskew used is in the Kerberos protocol, and there it measures the amount of time that the client clock differs from the server clock. If that's not what they're talking about, then what precisely are they measuring? The amount of drift - that is, how fast the clock gains or loses time?

Re:Fingerprinting

[quarkscat]

While I did not RTFT (thesis - 100K PDF), I remain
skeptical about using ONLY clock skew to uniquely
identify any computer on the internets. I would
like to see some hard empirical data from the wild
to back up this claim.

First, not every computer on the internet uses
NTP or SNTP to obtain its timekeeping. This
is generally more useful with servers, or with
workstations/laptops in a rigid (eg. corporate)
environment. Use of local timekeeping, or use
of an atomic clock (RF) signal should shoot this
procedure down.

Second, any computer process that requires
distinct timeslices can be altered, particularly
with the incorporation of modern power saving
technologies that slow the processor clock down.
This technique isn't BIOS independent, but is
OS independent. Merely altering a program or
process "niceness" in modern unices would alter
the fingerprint. Open source PRNG and entropy
gathering can be readily employed to alter any
number of process parameters, should that be
desirable. Even the incorporation of a local
(machine local) proxy server should shroud the
machine identity.

Third, altering maximum packet size, switching
network adaptors, switching or modifying drivers,
or even incorporating different encryption
algorythms, could cause enough variance in
network traffic analysis to throw off this
method of analysis.

That being said, I will read the full text of
this thesis paper off-line, to broaden my
vision. But I will remain skeptical.

Re:Fingerprinting

[Spetiam]

And OS did make a difference

I wonder how much of a difference there would be from kernel to kernel.

Re:Fingerprinting

[atempest]

I have been following the discussion but I have not seen anyone try
to summarize the meat of the paper. I will try to do that here.
Remember, this is just the gist of the paper; I have simplified
many things.

First, a definition of "clock skew": A clock with skew is gaining
or losing time. For example, a wall clock with a 2-minute skew that
correctly shows 12:00 at noon, will show 1:02 when it is one o'clock,
then 2:04 when it is two o'clock, next 3:06 at three, and so on.
Similarly, a clock with a -2 minute skew loses 2 minutes every hour.

This is different from a clock running fast or slow. A clock running
2 minutes fast would show 12:02 at noon, 1:02 at one o'clock, 2:02,
3:02, etc.

The authors' experiments demonstrate that the various clocks found
on a computer have tiny skews. The skews range from roughly -50 to 50
microseconds every second, and they stay constant for a particular
computer. The authors say that there is enough statistical variation
among skews to tell apart one computer from another if you can somehow
watch a targeted computer's system clock.

How do you watch the clock on a remote computer? It turns out that
most implementations of TCP/IP put a 32-bit timestamp into each TCP
packet. The authors' trick is to monitor thousands of packets from a
targeted computer over the course of minutes or hours; then, using
some linear algebra, they determine the targeted system's skew.

For example, a laptop accessing the Internet from New York may have
its skew measured as 45 microseconds per second. Later, the same laptop
connecting to the 'net from Berlin would again show a skew of 45
microseconds per second.

The authors claim that their method will allow you to learn 6 bits
of information about a device. Well, 2^6 is only 64 different devices.
If there are 200 million computers on the Internet, their method
would divide the world into 64 groups of 3 million computers each.
Your computer would look identical to 3 million other computers!

As other posters have already pointed out, this technique would
be useful to show negative but not positive results. If a laptop in
Berlin gives a skew value of 26 microseconds, you can conclude that
it is a different laptop than the one in New York. But if an arbitrary
laptop in Berlin shows a 45 microsecond skew, you can only say that
there are 3 million other computers like it. You cannot conclude that
it is the same laptop that was once in New York.

Re:Fingerprinting

[ca1v1n]

Be careful that you're not creating a normal distribution around the real value. That's fingerprintable too.

Re:Fingerprinting

[Fjornir]

Would a cauchy distribution be fingerprintable?

Paper and technical details are here:

[JohnGrahamCumming]

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

John.

Re:Paper and technical details are here:

[trick-knee]

... and here:

http://www.caida.org/outreach/papers/2005/fingerpr inting/KohnoBroidoClaffy05-devicefingerprinting.pd f

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:

[TeleoMan]

Good job cumming your brains out. Err...I mean karma whoring. Ummm...I meant to say thanks for the redundant link. Damn, just can't say anything right today!

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.

Re:Paper and technical details are here:

[sir99]

I believe one of the points in the paper is that the operating systems surveyed have a seperate TSopt clock than the system clock. For example, it sounded like Linux's TSopt clock is based on jiffies, which are incremented by the hardware timer (100 Hz in linux 2.4, 1000 in 2.6). Therefore it makes no difference whether or when you run NTP, TSopt measurements will reflect the hardware timer's skew regardless.

Re:Paper and technical details are here:

[tricorn]

Right, when using the TCP option, it doesn't use the corrected time, but when using the ICMP timestamp request, it does. So NTP helps with one of the methods (or just blocking that request would take care of it as well). One mistake several people are making (not you) is that NTP adjusts to the skew of the clock - once it has been running for long enough to get an accurate estimate of how far off your clock is, it doesn't need to "synch up" all the time, as the corrected clock will be very close to accurate all by itself, with only minor drifting.

Other than simply blocking the TS option in TCP packets (so both sides think that the other side doesn't support it, even if requested), or using NTP (and making the timestamp use the corrected clock), another technique would be to have a per-socket skew - use a biased distribution (so the real value doesn't come out if you average enough different sessions) and offset the reported timestamp so you have a slightly fast or slow running clock. Keep the same distribution bias until reboot, then choose another one (on the assumption that the underlying clock will be reset, new skew corrections figured out, etc). The adjusted timestamp value should NOT be affected by the system clock being changed or corrected - you want all of the sessions to appear to be independent. Use the raw hardware clock, adjusted by a fixed (per-socket) skew - with new skews/offsets being biased off of an NTP-mediated base skew/offset (so you're generating an offset from a hardware clock with progressively less skew). This also would help with the attack method detecting virtual hosts.

Where this would appear to be more of a problem is taking the technique further. Measuring the granularity of timestamp jumps, response times to requests, down to the nanosecond range, would ignore any attempt to skew the results. You'd need to have the underlying clocks (real-time and processor) adjustable, and use a strong-random drift to it - and even then, with enough samples you could still measure the granularity of the drift. If you use a non-digital method, you'll end up with a fingerprint of the analog portion. The only defense is to decrease the granularity you can control things so low that it becomes very difficult to measure accurately (requires an unrealistic number of samples). Adding extra intentional jitter at every level you can helps, though.

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

[stinerman]

... and as all things that can be good, it will only be used for evil.

Re:This can be good...

[Placido]

>> Or just by changing the date/time, or running NTPD on the machine...
Would that help? I'm not 100% sure what clock skew is but I would have thought that it depended on the difference between two timestamps rather than the actual date/time.

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

[cyfer2000]

And the local police think "amount is too small.", then closed the case.

Re:This can be good...

[3arwax]

I had a friend who had a computer stolen. Everytime it connected it would log into MSN IM and through the help of some friends at Microsoft were able to recover the computer and arrest the bad guy.

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

[maotx]

Our company had a few of it's laptops stolen recently and I took the liberty of investigatin in some of these Laptop Tracker tools.
What they do is randomly check for Internet connection and sends out a packet to help track it down. If it is not connected it will try to dial a predetermined number to help locate it. The company who keeps track of all this information will then work with the authorities to track it down. It is not really dependant on the OS and can survive reformats.
The only problem is that all is lost if the theifs wipe out the partitions (which happens if you do a full install of say..Windows 2000 or XP.)

Since then I've been looking at creating my own that is independant of the OS and does not reside on any partition.

Using LinuxBIOS as a replacement for the original BIOS this minature Linux has the potential to do whatever I need.
Set it up so it freezes on the lack of a dongle plugged in or have the ability to initialize the ethernet device and try to reach the outside world.

I doubt the the project managers of LinuxBIOS had any of this in mind and it needs to mature a little bit more before this could really work but once abled, but this project could really help out laptop owners.

Re:This can be good...

[titusjan]

I still have this idea of writing a shell script that mails me every hour the output of ifconfig and a traceroute to a box at my company.

Something like:

ifconfig | mail -s ifconfig me@mycompany.com
traceroute www.mycompany.com | mail -s traceroute me@mycompany.com

And then put it in the crontab of my powerbook under an unsuspicious name.

Allthough this is not nearly as sophisticated as your project, it's better than nothing. I think there are a lot of morons that would steal a laptop and connect it to the internet without reinstalling the OS.

I'm not sure if mail is the best way to do this. You'd have to have an smtp server that accepts mail from every location, and a procmail filter would be convenient. Any other thoughts?

P.S. any links to you're software yet? Will it be opensource?

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

Re:This can be good...

[titusjan]

On second thought, better use netcat instead of mail.

Re:This can be good...

[SpaceLifeForm]

Skew is the error in the processor clock compared to actual time. It is always there.

More info here.

Re:This can be good...

[bort27]

Well, of course she had the foresight to determine her clock skew before the laptop was stolen, right?

Good. In that case, here's a script that might be useful for you in tracking down the thief.

#!/usr/bin/perl

for (my $a = 0; $a < 256; $a++) {
for (my $b = 0; $b < 256; $b++) {
for (my $c = 0; $c < 256; $c++) {
for (my $d = 0; $d < 256; $d++) {
system ("calculateclockskew $a.$b.$c.$d");
}
}
}
}

Coding the program "calculateclockskew" is left as an exercise to the reader.

bort.

Re:This can be good...

[maotx]

Right now it's just a "what if" phase but its been growing on me for a while now. Also, LinuxBIOS is not the only one I'm looking at as each open bios has their own limitations. I'll create a page for it at my site (down right now for maintenance) if your interested with what I'm coming up with and/or want to share some thoughts. I'll have something up this weekend.

The software will also be opensource (probably GNU)

Re:This can be good...

[evilviper]

You seem to know what clock-skew is... What you don't seem to know is that NTPd includes tickadj, which uses the data from NTP servers to determine your hardware clock-skew, and correct it as best it can...

Re:This can be good...

[evilviper]

Ever try to swap a quartz in a notebook?

No, though I did do it many years ago with a few desktop machines. Addition, I have taken apart and repaired many notebooks.

If you have enough skills to do that, you probably don't need to bother stealing laptops in the first place.

Where do you get that idea? Crime always pays more than the equivalent legit work... I don't expect every thief to have the ability, I just expect them to know who to take stolen notebooks to, to have them "fixed".

Most people who steal laptops don't even reinstall the OS

I would very much like to know where you've gotten that stastic.

Sure, there are amatures stealing laptops, just like there are amatures stealing cars, but they are easily thwarted (eg bios password) and the experts are the real problem.

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.

How did you come to that conclusion? If I can ping 1,000 computers that I suspect might be my notebook, how does that prove they are?

Additionally, this would be of more use in combination with something like Carnivore, which allows the FBI to read all the packets to/from a machine, and extract information (like clock skew) from the data. In that way, if someone "important" has their notebook stolen, this method might help find the amature that took it.

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

[einhverfr]

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

I doubt that the timestamps will survive going through a SOCKS proxy server (or any other non-transparent proxy). In fact what you have described is a proxy server.

It would be relatively simple to do the same for transparent proxies as well-- TCP connection in gets intercepted and is handled with a new TCP connection out.

Re:Dangers with licence activation

[Welsh Dwarf]

I think the problem would intervene when the same prouct key was used on multiple machines, so the case of false positives shouldn't arrise

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

Re:Dangers with licence activation

[Oriumpor]

I like this approach, as it involves isolation at the network layer. Still only those bright enough to flash firmware will be able to stay obfuscated.

And who's to say we won't see a bill that prevents US citizens from staying anonymous in the future. Far fetched, perhaps but still not that far from the Patriot atrocity.

I can see this from the top down being a powerful tool for anyone tracking a specific host. Still the Fed already has this one covered. The best way to impliment this would be at the carrier level. With a carni box sniffin packets at almost all big ISPs they've already taken care of that.

Re:Dangers with licence activation

[Elbeno]

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

"... we stress that our techniques do not provide unique serial numbers for devices"

They recognise that of the millions of machines on the Internet, many will have identical clock skews within measurable limits. If this is used for activation purposes, the only application would be of a negative result - i.e. you can't install it again on a machine with a different skew from the original.

Re:Dangers with licence activation

[Perl-Pusher]

So as long as your computers skew is consistent, then it will always finger print as your computer.

So I can't decide to change the clockspeed because I bought a new CPU? Say I change the CPU from a 2.6Ghz to a 2.8Ghz? What if my BIOS has a feature that varies the clockspeed with CPU load in order to save juice? Changing the frequency will change the skew because the scew is caused by capacitive and inductive reactance which is frequency dependent.

Re:Dangers with licence activation

[Eric604]

Dude, clocks are run by a piece of hardware with it's own pulse generator seperated from the motherboard's bus speed.

Re:Dangers with licence activation

[Gr8Apes]

what if I swap out my motherboard? I won't be able to reinstall my legally bought software? What a crock!

Re:Dangers with licence activation

[Perl-Pusher]

True but no periperial one sees the pure clock signal, all they see is the multiplier applied to whatever bus it's applied to. From a NIC that would be the PCI BUS speed. The multiplier induces skew it cannot make a perfect pulse copy while doubling or tripling the pulse frequency. I change memory and the bus speed in my bios and the skew changes.

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?

[xv4n]

what if you just changed the NIC everytime you connected to the network?

No. What you want to change is the CPU itself.

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.

Re:How about this though?

[BWJones]

so wouldn't changing the FSB or Multiplier fix this?

Not working out the math or knowing exactly what Tadayoshi has done, I cannot say for sure, but I am inclined to believe that the resulting signature would be a harmonic or some multiple of the original and still easily able to be identified by adding a function that searched possible variations along any simple modifiers.

Re:How about this though?

[EduardoFonseca]

What about mobile CPUs that keeps changing frequency according to system load?

Re:How about this though?

[Tassach]

The attack works because most TCP stacks tell you what time the sending machine thinks it is. Because manufacturing variations cause a unique time skew rate in each device, this gives you a way to identify a particular machine.

This vulnerability can be easily defeated by modifying the TCP stack so that it applies some (cryptographically secure) random variation into the outgoing timestamps. Running some software which disciplines the local clock and compensates for hardware clock drift (NTPD) should also help eliminate the vulnerability.

Re:How about this though?

[pilgrim23]

This technique, if I am not mistaken, relies on timing, that is as he calls it "clock skews". This raises the question of what clock? Is this referenced to the system clock of the CPU of the machine? is this the timing on the chipset of the NIC? is this NIC specific? Does it work with a modem and dial up? Does this effect all TCP implementations or only the more common modern ones?
To give an example: One can connect to the internet via TCP/IP using an Apple IIgs. This is accomplished using the Marinetti TCP/IP stackunder GS/OS 6.0.1 using the Apple Igs 65816 processor. Version 2 of the stack can work using either a modem and a dial up link, or the LANceGS Apple II NIC (or the rare Apple Apple II ethernet card). Version 3 includes the ability to connect using MacIP using a 68k based Macintosh running MacOS 7.5 as a router. In this case the TCP/IP link is translated to serial and therefore the only NIC involved is at the router. Next point: though the Marinetti stack requires the 16bit GS/OS 6.0.1 to operate, the LANceGS ethernet card can be addressed and modified via the included utilities in ProDOS (an 8 bit operating system) and can therefore be run on an Apple IIe. Why is this important? Well, given a TCP link is developed under ProDOS on an Apple IIe using this setup, consider the fact that an Apple IIe DOES NOT HAVE a System Clock. Timing is achieved strictly in software. This example is strictly in the Apple II hobbyist retro-computing world but, I am sure similar examples can be found in embedded systems, among the Commodore 64 aficionados, in CP/M based systems, and quite a number of other systems. . If you want to look any of this up please do, but I am not posting the links because my friends would kill me if they get slash dotted!

Re:How about this though?

[Mr Guy]

Why bother with all the trouble of randomness? If this relies on a degree of accuracy in the information being sent over and above what the protocal requires, just truncate.

Re:How about this though?

[InfiniteWisdom]

How about assuming a little and Ring TFA a little more?

Unanonymousing?

[Anonymous Coward]

unanonymousing, or identifiying?

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

Re:Obligatory bash quote

[Tuirn]

We've lost machines at work. Big cube farm with lots of lab space. We had at least 1 time in the last year that a machine was found to be improperly configured (or was it infected - can't remember now) and needed to be taken off the network. It took days for us to find it.

Re:Obligatory bash quote

[_Sharp'r_]

Did you consider disconnecting the offending computer from it's switch port, instead of from it's end?

Seems like that'd be a lot faster to find, assuming you have any kind of decent switch management at all. Typically, you wouldn't even have to physically pull the plug.

Re:Obligatory bash quote

[swillden]

We've lost machines at work. Big cube farm with lots of lab space. We had at least 1 time in the last year that a machine was found to be improperly configured (or was it infected - can't remember now) and needed to be taken off the network. It took days for us to find it.

Why not just SSH in and tell it to shut down, then look for the machine that's turned off?

Re:Obligatory bash quote

[nacturation]

We've lost machines at work. Big cube farm with lots of lab space. ... It took days for us to find it.

Eject the CDROM tray. Works for me.

Re:Obligatory bash quote

[0123456]

"hm. I've lost a machine.. literally _lost_"

We've done that before at work: our solution was to rlogin and play music, then listen for which machine was making the noise :).

Re:Obligatory bash quote

[tricorn]

Even better, just have it start making some sound (a siren, alarm clock ringing, telephone ringing, whatever). On Mac OSX (maybe just in 10.3, not sure if you can do it in earlier versions), there's a "say" command which uses text-to-speech - just put it in a loop: say "Help me, I'm lost" every 10 seconds or so.

Re:Obligatory bash quote

[swillden]

Hehe. I assumed the machine was a server, which commonly have no audio output devices attached. Well, maybe a "PC speaker", but "real" servers often don't even have those. I guess "real" servers seem unlikely to get lost, though, as they tend to live in nice racks...

I like the "Help me, I'm lost" notion, though :-) BTW, on my Linux box:

echo "Help me, I'm lost" | festival --tts

will do the same thing.

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

[msaulters]

I agree... very good point.

However, it's one piece of data that can be added to other pieces of data to uniquely identify you.

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.

Re:So...

[Have Blue]

I haven't read the paper, but what if they established a pattern over a large packet capture? The sequence of slots in the 240,000 possible time deviation values could be a unique property in and of itself.

Re:So...

[sosume]

Look at it the other way around. If you suspect someone is doing evil deeds on the internet, all that needs to be done by law enforcement is gather some legitimate data from that person, for instance an e-mail. The clock skew can than be compared to the illegitimate traffic, for instance something routed through hundreds of hops, for the same clock skew.
Since the chance of having the exact same clock skew is very remote, this could then be used as real evidence in a court of law.

Ofcourse you can write a packet proxy that can rewrite the entire packet and forward it.

Re:So...

[orac2]

Unfortunately, and as the article points out, NTP synchronises only the System clock. Most of the article concerns itself with the TCP stack clock, an independant and different clock which doesn't get synched with NTP (it's also typically just set to zero at boot time as another example of its difference to system time)

Re:So...

[Fred_A]

Damn you mean I should have read the article ?
(yes Ok, I should have, shame on me. I'm not even new here)

It's true that the timekeeping circuits on most (every, really) motherboard are so poor that the skew should appear quite fast if that's what's used by the TCP stack to increment it's counter. I know that there are some architectural constraints (or legacy crud rather) at work there as well, but it still sucks.

I've had machines (PC clones) that, left to themselves, drifted by as much as 15 minutes per day.
OTOK my (now a bit old) Vaio Picturebook laptop maintains fairly good time even though it can go for weeks without connecting to the network. Never had a desktop machine that performed that well in that regard.

Re:So...

[RomulusNR]

But over time, you can take repeated samples of that time and thereby determine its drift far beyond 1 ms.

This is clearly not (or not obviously) an "okay, he's connected, it's him" solution. The story points out that their test on 69 XP boxes ran for 38 days. That's an awfully long time unless you're on a long haul sting. The "prettiest" unique timestamp graph in the paper (figure 3) covers a 96 hour period, for 69 hosts. To truly do unique fingerprinting of this sort when you have to content with a single ISP's worth of hosts is probably going to take an awful lot longer than 96 hours. The technique would actually be better off if the skews weren't perfectly linear.

I'm not sure it's practical. It's interesting, but not practical.

Anyway, it seems to me I could easily fiddle with my clock time at the millisecond level (probably in the stack code rather than actual system time, but who cares?) in such a way to throw off this technique.

From the paper:

Unfortunately, because Windows 2000 and XP machines do not include the TCP timestamps option in their initial SYN packets, the TCP timestamps RFC [13] mandates that none of the subsequent packets in Windows-initiated flows can include the TCP timestamps option. Thus, assuming that all parties correctly implement the TCP RFCs, a passive adversary will not be able to exploit the TCP timestamps option with Windows 2000/XP-initiated flows.
If the adversary is semi-passive, we observe the following trick. Assume for simplicity that the adversary is the device to whom theWindows machine is connecting. After receiving the initial SYN packet from the Windows machine, the adversary will reply with a SYN/ACK, but the adversary will break the RFC 1323 specification and include the TCP timestamps option in its reply. After receiving such a reply, our Windows 2000 and XP machines ignored the fact that they did not include the TCP timestamps option in their initial SYN packets, and included the TCP timestamps option in all of their subsequent packets.

So if you're looking to avoid detection via this method, you need to ignore ICMP TSTAMP requests (used in the "active" technique) and have a TCP stack that never sends TSOpt timestamps (used in the passive and semi-passive techniques). Apparently Windows boxes normally get through life quite fine without them. One wonders if the TCP performance benefits of the TSOpt are really relevant in an era of broadband and high-speed links for the majority of uses.

Another way that seems implied by suggestions about the best fingerprint-detecting device would be to have your system clock maintained by something better than NTP. The paper suggests CDMA and GPS as higher-accuracy alternatives for the attacking host; no comment on how it affects the process if used on the target host (especially if the attacking host doesn't).

Re:So...

[slide-rule]

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?

After reading this several times on this thread, it occurs to me that 'common sense' on the investigators part might fill the gap: If a particular [dynamic] IP address did something naughty and a clock skew was logged, then the Fed's can watch all traffic coming from the ISP's net block for that particular clock skew again (or something like that). Surely these guys know there isn't resolution to track across the full range of 'Net-connected computers w/out some way of cutting the sample size down before hand. Like many tools, it isn't a magic bullet, but does add one more tool which can be useful in the right set of circumstances.

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.

Re:Easily avoidable?

[good-n-nappy]

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

This was the first thing I thought of too. But aren't our current pseudo random number generators based on the clock too? Still, I'm guessing it would take a lot of connections to reconstruct your clock skew from the random numbers it generates - i.e. in the scenario mentioned by the previous poster where you increment the time by a consistent amount for each connection.

Re:Easily avoidable?

[cosinezero]

Seriously. Anyone with any ability to edit outgoing packets will be cloaked before most of slashdot is done reading TFA.

Re:Easily avoidable?

[WhiplashII]

The easy answer never seems to work. In this case, simply adding a small random value to the time merely lowers the signal to moise ratio (the random value is essentially noise). The signal to noise ratio starts out so low, that in order to make any real difference you would have to add so much randomness that you might as well not send the time anymore.

As an example, let's say you add +- 30 seconds to your time. Now, in order to figure out the time to the millisecond, I need about 30,000 samples. But I needed way more samples before anyway, so an additional 30K is no problem.

Re:Easily avoidable?

[mc6809e]

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

I dont think so.

The technique measures the skew in the clock, NOT the variance in the clock.

Besides, the time stamps are already somewhat randomized by the other things going on in the system.

The technique probably alrady uses some sort of averaging to overcome this.

Re:Easily avoidable?

[JustKidding]

The technique measures the skew in the clock, NOT the variance in the clock.

Indeed, one would only need to average the difference between the target and the host time to calculate the time skew, which would (nearly) completely eliminate any random factor, as the sum of a large number of randomly generated number will be (approximately) half the range of the number, by nature.

On the other hand, what's the use? There is no point in changing the skew during a connection, as the host will still have the same IP address, it isn't exactly hard to track. It would be usefull, however, to alter the skew (by a little or a whole lot) between different connections, making it impossible to link the connections to a single machine.

A firewall or NAT device could ofcourse, calculate the difference between the time in a packet and it's internal clock, overwrite the time in the outgoing packet to masquerade the machine on the protected network, and overwrite the timestamp again in the respective incoming packet. That should keep anyone from detecting and identifying devices behind a firewall.

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

Your Rights Online

[WormholeFiend]

just disappeared completely.

(I mean your actual rights, not the /. category)

Re:Your Rights Online

[Atzanteol]

Yep. There they go. I'm not even allowed to post this comment now. Or to say that George Bush is a moron and doesn't deserve to be president.

Wow, I hate this new fascism. Why do I bother writing this? Nobody will ever see it now that my rights on-line are gone...

Re:Your Rights Online

[WormholeFiend]

on the plus side, we should be able to ferret out those pesky spammers, for some hot, throbbing vigilante justice...

Re:Your Rights Online

[willCode4Beer.com]

Don't we need to have "rights online" before we can lose them?

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?

Re:Slashdot is Slipping

[Pollardito]

"Slashdot: Blurbs for Nerds, links to TFA are purely ornamental"

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, check also their other freeware, some are pretty neat!
PS: no, I do not work for them!

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:for windows user

[Rinzai]

I disagree. If the clock is constantly reset by an external process, this would skew the skew--the clock might appear sometimes to tick at 2 second intervals, and sometimes in 0 second intervals. Assuming that the clock reset occurred at random intervals (based on a long-period pseudo-RNG), I'd think this would make the process much more difficult.

How would you isolate one among many randomized skews?

Re:for windows user

[martysdomain]

when machines get older there is wear and tear on the components, and the tolerances lower, wouldnt that change what the signature of your clock/signal of the machine?

Re:for windows user

[pg110404]

To make matters worse, there's the runtime clock and the CMOS clock. Both are technically independent of each other (on boot up the OS will reset the runtime clock to the CMOS clock, but after that they are independent).

The drift of the CMOS clock will certainly be different than that of the runtime clock.

This is not really much of a problem for people who turn off their computers every day when they don't use it because any drift from the OS run clock will be reset to that of the CMOS, but for someone like myself who leaves it on 24/7, the drift can get be pretty bad and different on both.

That's why I use an NTP utility to keep it accurate and once a week, the OS updates the CMOS clock whether it needs it or not.

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?

[cfalcon]

This kind of post is why I read slashdot- big article about a thing, and in FOSS land there is a one command line solution.

Assuming this works, of course.

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

[Doc Ruby]

I love it when a "Fan" posts exactly the comment I would have, but then don't have to. Right on.

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.

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

[stratjakt]

They can detect that I don't appreciate being tracked online without my consent. That's fine with me, so long as some asshole isn't aggregating a bunch of data like "Hey he's in a starbucks in Cleveland, hey he's in Boston, hey he's in Japan".

Wait until the Direct Marketing Association (aka, spamming assholes) starts portscanning class A's with this technique to gather marketting data.

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

[wumpus188]

Yeah... you can turn this off on Windows too.
Set

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Tcpip\Parameters\Tcp1323Opts = 0

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

[net_shaman]

newbie ?:
Which start up script should I add this line to?
Fedora Core 3

Thanks!

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

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

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

[1110110001]

Mac OS X has the exact same option which should do the same thing.

b4n

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

[texroot]

You can use /etc/rc.local.

If you want to go to more trouble you can write your own script, add to /etc/init.d, create symlinks in the rc.d directories for different runlevels or use chkconfig to do so.

But the simple way is to just add to rc.local.

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

[mrtickle74]

Add

net.ipv4.tcp_timestamps = 0

to /etc/sysctl.conf and then

sysctl -p /etc/sysctl.conf

to activate the setting change. The setting will then persist after a reboot.

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

[caluml]

I was trying to work out what effect or side effects this could have. From /usr/src/linux/Documentation/filesystems/proc.txt, it references RFC1323, which says "The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences)."
I'm going to do some tests with it enable, and disabled, and see if I can find any difference. Google didn't turn up anything in the first few results one way or the other.

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

[savant_x]

How would you do this with ipv6 in FC3?

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

[ford_prefect_bg]

So I have a Centrino laptop which constantly adjusts the CPU core frequency according to the current load. Does this mean that no one can nail me with this timestamp fingerprinting stuff?

Ok.

[Anonymous Coward]

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

Gee, that doesn't sound breakable.

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

[good-n-nappy]

OK, I thought this too - but how do you get non-deterministic information on current PCs? I'm seriously asking because this isn't my area. I thought current pseudo random number generators use the clock. If so, this is making the problem harder - but isn't it still essentially the same problem?

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.

Re:Sceptical

[dunc78]

Strictly speaking, anything a computer does is deterministic. Just with the other methods you speak off, the sniffer doesn't know the inputs to the determistic system. Just a minor point.

Re:Sceptical

[jerdenn]

Yes, of course you are correct, for the current definition of 'computer'.

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!

Re:TCP/IP stack

[jimthev]

to add or subtract one unit at random from the least significant digit of the timestamp.

Now you can be identified as one of those that has a random timestamper. So you can be placed on a watch list. What are you trying to hide?

Re:TCP/IP stack

[Laurentiu]

If enough people concerned about their privacy do this, this won't be a tag any more ;) If they can get a search warrant just because of that, I'm screwed anyway, since I use SSH a lot.

Oh wait. Yes, Officer? Just let me press Submit and I'll be right with you.

Re:TCP/IP stack

[chris_mahan]

I'd have to say that this is correct. You would simply create a wobble in the skew pattern, but the skew pattern could still be detectable over time (say 10 hours) and even adjust for time of day, etc.

I suppose, as someone said, that since heat level in the mobo will affect the skew, that having a programmable fan for the crystal(s) would allow for geek-control of the skew itself. This might even lead to mightily accurate clocks, since the skew itself could then be adjusted, and clocks synchronized with the US Navy (official timekeeper in the US -- See http://tycho.usno.navy.mil/).

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

Re:What about IBM's laptop anti theft stuff

[NeoSkandranon]

Good points, but I'd almost put money on the majority of stolen laptops going more to the junkies and petty thieves as opposed to industrial espionage.

Terrorists... clearly terrorists...

[ixpro]

What's the name of that organization again? These guys are clearly the notorious terrorists and axis of evil!

Interesting, but limited

[MrAnnoyanceToYou]

This doesn't mention that all the timing and stack styles could probably be modified to change the way they communicate and mask these fingerprints... I don't know how it's done, but that seems moderately important. Really, it seems like this could be more of a bonus to people looking for the clueless. It's not the spammer-hunting tool for the new millenia that I'd love to see developed and used.

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.

Re:NAT

[quelrods]

Exactly! After the technique to use timestamps to count hosts behind nat OpenBSD added tcp options to the scrub directive. For all my isp knows I have a single box since I have the firewall generating strong ISN's as well as scrubbing timestamps.

That's nice.

[chris_mahan]

I am very happy about these developments.

This will make society much better.

I am sure law enforcement will use this to better protect us.

Read my sig.

Gentlemen, time to synchronize your clock skews.

Re:Wouldn't it be easier

[Pfhreakaz0id]

MAC's can be modified. There are NICs that allow MACs to be modified, for instance. Also, My firewall allows it's MAC to be modified. It even has a handy function to clone the MAC from your nic..

So this will let me...

[Mikito]

...use the computer that's in front of me in order to go online so that I can find the computer that's in front of me.

Re:Wouldn't it be easier

[ajw_h]

If you call completely unique trivial to change to a different value of your choosing, then yes it would be easier.

Re:Wouldn't it be easier

[0x461FAB0BD7D2]

It would be, in most cases, however it is still possible to change one's MAC address, so that wouldn't work too well, especially when trying to track technically-knowledgeable types and criminals.

Re:Wouldn't it be easier

[jmpvm]

In theory they are unique, but in practice they may not be. Also, MAC addresses are easily spoofed.

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:What are you using to track?

[dfj225]

I think perhaps the biggest application of this program, would be to use it to prove, once you have the TCP packets, that they did indeed come from the same box. However, I think even this application is flawed, as I would imagine the biggest reason someone would want to have a "fingerprint" of a computer is to convict its user of some crime. Usually, the prosecution is required to prove his/her case beyond a resonable doubt, and, as you said, with all the machines on the internet, I think it is very reasonable to doubt that TCP packets with the same skew are indeed the same computer.

Re:What are you using to track?

[m50d]

They have to force windows to use different TCP settings, so my guess is this is only useable from the endpoint i.e. the website the person they are tracking is visiting, or by MIM at that site's first hop. Could be useful for finding out how many unique visitors there were to a child porn site, so they would know if they had any more to catch before they moved in on the site itself (ISPs tend to be cooperative in such cases). Or something.

Re:What are you using to track?

[lgw]

Well, that depends whether you're looking for enough evidence to stand on it's own in court, or just enough to convince a judge to give you a wiretap warrent.

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:yet another smackdown for freedom

[RedBear]

How this thing qualifies as a "smackdown for freedom" is simply beyond me. That entirely depends on how it's used and how quickly we can make the technique worthless with a security update.

Now I can't be an anonymous coward because slashdot can sniff my time-skew and put my name up anyway.

Um, you have to be registered and logged in to post anonymously. Slashdot can already decide to unmask all ACs henceforth if they feel like it. Probably not retroactively, but I don't understand slashcode enough to verify that. Fingerprinting your computer would be a useless addition that would only tell them you logged in from a particular piece of hardware.

Where are the days when I could telephone someone and NOT have to be identified. (caller id).

Those days never existed that I know of. The telephone system has always been able to identify where you are calling from, they just extended that capability to the home user with the Caller ID service. What gives you the right to be anonymous when you call someone else? If you want to be anonymous, call from a payphone. It will still probably tell them your address. That's the nature of the phone system. If you really want to be anonymous, don't use the phone system.

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.

What. The. Bleep. Are. You. Smoking? That's a new one. Security through mutual worldwide agreement of packet sacredness? Good luck. And what does "necessary" have to do with anything? Was it "necessary" to climb Mt. Everest, or land on the Moon, or discover that uranium ore exhibits radioactivity?

No, this isn't "peeking through the curtains". This has nothing to do with your privacy in your own home. If you don't want anyone analyzing the packets that you send outside your four walls, don't send any packets out. Nobody is "peeping" into your LAN. You are handing them all the information they need to find this fingerprint from anywhere in the world. Either don't send the information out or mangle it in some way to keep it from being identifiable.

This fingerprinting technique is merely knowledge gained from understanding a technology. Knowledge is neither good nor evil, and knows nothing about what we consider sacred and what we don't. All knowledge can be abused. The answer is not to bury our heads in the sand and demand that no one analyze our TCP packets without our permission. The answer is not to demand that knowledge not be used, or new knowledge not be created. The right answer is to adapt to this security threat with new technology and move on with our lives. Oh, and it would be good to have some sense of reality while we're at it.

Re:yet another smackdown for freedom

[pintpusher]

while your trashing of my post is pretty good, I think you're missing the point. There seems to be a drive to find more ways of tracking what people are doing. My gripe is that I don't really see where this gets us except that now there is yet ANOTHER way for people to look at what you're doing. Whether you want them to or not. Inevitably somone will try to use this to their advantage without concern for my privacy or what damage it may do to me. I'm merely arguing that there has to be a point at which we decide we don't accept this anymore.

No, this isn't "peeking through the curtains".

Actually it is. I have multiple machines behind my NAT box. They are behind the box because I want them to access the web, but I don't want them open to the public. This fingerprinting technology allows them to "see" behind my box and see that I have other machines, and perhaps what OS they run etc. I prefer not to have that happen. So now I have to find a way to change the timestamps on packets so others can't tell what's going on. I have to pro-actively protect my privacy. That's an annoyance and, personally, I think its wrong. My privacy should be protected by default. True they "see" behind my box because I send packets out. Just like a peeping tom sees me through my windows because I reflect light out.

Also, don't get me wrong. I think the technology is cool and its an interesting bit of creativity to come up with this thing, but damn I lament yet another way for people to find out what I do.

Re:yet another smackdown for freedom

[RedBear]

while your trashing of my post is pretty good, I think you're missing the point. There seems to be a drive to find more ways of tracking what people are doing. My gripe is that I don't really see where this gets us except that now there is yet ANOTHER way for people to look at what you're doing. Whether you want them to or not. Inevitably somone will try to use this to their advantage without concern for my privacy or what damage it may do to me. I'm merely arguing that there has to be a point at which we decide we don't accept this anymore.

Don't see where this gets whom? It's just a piece of knowledge. Like a lot of knowledge, in the right hands and with the right uses it could benefit many people by helping to identify crackers and stolen hardware, etc. In the wrong hands it could do a lot of damage, until we make the technique useless which it sounds like should happen pretty quickly. In systems like Linux and OpenBSD people have already posted how to turn off the feature that allows this fingerprinting technique to work. It can be done in a few seconds, and will probably become a default in most open source operating systems before the year is out.

The problem is that your statement assumes that "we" (whoever "we" is) run the world and have some sort of control over all the people in it. This is really a pointless and misdirected sentiment because nobody has control over everyone on this planet. If you don't want someone walking by your house to peek in your window, it's accepted that you already need to take some reasonable technological pro-active actions like pulling the shades over your bay windows before you get nekkid.

You had a good point there about the emission of light but you missed its significance to your argument. If you don't take privacy precautions the person who looks in your window is no longer a peeping tom, but an innocent bystander who can even charge you with lewd conduct if they can clearly see you nekkid from outside your property without taking any unusual action like climbing a tree. They aren't invading your privacy if you aren't taking any real action to protect it. There is an expectation that they won't try very hard to look inside your house, but there is also an expectation that you won't display the inside of your house where everyone can see it without even trying. If you build your house of glass, any court in this country would say that you have no reasonable expectation of privacy.

As we all know, computer analogies are always very rough when they relate things to the real world. The emission of identifiable packets from your NAT is the same as having a completely uncovered window. It just happens that everyone walking by up until now was legally blind and couldn't see clearly the identifying information embedded in your packets. Now that someone has developed a pair of glasses to let us bring into focus the packets (photons) coming through your NAT (window), you'll have to do the equivalent of putting frosted contact paper over your window. You'll have to randomize that fingerprinting information like contact paper would scatter the identifiable photons.

This fingerprinting thing isn't the equivalent of peeking through the curtains. If your curtains are closed, I would have to use a telescope or come right up to your house into your yard in order to look inside through the crack. That's the equivalent of taking an action like tapping your LAN or inserting a trojan into your internal network. It's active rather than passive. I don't buy that analyzing traffic going over the public Internet (sidewalk) is the same as peeking through the curtains. This is more like the police taking surveillance photos of you walking down a public street. In the same way, the packets being analyzed are walking down a public wire.

Again, if you don't want to be identified, don't send the packets outside your LAN, or make them put on a disguise. Your NAT box lets your computers onto the public Internet, it doesn't necessarily keep the public Int

Re:yet another smackdown for freedom

[pintpusher]

many days since original article and I'm too lazy to look it up, but my peeping tom reference was directed at the ability to make a machine produce the timestamp even if the machine's owner had intentionally turned it off. I recall a line about forcing windows to produce fingerprintable timestamps. That, IMO is peeping tom-foolery. If I configure my windows box to no longer include timestamp and someone forces it back on from the outside, that's a problem. That's analogous to creeping up under the window to look through the small crack in the curtains, or perhaps reaching through the open window to push up the shade. Follow?

for the record, I turned off tcp_timestamp within minutes of reading this -- not because I have anything to hide, but simply because my Tin Foil Hat was getting worn.

I totally agree that these bits of information need to be public and that our security is better as a result. I am merely tired (that is worn and mentally frayed) from the constant stream of new ways people can look at you that I didn't know about. I'm really a luddite at heart and wonder what I would have done were it not for tin foil.

Re:yet another smackdown for freedom

[RedBear]

I recall a line about forcing windows to produce fingerprintable timestamps.

That's something I hadn't heard. Typical of Windows to be controllable externally in such a manner. Definitely a little closer to an active action to unmask the user.

I am merely tired (that is worn and mentally frayed) from the constant stream of new ways people can look at you that I didn't know about.

I hear you. It's not a fun universe some days. But life goes on. Cheers.

On Linux...

[macemoneta]

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

Re:On Linux...

[Tassach]

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

IIRC, modifying system parameters via /proc isn't persistent between reboots. I'm pretty sure you'd have to add this to /etc/sysctl.conf if you want it to be persistent:

net.ipv4.tcp_timestamps = 0

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.

Re:Wouldn't it be easier

[Anonymous Coward]

not really... MAC's operate at layer-2, and thus would not make it past the first router. In addition, MAC's are easily changed.

Re:Wouldn't it be easier

[bagel2ooo]

There are a number of problems with that. MAC addresses can be spoofed at least behind the firewall (even in some cases with static arp tables.) Also, the smaller nic manufacturers have been known to have MAC address collisions even as low as 1 in 12 (which I've personally witnessed on some bad deploys for clients by other companies.) Then there is getting the arp information from the firewall/router they are behind.

Re:Wouldn't it be easier

[Tenebrious1]

Wouldn't it be easier to just look at the MAC address on the NIC. It is completely unique and the internet is just a gigantic network.

MAC addresses can easily be changed or spoofed. MAC addresses also do not get sent beyond the local segment, so you won't find a computer's MAC address on any packets beyond the first router.

Re:Wouldn't it be easier

[Jonathan_S]

Wouldn't it be easier to just look at the MAC address on the NIC. It is completely unique and the internet is just a gigantic network.

Not really. First you could trivially hide your computer by swapping out the NIC. New NIC = new MAC address.

And second placing your computer behind NAT hides its MAC address from anything upstream. They can only see the MAC address of the NAT device. (Which is also usually easy to change, in order to work with ISPs who attempt to lock the connection to the MAC address of the first network card to use it)

This new idea is suppose to be able to identify individual computers behind NAT and, apparently, since it relies on the motherboard's hardware clock skew it should also still ID a computer even if the NIC is swapped out.

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:Clocks Drift

[Chyeld]

The drift is actually what they are using to do the finger printing. They are figuring how much 'drift' you actually have and using that to decide later on that another machine with a similar drift is you. They beleive they can do this because the drift itself is mostly constant.

Re:Clocks Drift

[willCode4Beer.com]

Its the "clock drift" and "inaccuracies" that are being used as the fingerprint.

NTP and ambiant temp

[martin]

Surely both of the above would mess with the clock skews esp as xntp will do it's best to keep the time sane..

OpenBSD

[Alioth]

I wonder when OpenBSD 'pf' will normalize the tcp timestamp on packets passing through an OpenBSD firewall. Probably with OpenBSD 3.7 no doubt.

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.

Re:Wouldn't it be easier

[nocomment]

Not completely unique. They can be modifed, they are hidden by firewalls and can only be seen by others on your same logical network. Not only that, but Vendors re-use MAC's all the time. Though they usually send those cards to other places of the world.

So no, tracking by MAC is completely useless outside your own LAN.

We need a large base of samples

[anticypher]

Please visit our publicly facing tracking site to ensure we have a reliable base of micro-skew signatures. This will enable us to quickly identify M$-hating, freedom-loving^W^Wterrorists.

the NSA^Wanticypher

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:Doesn't work that way

[feagle814]

On Windows, changing MACs is dangerously simple with the open-source commandline tool Macshift (http://macshift.natetrue.com)

Countermeasure

[ENOENT]

For laptops, run ntpdate at startup. For other hosts, use ntpd.

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

hack-back?

[scaltagi_the_pirate]

This is very good for those who are interested in protecting their own assets by using offensive techniques - this removes some of the uncertainty of who you are actually retaliating against. www.activedefense.org

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?

Re:Changing Clock

[chris_mahan]

Yes, but how often? Every 120 seconds? Every 360 seconds?

Could that pattern be discovered as well?

So let's say your pc, when full-powered, at room temperature, gains 1 millisecond every 20 minutes, (skew) and thus, after a while, your clock is off by a second from the official time (drift), and you change the time every 2 minuutes randomly, you will have created a detectable wobble every 2 minutes in a 20 minute pattern. Sort of like waves and tides.

What you need to be able to do is slow down/speed up your clock crystal, so that the change in millisecond has a random pattern (say like hookup the to-be-installed crystal fan to your phone: Every time the phone rings, you get a few minutes of fan, thus cooling the crystal, thus altering the pattern).

Yes, I am a geek.

Re:Changing Clock

[FranTaylor]

"Room temperature" is not constant. Don't worry about introducing randomness into the system, it's already there. There is a lot of hysteresis in the thermostat. The presence of people, sunlight, etc. in the room will have a noticable effect on the temperature. The temperature has a profound effect on the crystal's resonant frequency. And what happens if the computer gets turned off, and then back on again? Uncharacterizable errors will be introduced in the process of transferring the "correct" time back and forth between the battery clock and the system clock. This stuff has to go under the category of "noise" unless it can be characterized. Is this guy going to start analyzing thermostats, furnaces, and sunlight? "Real" frequency generators put the crystal in an oven with lots of thermal inertia and small hysteresis in the thermostat. This analysis ignores all of these effects. The researcher clearly spends too much time in his air-conditioned laboratory.

Re:Changing Clock

[chris_mahan]

Good point.

Re:Changing Clock

[m50d]

The rate will still average the same. What you would need is something that slows your clock by 3 miliseconds an hour this boot, then speeds it up by 6 next time, and so on.

Re:Changing Clock

[iammrjvo]

I was thinking that changing it according to a pseudo-random algorithm would do the trick.

Re:Changing Clock

[stratjakt]

No you just need an iptables rule to mangle the timestamp on outbound packets.

Everyone needs the same rule, so when this asshat starts portscanning class A's, he sees the same machine a billion times.

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

Intel already did it

[mattspammail]

http://support.intel.com/support/processors/pentiu miii/sb/CS-007579.htm

Remember when Intel announced processor identification? They were slaughtered! They ended up shipping P3's with this feature turned off.

My bad...

[bsd4me]

Oops; brain fart. ntp.drift is the wrong place to look. You have to enable statistics loging in ntp.conf.

Re:Wouldn't it be easier

[Taladar]

1. Macs are only visible to directly connected devices
2. Macs can be changed by Software

Re:Doesn't work that way (MOD PARENT UP)

[demi]

It's funny how all of the replies to the question missed the primary point that MAC is a link-level address and is only used on your link.

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.

Re:Wouldn't it be easier

[slungsolow]

Thanks for the clarification. I wasn't 100% sure of it so I phrased it as a question and I appreciate (the many) answers and replies.

there are already methods to protect your LAN

[deadlocked]

with pf: scrub reassemble tcp

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.

If I were an evil internet marketeer...

[neiras]

...I'd be thinking "Wow! No more unreliable tracking cookies! Now my ads will always be targeted to individuals!"

Don't shoot me...

As a web developer, I was thinking more along the lines of "Yay! No more session cookies!"

Proxy?

[ThisIsFred]

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.

Does this still work if you turn off TCP timestamps? How about if you're behind a routing device that rewrites them (is there such a thing)? From what I've read, it's fairly trivial to toggle TCP timestamps (and other RFC 1323 options) in all the major OSes (I haven't tested MacOS 10). If fact, I just did it for the heck of it with my Linux box.

Also, depending on how the host clock keeps time, wouldn't this be subject to local fluctuations in power? This wouldn't show up in their LAN test, but if those machines are moved to another location with different conditions, wouldn't it?

Even worse....

[imsabbel]

They cant tell the time scew in that resolution, because to estimate it, they would have to guess the ping time with that accuracy.
And even if they have a large sample set, it would still be more like 3-5ms, and moving over time... what is shift in the backbone saturation, what is clock skew?
Plus like other people said: xp has atomic clock synchronisation on per default (mine has), so im one of the 50million machines that has an clock error of 5 or 10 seconds...
now 5ms accuracy would give us 2000-5000 slots, for 50million machines... not unique

Even for my internet provider (the pool of dynamic ips mine is from) it would still be secure enough, even without just faking the data

Good for unique visitor counting

[wheelbarrow]

This could be useful for websites wishing to get another means of counting unique visitors to a website. Today there are 2 ways and both are error prone. The first is cookies. The server hands the client a cookie and depends on the client to cooperate and give it back. The problem is that clients are increasingly not cooperating through routine use of things like cookie scrubbers. The second way is through representative sampling from a cooperative and statistically significant sample population. Stats gather from the sample are used to predict real visitor numbers. This is how rating services like Nielsen Net Ratings work.

Clock skew finger printing has the potential to out perform both methods that are in common use today.

Re:Good for unique visitor counting

[gl4ss]

then you'd get ~60 unique visitors and start wondering if they really can be all around the world.

(the technique isn't particularly good at determining individual comps from LARGE groups..)

works by measuring the clock skew rate

[ArbitraryConstant]

According to TFA this works by measuring the clock skew rate over a significant period (over a month is the example they give), so using something like NTP to keep your clock from deviating would completely screw it up.

Don't worry

[Prince Vegeta SSJ4]

the first comment will be on topic, insightful, and the the poster obviuosly RTFA tomorrow, and the next day as well.

In unrelated news......

[pg110404]

.....the RSA is using the time-stamp feature to determine how fast and how often people download porn

What about variations in the battery?

[Ralph Spoilsport]

1. If the energy going into a computer erodes due to degradation of the internal battery and other components (manifested in the erosion of the accuracy of the clock), wouldn't that effect the components and "change" the fingerprint?

2. What about multi-processors? If you're cranking from processor A one day, but the next day processor B is the one doing the talking,won't they have different skews? And if the thing is multi-threaded or multi-cored, one could get the skews changing erratically depending on which processor is "speaking" for that particular section of data.

Then there will be the guy who builds data skew randomisers, or the internet data equivalent of a video Time Base Corrector in his garage and sells them on that internet thingie for $200... (Actually I think a digital TBC would be a great idea, in general...)

I think the author of that paper is onto something, but that something is very historic for this moment. From what I can gather, a few basic changes in machinery could obviate his plans.

Interesting ideas, though!

RS

as long as it is not elCAIDA

[basingwerk]

This is fine and dandy as long as it is not elCAIDA behind all this.

Wouldn't it be easier?

[nihilistcanada]

To simply see where the Herbal Viagra and Penis Enlargement Creme is being sent too?

Linux patch available in 5 .. 4 .. 3 ...

[grahamsz]

It wouldn't be particularly hard to add a random skew to your timestamp data.

My first idea would be just adding a random number, but if the number were truly random then over a long enough interval the skew would remain the same.

Maybe you need some sort of slowly moving skew vector so that your timestamp clock really does skew but in a fashion which is random.

Re:Linux patch available in 5 .. 4 .. 3 ...

[climb_no_fear]

Since they have to collect a reasonable amount of data to determine your true skew, even the random approach without a vector make it much more difficult.

How about a second hardware clock hooked up to your computer? Or even better, a software clock that starts new with a randomly determined skew. The software clock is gets a HUP every 10 minutes to change its skew ...

Actually, no

[AbraCadaver]

You can run a program like macmakeup to change your mac to whatever the hell you want, which makes tracking by mac pointless if the target has any clue. You could do this every single time you log on to the internet (or random intervals, etc) to throw off tracking of your usage, along with changing what browser you "seem" to be using, responses to your OS type, and the way your system responds to pings, port scans, etc to appear to be just about anything.

Also, given that this new technique listed in the article seems to deal with response times, you just modify your response times with something else - an extra clock cycle here, 13 clock cycles there... And this technique is pretty useless. It's kinda a rehash of the idea of "fingerprinting" by the unique timing involved in how a user types, and anyone dealing with computer forensics will spot it right away. But hey, it's good enough to get him a reasearch grant, probably. How about giving me one to foil it now?

And lastly (and more importantly) once you acquire the data needed to indentify a system by this new method (basicly by conversing with it over the net, etc) what's to say I don't get a machine that can respond much faster, and spoof who I am because now I'm responding JUST like said system.... "Your bank account transfer has been accepted, Mr Gates..." :P

case of bad terminology -- not clock skew

[onemorechip]

I don't know what definition of "clock skew" he is using but to say you can measure clock skew by looking at time stamps generated from a single point makes no sense at all. Clock skew is the mean time difference between *two* clocks of the same frequency (or related by a rational multiplier). The skew of any clock measured against itself at the same point in a clock tree is always zero.

It seems likely to me that he is measuring the differences in clock frequency from a reference frequency. This is not clock skew. Call it "clock frequency variance" or something to that effect.

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:read the paper

[rpdillon]

Soldering can be easy, or very difficult. It just depends on scale. =)

I would tend to think that randomizing your skew with an altered stack or TCP driver would be effective. You have the right idea that "you'd be identified as the guy with the random skew", but only if there were other traits to associate those data points, like IP address, OS, etc. If you grabbed a couple of data points at one IP, and then grabbed another couple at another IP, you'd be hard pressed to draw a meaningful correlation.

Having just read the paper, my impression is that there is going to be a LOT of overlap in the skew-space, so this wouldn't be particularly useful in isolating a computer from a large crowd. Further, tracking would be difficult without a priori knowledge of where the computer *should* be, so that you can then test to see if the computer is actually there.

Re:read the paper

[srmalloy]

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.

If you read the paper, what they are describing is a statistical analysis of packet traffic to be able to identify distinct skew rates, and this rate being the identifying characteristic, applying a random -- or pseudo-random -- offset to the TSopt clock for each packet would fuzz the data but not change the overall skew rate (look at Figure 1 in the paper). What you would want to do in order to hide your computer is to periodically generate a small random value that you increment the TSopt value with for each packet, thereby making your computer's skew rate change from time to time; this would make your computer appear to be many different computers under the analytical process defined in the paper.

Re:read the paper

[Anonym0us Cow Herd]

Soldering?

Since most slashdotters probably grew up with computers, and never dabbled in electronics, they probably don't know which end of a soldering iron to pick up.

Re:read the paper

[aav]

Actually adding some random element in the timestamp might not be a very good idea. There are a couple of reasons: you still have to implement the TCP stack, as specified by IEEE. In the paper was said that this limits your variance to 1s. The addition of a random variable to another random variable can be reverse engineered. The algorithm of generating the timestamp would become terribly complex.

Possible, but quite complex.

I like the following solution somewhat better: do exactly what this guy is doing, and collect time skews from some machine elsewhere. Using several measurements extrapolate a timestamp, then use it for your own packets. Cycle through skews obtained from several machines, if you'd like...
This kind of code could be equally complex, though.

Re:read the paper

[A beautiful mind]

There is a difference between NTP and NTPD.

Re:read the paper

[JohnyDog]

There's fundamental difference between syncing your time through NTP once in a while and running NTPd which first measures skew of your local clock and then constantly adjusts to it.

Re:read the paper

[jp10558]

Although I submit that if sufficentally motivated, an average slashdotter could find out how to solder things.

Re:read the paper

[willCode4Beer.com]

Yes,
N - Network
T - Time
P - Protocol

N - Network
T - Time
P - Protocol
D - Daemon

One uses the other.

How it works

[jagilbertvt]

Just to set the record straight. The clock skew referred to in the article would be the amount of time the clock WILL lose or gain over a given period of time. you could receive say 1 packet a second for 30 seconds from one machine, and judge the amount of time lost or gained, and come up w/ an avg percentage of time lost or gained. So, say a machine loses 3ms every 5 seconds. You could then match that number to a list of machines you have already fingerprinted.

Alot of people seem to think it is referring to the amount of time the clock is actually off from the current time, which really has no bearing on this. The only way ntp would effect this is if it updated the machine time while you were in the middle of processing packets from the machine. Obviously, you'd be able to see this happen in the packets and then start over.

Frequency Changing CPUs

[EduardoFonseca]

What about mobile CPUs that keeps changing frequency according to system load?

My guess is that the clock skew would change as well.

patch for piracy

[willCode4Beer.com]

If done, then a firewall patch would allow everyone behind the firewall to get free activation. Of course, corporations don't pirate software from each other ;) Proxy servers are another reason not to use this for activation. None of the original machines TCP info is used on a proxied request, as these function much differently than a firewall or NAT.

Re:patch for piracy

[willCode4Beer.com]

Or as some companies do:

if lastDateMoneyReceived today-30
nag
if notMeetingRevenueForTheQuarter
nag
if boatPaymentDue
nag ...

Differnet from nmap's timestamping?

[crush]

From the I Didn't Understand The Article department: Nmap and checkos have enabled investigating timestamps for years (at least 1998 IIRC?). So, how is this different? I'm guessing it's to do with the "passive" nature of the detection, the fingerprinter has to be either a man-in-the-middle ISP/NSA or else the terminator of the connection? Would a firewall rule which rewrites all the packets to have a randomized deviation from an NTP derived timestamp overcome this? That'd seem like the simplest solution if it's true.

Thanks for the warning

[tuxlove]

Now we just need to implement TCP clock skew randomization to make this go away.

Already been done.

[XorNand]

Computrace, amongst others.

Re:Already been done.

[mikiN]

That seems to be a software solution. I doubt that any serious crook worth his salt would just take his freshly stolen laptop, hook it up to the 'net and start surfing about.
For a solution to be anything worth mentioning, it should be a hardware solution. And I don't mean just some PC Card or USB dongle, it should be right there in the silicon of the NIC(s).
Have the network device periodically send out packets with identifying info to tracking servers (details of which are stored on on-chip PROM) and there will be a reasonable chance of getting back your treasured gadget.

Re:If you turn it off, you stand out too.

[barawn]

I realize it wouldn't ONLY be you, but in a small subset (internet cafe, or whatnot), it could be an even bigger red flag. Hell, they might use that to say, "watch this stream carefully, he cares that we're watching him."

You're missing the point. Use a Linux box as a NATing gateway. Turn off timestamps.

Poof. All of the computers behind that gateway no longer have timestamps.

Once you can't get through a gateway anymore, anonymity comes back in a big way.

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

[lorenc]

Actually, this is probably not correct. They are measuring the skew from packet to packet. You could never reset your system enough times to prevent the measurement. However, there are 2 easy ways to defeat this: Software: Modify the TCP stack to intentionally create timestamp statistics that change. You would not want to make every timestamp skewed random or p-random as that would be a thumbprint too. You would want use a random skew for some 'n' number of packets and then change to another random skew. This would prevent someone from compiling enough statics to characterize the machine. Hardware: Implement a man-in-the-middle hardware box that takes all incoming packets, then only change the timestamp. You would use an algorithm like the software above ... but it would protect any machine. In fact ... if I design one .. will anyone buy it from me?!!!

Re:Atomic Cocks

[lorenc]

Not true. Check this article: http://www.cnn.com/2004/TECH/10/14/atomic.clock/ December 22, 2004 current estimate of quantity production is $100, and the device is brand new and not commercially available. Most time sources with adequate jitter control at processor frequencies are over $2500. It is not the average time base accuracy anyway ... it is jitter and skew - not quite the same thing.. PS .. I am involved in designs that involve these issues... We actually have a GPS timebase in the lab right now - it has 90ns skew over a 1Hz tick - it's about $2500 new.

Re:Atomic Cocks

[wembley]

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

Re:Atomic Cocks

[lorenc]

Which poster are you refering too .. the top parent?

Re:Atomic Cocks

[wembley]

Which poster are you refering too .. the top parent?

To whoever butchered the subject line.

It's the drift, not the time (if I understand it)

[blueZ3]

Say your clock drifts .000023MS per second. So between 1:00:00 and 1:00:01 there's a .000023MS difference.

You reset the time by three seconds, to 1:00:04. But it's going to have that same .000023MS drift between 1:00:04 and 1:00:05. So it can still be identified even if you cahnge the clock.

Al CAIDA?

[Junior J. Junior III]

All your caida are belong to us.

You have no chance to survive make your time.

Always cool...

[meese]

I don't know if you noticed, but he has a history of breaking, oh, WinZip, Diebold voting machines, and SSH.

Great!

[bblazer]

Now my wife can find me easier...

Way around it...

[Transcendent]

Integrate a TCP packet scrubber in which the time stamp seconds digit is somewhat randomized (perhaps just randomize the decimal of the second, and maybe even the seconds digit within 1).

It may be possible to still track a single computer, but this would probably be effective to put on a NAT firewall to hide the number of connections behind it.

Or, just disable the time stamp in the TCP stack... it's optional anyway.

Anyway, I thought the mac address stayed in the TCP packet? Maybe I didn't pay enough attention in CISCO class...

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.

fingerprinting on the net?

[g00n]

Didn't intel give us the ability to identify an individual pc on the net by it's processor ID?

Standard practice for MOST people that know about this is to turn it off, and I'm not sure if this "feature" has been removed the p4's. But it is present in all p3's.

With that activated, an API of the OS can ask the proc for it's ID and include it in online transactions, letting you say that wasn't me my procID is XXXXXXXXXXXXXXXX not YYYYYYYYYYYYYY..

any other clock drift, or any network characteristics can be forged. The proc ID can be as well, but if they're targetting someone specific. The attacker would have to learn that procID and then use it.

Of course, i could be completely mistaken. But that doesn't happen often.

How to disable in Windows 98

[Anonymous Coward]

Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\VxD\MSTCP
Value Name: Tcp1323Opts
Value Type: String Value
Value Data: 1
Details: The possible settings are 0 - No Windowscaling and Timestamp Options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options. The value is documented in RFC 1323. According to Microsoft, Tcp1323Opts should be a DWORD, rather than a string value, however seems that the documentation is incorrect and a string value is necessary to enable large RWIN support.

http://www.wisenetworks.net/tweaks.html

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.

Uh...thanks asshole...

[IronChefMorimoto]

I'd like to personally thank the jerk who came up with this idea (get a Ph.D by curing cancer for Christ's sake!).

Now I gotta buy a new computer every time my wife figures out which unique PC I'm using when I'm surfing the 'net at my mistress' house.

IronChefMorimoto

P.S. - I'm screwing with your mind -- /.'ers barely have wives let alone mistresses.

Re:Wouldn't it be easier

[fmobus]

Almost the same with me... We bought 10 PCs for our lab and two of them kept crashing when connected to the lan in some situations (more specifically when we tried to play our friday's Warcraft). It took us bloody two weeks to figure out they have identical MAC addresses. The most unbelievable/unstatistic detail: they were NEXT to each other.

I guess I'm going to have to stop using Kazaa

[djfatbody]

I am using Anonymizer and other proxies to hide myself as I "borrow" music. ;) I can imagine that the RIAA and MPAA would invest heavily to do a better job of tracking who has their content and who is downloading it.

Re:Wouldn't it be easier

[vyrus128]

I can beat that. On Carnegie Mellon University's wireless network:

[user@host ~]$ netstat -rn
Routing tables

Internet:
Destination.. Gateway.......... Flags Refs Use Netif Expire
default..... . 128.237.224.1.... UGSc. 99.. 5... en1..
128.237.224.1 de:ad:de:ad:be:ef UHLW. 95.. 0... en1.. 1200

Somebody was having fun with a network card. (Sorry about the crap formatting, how hard must they make it to paste program output?)

where's your search warrant

[pintpusher]

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.

and

without the fingerprinted device's known cooperation

sort of require a search warrant don't they?

IANAL, but seems to me that forcing your computer to do something other than what you've directed it to do (like forcing a timestamp you've turned off) without your persmission would be B&E. Unless you explicitly gave permission in the form of agreeing to a EULA or such.

Yet another reason to read the fine-print. You may inadvertently give persmission to allow this sort of privacy invasion.

I propose a new constitutional (for the US) amendment -- The congress shall not make any law that compromises the ANONYMITY of a citizen unless the citizen shall explicitly and intentionally give up that anonymity. In other words, unless I tell you who I am, you can't know who I am.

that and a dime 'll get you a dime.

Re:where's your search warrant

[m50d]

Not really - the machines were prepared to do it as a fallback, something which can be disabled if you really want to. No worse than what IE does to hundreds of web servers daily.

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.

Kernel patch?

[La Camiseta]

How long before someone releases a kernel patch that randomises the time offset of all TCP packets sent from a computer?

Impressive is Right

[serutan]

this is a more impressive (and unique) way of looking at the problem

You got that right! Regardless of the possible sinister big-brother applications, didn't we all read this and deep down think Whoa, that's pretty damn cool! I know I did. This guy deserves major uber-geek points. /golf clap

Re:Impressive is Right

[bbuR_bbuB]

I didn't, because it's not really something that will be of any use at all. I thought 'wow, this guy thinks he's smart. let me list the ways that this wouldn't work:'...

1. Change the CMOS battery! That will surely change the jitter, which then changes your 'signature'.
2. Play with the system clock!
3. Rewrite packets so that the timestamp is slightly different!

Need I go on? Seriously, this isn't anything exciting. Whenever you're relying on a remote resource for some sort of information, it's nearly impossible to reliably validate that information without some sort of additional information (crypto, CRC, whatever).

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:Simple question: Why?

[Reziac]

As you imply, one way to make Powerful Folks' heads whip around is when it Happens To Them. Maybe some enterprising techie could apply these tracking techniques to certain Powerful Folks, and make the data public. After all, if our lives are no longer private, why should theirs be??

What's sauce for the goose is sauce for the gander...

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:Firewalls?

[ebyrob]

Ya, and communication requires responding to TCP packets too. So, by your logic, it shouldn't be possible to communicate through a firewall either...

Of course, if you change your ...*and* used connections initiated by the clients... to ...*or* used connections initiated by the clients... it would make a lot more sense. In this case, a packet trace of clients connecting to random servers out on the internet taken at, say, their ISP's router, would work wonders.

Example 1: You're a Comcast cable-modem customer and Comcast wants to know if you use NAT. So, comcast installs 1 new tool on the router you use to get onto their network and viola, they can get your clock skews down to an extremely accurate number. (And consequently count the number of machines behind your NAT'ing firewall.)

Example 2: You're a pir8 arrrr and you hook to a usenet server to download your favorite b00t13. But, the ISP providing access to the server has had complaints and wants to lock things down, so they've installed 1 new tool on the router providing internet access to the usenet server. You connect and download a broken up copy of "The Matrix" and the router in question is able to estimate your clock-skew down to .56 ppm. Combine that with your IP, and a trace-back to your ISP, and you could be sunk...

Why does this whole thing remind me of Milliken oil-drop experiments?

NTP?

[anno1602]

Doesn't xntpd adjust the system clock's drift to most closely match the real time? Wouldn't this completely kill the entire idea?

ignore this post

[damnnicks]

posting to kill a bad moderation I made...

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.

Re:Can I ask a dumb question?

[siliconjunkie]

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

Here's one reason, here's another. Furthermore, even my consumer Linksys router has MAC spoofing features to make it easier to connect to ISP that register your MAC address.

Re:Can I ask a dumb question?

[zygote]

Okay, this might be a dumb answer, but can't you pretty easily spoof that? I don't know about NIC, but routers can be cloned with any MAC.

Easy

[stratjakt]

Randomly adjust your RTC by a few millisecs every 30 seconds or so, or have your edge router (NAT box) mangle the timestamps.

OT Note to comcast and other ISPs: I am not violating anything in your usage policy by running my own nat. I do not want third third rate router you offer for "home networking".

Go ahead and try and employ these types of douchey tricks to "catch" me doing something that's perfectly acceptable to you (using my cable connection for my personal use, and that of my immediate families). All that'll happen is Speakeasy will get a new customer.

It's been done. What's the big deal?

[default luser]

The military has been doing this sort of concept for years, except with electromagnetic radiation.

The technique is called Specific Emitter Identification (SEI), and it's used to create a unique fingerprint of the signal characteristics of every known radar platform in the world.

And I'm not just talking about a fingerprint by model...we're talking a unique fingerprint for every individual radar in existence, all available in a managed database.

Of course, the enemy has no expectation of privacy if they broadcast radar waves, and honestly, neither do home users who connect to the open net.

If you want to fake out the SEI database, you either never transmit, EVER, or you tune or replace the radar. If you want to fake out this system, you don't connect to the net...or you tune or replace the processor. It's much like dodging cookies and such: it's perfectly possible to avoid being tracked by them, but it's on your shoulders to do so.

But it actually happened!

[mcrbids]

It's funny, but what you suggest
really happened with a Novell server over a 4-year period at the University of North Carolina...

Is there some other reference to your apartment I'm missing?

An absolutely useless technique.

[ExtraT]

Some people mentioned running NTP to eliminate the skew, but I say you wouldn't even need that. Computers are complex electronic devices and just because your CPU has 1.6 Ghz written on it doesn't mean it runs exactly at 1.6 Ghz. The frequencies vary with time and are influenced by any number of things, starting from the power grid and ending with your neighbor's powerful sneeze.
Laptops are even worse. different battery charge, moving from one power grid to another. And what about frequency scaling? Can you imagine the havoc this technology wreaks on your clock skew?

In short, this technique will never work outside of the lab. Back to the drawing board, assholes! :)

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

[jfdawes]

Essentially this technique relies on no-one fixing clock skew.

Your clock is supposed to be accurate. A clock with a skew is [in some degree] broken. If this guy can measure the skew rate of your clock, then you should be able to measure it too, and automatically correct for it - reducing the skew rate to a value very close to 0.

How many bits of entropy does that have?

Re:entropy

[Directrix1]

Yeah, and this is done quite simply with the NTP daemon.

Re:entropy

[jp10558]

Is that enough to legally identify some computer though? I mean, there are likely 100 million computers in the USA alone, not to mention another 100 million "computer like devices" such as cellphones or Xboxes.

If you are trying to track someone who is moving around the net, wouldn't that indicate you could likely have 200 distinct devices that would look the same to this?

Re:entropy

[ebyrob]

If you read the abstract of the paper...

...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 iva NTP or SNTP...

This doesn't help. (Not to say "skew correction" is not possible, just that it's part of the escalating arms race.)

Re:entropy

[ebyrob]

I'm confused by this too. I just checked the paper and it does use the term "bits" to refer to the amount of entropy.

Maybe someone can translate this jargon for us? It looks like we go from 4.87 bits at 0 bytes per hour (for 10 minutes of the hour?) to 6.41 at 2000 packets per hour (for 50 minutes of the hour?).

2^4.87 = 29.2 distinct values
2^6.41 = 85.0 distinct values

But err, those numbers seem awful low considering all the excitement over this method... What are we missing?

Re:entropy

[djtack]

don't you mean 1 computer in 64?
oops, you are right, I don't know why I was thinking 10**6.

Easily defeated.

[raider_red]

This kind of reminds me of the ballistic fingerprinting systems that are being pushed for by some gun-control groups. They all rely on some way of cataloging the physical marks left on a cartridge case (and sometime a bullet) when fired by a particular firearm.

The problem is that they are first, not very effective, and second, very easy to defeat. They are unreliable because an attempt to identify an arbitrary shell casing will cause the system to spit out several hundred potential matches. With guns made to exacting quality control standars, it can produce thousands of potentials. It's easy to defeat because the markings used are all produced by parts of a gun which are very easily replaced. All one has to do change the ballistic signature is swap out the extractor, firing pin, and barrel of the weapon.

Something similar could probably be done here. One could swap out the oscillator crystals, change a few key capacitors to introduce timing variations, or even raise the temperature of a key component, and you'll have a different clock signature.

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

Re:This is incredibly accurate

[Reziac]

What are your thoughts about how spoofable it might be, say with a firewall *designed* to produce "random skew" ??

You mentioned Comcast... I can see nasty ISPs using this to tie service to a single computer, and forcing folk to pay extra if they have more than one machine connected.

Re:This is incredibly accurate

[ebyrob]

Okay. So they can get within .56 ppm of your actual clock skew. What's the standard deviation of skew for these components? (ie: I'm trying to figure out the likelihood that two machines with "matching" standard deviations, as measured by this test, are not actually the same machine. 1/64? 1/1000? 1/1000000?)

Re:This is incredibly accurate

[ebyrob]

So say 100 is 1 standard deviation (going by the graph in that paper). Then there would be about 800 distinct values that fall within the most common 95% of clock values.

So odds are somewhere between 1/500 and 1/1000 that any random two computers are indistinguishable. Certiainly useful, but by no means conclusive.

Let me guess ..

[apankrat]

It is a Novell server :)

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.

Exactly

[apankrat]

net/tcp.h

static inline void tcp_syn_build_options(__u32 *ptr, ...)
{
...
- *ptr++ = htonl(tstamp); /* TSVAL */
+ *ptr++ = htonl(tstamp) + jitter(); /* correlate this :) */
...
}

So the real questions are...

[sharper56]

... what real apps actually use the TSpot info?

... why are optional pieces of protocols leaking system info by default.

(And as required by ./, the MS dig)
... why is MS allowing incoming packet options to violate RFCs and change system security performance?

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

Tracking ...

[Salus Victus]

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.

Hmph ... now there's an interesting thought: "Low-jack" software for portables that automatically connects to a central security service whenever the computer is connected to the Internet. Somebody steals your laptop, you report it stolen to the service, and the system calls the cops if the thieves try to use it without wiping the hard drive.

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.

Universal skew reference? Nope.

[zhvihti]

If each computer has unique skew how are they going to establish a common time reference standard? You can't have one phisycal machine sniff the whole net. Having a few however, would mean that the skew they measure is based on their perception of time, which is (as per definition) uniquely skewed. Now, if they can sync many machines completely, then we can basically do the same.

Spoofing it??

[Reziac]

Someone above mentioned that the numbers indicate it should be accurate enough "to uniquely identify 1 computer in a million". Given that, combined with other identifiable info it should be enough to get a hard ID.

However, I'm wondering how easy it might be to spoof, such as with a firewall *designed* to produce random skew. Thoughts, anyone??

Re:Fingerprinting Random add and subtract

[B'Trey]

Has problems.

Does it?

Over time add and subtract will average let person still see the infomation they want. Just it will take longer.

The above is predicated on having long term samples to analyze. But if they can identify your machine over a long time to gather samples, then they don't need this technique in the first place. The whole point is to identify a machine which is moving around, connecting through multiple netwokrs or otherwise taking actions which, intentionally or not, work to obscure their identity.

The one use that they mentioned where this might not apply was identifying the number of machines behind a NAT connection, but that should be trivially defeated by having the NAT machine re-timestamp each packet. All connections would show the timeskew of the NAT server.

There are, of course, other cases where it might come in handy. For example, you could likely show that a laptop that a user caries from home to work and back on the daily basis is the same machine, even though it has different IPs in the two locations. But this is a much narrower use. A criminal who connects via wireless at various Starbucks Cafe's for short periods of time probably won't leave enough of a trail for this technique to work if he's taking precautions against it like adding random offsets to his time.

Having thought a bit about it ..

[apankrat]

static inline void tcp_syn_build_options(__u32 *ptr, ...)
{
...
- *ptr++ = htonl(tstamp); /* TSVAL */
+ *ptr++ = htonl(tstamp) + skew(jiffies);
...
}

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

More like blood typing than a fingerprint

[sesquipedalian_one]

If you read the whole FA that you linked, you'll find that the authors aren't claiming they can uniquely identify any computer on the net with this technique. In fact, they specifically disavow it (p. 13 of the PDF):

"For forensics, we anticipate that our techniques will be most useful when arguing that a given device what not involved in the recorded event. With respect to tracking individual devices, we stress that our techniques do not provide unique serial numbers for devices, but that our skew estimates do provide valuable bits of information that, when combined with other sorts of information such as operating system fingerprinting results, can help track individual devices on the internet."

So it's a bit less precise than a fingerprint or DNA testing. It would be nice to know how much less precise. The number of computers they tested was rather small.

Erm, Why not just use software clock?

[jedimark]

Sync the software to hardware clock at boot time, and update the software clock in a low level interrupt. With a few subtle little variances worked in, and balances out a few seconds later.

I thought most OS's did most of that already (apart from the subtle variance bit)?

As far as NAT goes, why not b0rk the timestamps a bit on the packets? I'm no networking guru, but someone will come up with something soon enough to stop this.

Sure it's handy to have as evidence, but what can be used to solve crimes can also be used to carry out crimes.

Two words

[sanermind]

man adjtimex ...under linux, it would be trivial to change your skew slightly each time you attach to the network

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:NTP doesn't help - Actually, it can. - quotes

[fhage]

Yes, the authors keep repeating it, but if you read carefully, they specifically excluded "professional configurations" and their methods only work on "typical user" configuations. NTP doesn't help if you only sync only at boot or like XP pro; once a week!. They break this news on page 2 and then are more specific on page 4:

[pg 4] Although the system clocks on professionally administered machines are often approximately synchronized with true time via NTP [19] or, less accurately, via SNTP [18], we stress that it is much less likely for the system clocks on non-professionally managed machines to be externally synchronized. This lack of synchronization is because the default installations of most of the popular operating systems that we tested do not synchronize the hosts' system clocks with true time or, if they do, they do so only infrequently. 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 .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-professionally-administered 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.

GPS Atomic clock sync'd, 1 usec clock accuracy can now be had for less than $100. (ntpd + Garmin GPS 18 w/PPS). I've done it with the Garmin GPS 16. Works like a charm when the antenna has a clear view of the sky. Put one of these on a PC on your LAN and all your hosts will skew less than they can measure.

Re:Wouldn't it be easier

[conteXXt]

There is a simple explanation for this

Openvpn + bridge How-to

The examples given use the de:ad:be:ef mac for the bridge.

Funny to see it out there though.

(and the output stuff? use tags. )

I don't think it works that way...

[hains]

Here's how I think it works. Other folks who have read the paper please correct me if I am wrong.

Clock skew is the disparity between your clock value and some reference time value (probably the clock of the measuring machine. This disparity grows over time, and the rate of growth of this disparity is the difference between the rate of the measured system's clock ticks and the rate of the clock of the reference system's clock ticks. If you are going to do this "officially", your reference time should be an atomic clock instead of the rate of the measuring machine.

Thus the characteristic fingerprint that we want to measure is the rate, or frequency, of the clock on the measured machine -- or more precisely, its difference from some reference value. What we can measure are

• S1, S2 = The clock skew at two points in time
• DT = The time between the two observations.

The clock frequency error is then calculated as

fingerprint = clock frequency error = (S2 - S1) / DT

This approach has a number of consequences:

• The longer you measure, the greater the number of bits of precision that you get in your measurement.
• More bits of precision mean that you can tell more machines apart. To identify one machine on the entire internet requires many bits of accuracy. To identify one machine on a LAN requires very few.
• Long measurements can be defeated by periodically resetting your clock. Rebooting, running NTFS, or manually setting your clock does this.
• Short measurements can be defeated by heating or cooling your machine, which affects the operation of the oscillator used by the clock.
• Swapping out the clock oscillator will change the fingerprint of your machine, but it may not be easy to do.

I hope this helps.

John

just bookmarking

[Spetiam]

for future reference

I'll believe this when I see it!

[UK Boz]

So what machine, OS, IP address etc have I sent this reply from ???????? Or is this bulls*** Boz

Go right through Falken's Maze

[TanRanger]

I believe there is a clue to how to defeat these attacks burried in the report.

The researchers only included one laptop in their study and yet laptops are arguably the most interesting targets to try to track. It is due to their portability that they are attractive to those desiring to stay anonymous. I find it interesting that among more than 70 devices they studied, only one was a laptop.

I also think they have paid less attention to this laptop than they should have:

"When booting with outlet power, the clock skew on laptop running Windows XP initially begins with a large magnitude, and then stabilizes to a skew like that in Table 5 until we disconnect the power; the initially large skew may be due to the laptop recharging its batteries."

What this suggests to me is that the voltage supplied to the oscillator may alter the clock skew. In fact, I wouldn't be surprised if overclocking or underclocking a desktop PC also changes the skew. Changing core and RAM voltages might also modify the skew. They should have researched these possibilites.

I have seen little mention here of another type of attack they describe which is independent of the TCP skew. The Fourier transform attack is scarier than they let on:

"...[O]ur Fourier-based technique does not require knowledge of a device's TSopt or system clocks..."

"Some systems send packet [sic] at 10 or 100 ms intervals, perhaps due to interrupt processing or other internal operating system feature [sic] on one side of a flow. When this condition holds, we can use the Fourier transform to extract information about the system's clock skew."

"...[W]e can use the Fourier transform on packet arrival times to estimate the frequency at which the device actually transmits packets (here packet arrival times refers to the times at which the monitor records the packets)."

What this says is that even if you're running a modified TCP stack and are filtering out ICMP requests, attackers may still be able to find out your skew.

I anxiously await the results of research on skew modulation techniques.