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."
http://www.cse.ucsd.edu/users/tkohno/papers/PDF/
John.
Can't you turn this off on Linux with /proc/sys/net/ipv4/tcp_timestamps
echo 0 >
> 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.
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
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
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.
The truth about Led Zep should never be told on
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.
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.
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.
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.
demi
... 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.
Clean coal harnesses the awesome power of the word 'clean'.
The truth about Led Zep should never be told on
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.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
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.
demi
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.
world was created 5 seconds before this post as it is.
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.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
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
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.
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.
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.
A radio maverick jumps to internet only. The Future of Rock n Roll
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).
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)
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.
Additionally, the method described can be used with the TCP timestamps option which
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
There's no place like ~/
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.
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)
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
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.
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....