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

Paper and technical details are here:

[JohnGrahamCumming]

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

John.

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

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.

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

Doesn't work that way

[V. Mole]

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

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

Re:for windows user

[demi]

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

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

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.

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

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 [wisenetworks.net]

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

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.

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

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 [caida.org]. The full 15-page text is available in PDF. [caida.org]

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

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

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

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

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

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

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

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

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

7 bits of identification/entropy

[dahin]

The paper http://www.cse.ucsd.edu/users/tkohno/papers/PDF/ [ucsd.edu] 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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Not how it works

[JohnBaleshiski]

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

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

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

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