Slashdot Mirror
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."
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
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
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: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.
Its not users who are broken, it's systems not taking account their likely behaviour and fixing it technically.
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?
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
(S(SKK)(SKK))(S(SKK)(SKK))
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)
News Reporters Make Tasty Polar Bear Treats!
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.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
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.
akad0nric0
This sentence no verb.
How about rigging my TCP stack to add/subtract a random number to the timestamp in my headers?
I want a new world. I think this one is broken.
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...
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.