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

27 of 470 comments (clear)

  1. Paper and technical details are here: by JohnGrahamCumming · · Score: 5, Informative

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

    John.

    1. Re:Paper and technical details are here: by peacefinder · · Score: 2, Informative

      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.

      --
      With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
  2. Can't you turn this off on Linux? by Anonymous Coward · · Score: 5, Informative

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

    1. Re:Can't you turn this off on Linux? by demi · · Score: 4, Informative

      I believe so, and on OpenBSD:

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

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

      --
      demi
  3. Ok. by Anonymous Coward · · Score: 1, Informative

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

  4. What about IBM's laptop anti theft stuff by varmittang · · Score: 3, Informative

    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-----
  5. Re:Wouldn't it be easier by conteXXt · · Score: 2, Informative

    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 /. (Karma suicide ensues)
  6. Re:Wouldn't it be easier by Anonymous Coward · · Score: 1, Informative

    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.

  7. Re:Sceptical by jerdenn · · Score: 4, Informative

    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.

  8. Doesn't work that way by V.+Mole · · Score: 4, Informative

    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.

  9. Re:for windows user by demi · · Score: 3, Informative

    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
  10. Re:This can be good... by Rei · · Score: 2, Informative

    ... 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'.
  11. Re:Wouldn't it be easier by conteXXt · · Score: 2, Informative
    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
    --
    The truth about Led Zep should never be told on /. (Karma suicide ensues)
  12. Re:Fingerprinting by harrkev · · Score: 5, Informative

    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."
  13. NTP doesn't help by demi · · Score: 4, Informative

    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
  14. Re:This can be good... by gl4ss · · Score: 2, Informative

    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.
  15. Re:Fingerprinting by harrkev · · Score: 4, Informative

    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."
  16. How to disable in Windows 98 by Anonymous Coward · · Score: 1, Informative

    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

  17. Re:Sceptical by jerdenn · · Score: 2, Informative

    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.

  18. Re:OpenBSD by eggnet · · Score: 2, Informative

    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.

  19. Re:Way around it... by rosie_bhjp · · Score: 2, Informative

    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
  20. entropy by djtack · · Score: 3, Informative

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

  21. This is incredibly accurate by IASmaster · · Score: 4, Informative

    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

    --
    There's no place like ~/
  22. 7 bits of identification/entropy by dahin · · Score: 2, Informative

    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.

  23. Re:Fingerprinting by flok · · Score: 2, Informative

    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
  24. Not how it works by JohnBaleshiski · · Score: 2, Informative

    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.

  25. Re:Skeptical by daremonai · · Score: 2, Informative

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