Forgot your password?
typodupeerror
Privacy Your Rights Online Technology

Computer's Heat May Unmask Anonymized PCs 146

Posted by Zonk
from the i-seee-you dept.
Virtual_Raider writes "Wired is carrying a story about a method developed by security researchers to identify computers hiding behind anonymity services. From the article: 'His victim is the Onion Router, or "Tor" — a sophisticated privacy system that lets users surf the web anonymously. Tor encrypts a user's traffic, and bounces it through multiple servers, so the final destination doesn't know where it came from. Murdoch set up a Tor network at Cambridge to test his technique, which works like this: If an attacker wants to learn the IP address of a hidden server on the Tor network, he'll suddenly request something difficult or intensive from that server. The added load will cause it to warm up.'"
This discussion has been archived. No new comments can be posted.

Computer's Heat May Unmask Anonymized PCs

Comments Filter:
  • by Anonymous Coward
  • by Mr. Flibble (12943) on Saturday December 30, 2006 @01:57AM (#17406964) Homepage
    The temp increase is the method to cause the clock to skew as the chip heats up due to added server load. The heat itself is not detected, so the summary is very misleading. The idea is to load the server enough so that the timestamps begin to change, and these changes can be detected.

    Of course, the defense to this attack is probably something along the lines of:

    $ man nice
    • by jd (1658) <imipak@nOSPam.yahoo.com> on Saturday December 30, 2006 @03:17AM (#17407298) Homepage Journal
      There are several defenses.
      • First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.
      • Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time, so the drift will be entirely absorbed through the loss of accuracy.
      • Third, a defender worried about such an attack would use an oven-controlled oscillator for the clock, which means the temperature is whatever you want it to be. You can deliberately vary it to produce errors, or compensate for external temperature changes. Either way, you can be quite invisible to this method.
      • Fourth, the TOR network should be using an external time source (eg: NTP) that is not included in the TOR tunnel - ie: it's out-of-band - which means that the computers can automagically correct drift. If the computers are REALLY good, they'd correct drift on a second-order or third-order basis, rather than as a constant, so that you adapt how you read the clock to the shift in drift.


      The idea of using some sort of timing attack against such a network is interesting. There are probably better methods, though.


      One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.


      (Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)

      • by sjmurdoch (193425)

        First, if the computer is sensibly cooled (ie: not by convection currents) then heating will be minimal.

        The computers I tested it with were normal desktop machines. They all had fans, and in some cases were thermostatically controlled. The differences in temperature were only 1–2 C, but that could be remotely detected.

        Second, if you use a high-precision clock-chip, the chip will be tens or hundreds of times more accurate than the system time

        An oven-controlled crystal might be accurate enough (<1pp

        • by Gordonjcp (186804)
          Let me know if you want to try it with an oven-controlled clock. I'm sure I can sort out something that will hold a reasonably steady temperature (better than free-space at least).
      • by arevos (659374)

        One idea that springs to mind is that such P2P systems use caches. If you could generate enough requests to flood the cache system, you can force any computer to query nearby computers, where the latency will be roughly equal to the number of hops along the critical path. It then becomes similar to the game of "Black Box", where you try to map particles by throwing rays in and seeing what happens. If you have a sufficiently large latency map from a sufficiently large number of entrance points, you should be able to derive the whole of the exposed topology of the P2P network and be able to identify which of those servers carry what data.

        Nice idea, but it wouldn't work on Tor. The topology of the router network depends on who is using it, as routing paths are decided by the machines using the Tor network to remain anonymous, not by the routers themselves. In the case of a hidden service on Tor, a directory server is used to associate a .onion TLD with several routing paths the clients can use to contact to the server. Little information can be derived from the routing paths themselves, as the address of each router in the sequence is encr

        • by jd (1658)
          Probing a theoretically ideal anonymous P2P network can be done if certain conditions are met. Step through the following and see what you think.
          1. If you connect to each and every R in the set of R' (the total number of edge-connected nodes in the network) and cache-flood prior to making your standard test query, and repeat the process R'/3 times, then the mean value of M over all these tests will be the maximum possible radius of the topology. It doesn't matter what test query you use or where in the topol
          • by arevos (659374)

            There will be exactly one minimal fit for these conditions and this will be the topology of the network.

            This won't work on Tor, for three reasons. First, there is no overall network topology. The routers merely act on routing instructions passed onto them via the client; they don't make connections autonomously, like, for instance, the nodes in a Gnutella network would do. Second, the hidden servers are not actually part of the Tor network; the routers merely act as middle men, stopping direct communication between the server and the client. Thirdly, I'm not aware of any caching that goes on between router

            • by jd (1658)
              Ok, fairy nuff. In which case, I have to confess I'm out of ideas.

              You don't need to know every complete path, so the number of possible permutations is something you can work around. Think of the tables used by the nudes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables.

              • by arevos (659374)

                Think of the tables used by the nodes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables.

                I don't think that's quite right. If there are 3 pieces of data encrypted with three different keys, then knowing what one of those pieces of information is doesn't necessarily help figure out what the other two pieces are.

                Tor is pleasingly clever in the way it goes about ensuring anonymity. Each router in the Tor network publishes its IP address and public key on a directory server. The client picks a random sequence of router addresses, R1 to RN, and corresponding public keys, P1 to PN. It then encrypts

      • by Instine (963303)
        "(Think about it. Those of us in Open Source have all done reverse engineering, we have all tried to wrest the secrets of some black box we can't see the inside of, and eventually we have all succeeded in doing so. Our interpretation may not 100% match the internals literally, but they WILL 100% match the internals logically. And in the end, that's all that matters.)"

        In many ways I agree, but literal != logical. If I spoof the behaviour you look for, I could 'frame' another server for my processes. Log
      • by pla (258480)
        There are several defenses.

        You forgot the simplest one that will defeat all attempts at timestamp fingerprinting...

        Lie about the time. As long as it monotonically increases between packets, and stays within a few seconds of accurate, everything goes smoothly (for most general-purpose data traffic - Obviously this would completely screw up something like an NTP query).
        • by jd (1658)
          Lying about the time works to a degree, but you can only lie in a positive direction. Eventually, with enough tries, it may be possible to figure out that there is a value you NEVER go below. That is the maximum the real time can be. If it's too much below that, however, anything that is time-order dependent risks getting screwed up.

          Now, this isn't to say you can't seriously screw with the network's perception of time. For example, you could channel bond multiple VPN connections into a single super-VPN co

  • by Mal Reynolds (676267) <Michael_stev80@@@hotmail...com> on Saturday December 30, 2006 @02:00AM (#17406982)
    Randomizing the clock of systems serving Tor traffic would render this attack worthless.

    Since this and other such attacks are based on analyzing very small changes in the target system clock, even a tiny amount of randomization or pseudo randomization would be effective.
    • Re: (Score:3, Informative)

      by Baricom (763970)
      Other potential solutions include preventing machines from reporting local time (through HTTP? - I'm not clear the attacker learns the time in the first place; neither TCP nor IP have time information in the headers, it seems) or preventing hidden servers from talking on the public Internet.

      For most hidden services, either should be feasible. Timing doesn't seem that important anyway, given the inherent latency of the Tor network.
      • It's probably easy for the "attacker" to note the time they "attack".
    • by whoever57 (658626)
      If I read this correctly, it requires the enclosure to heat up, since the clock oscillator is on the motherboard, not on the CPU. Thus, randomising fan speeds would have the same effect.

      Even if the clock oscillator were part of the CPU package, adding some random variation to the CPU cooler fan speed would defeat this.
    • by KermodeBear (738243) on Saturday December 30, 2006 @02:38AM (#17407170) Homepage
      What about always using 100% of your CPU? I run the BOINC [berkeley.edu] client for the Rosetta@HOME [bakerlab.org] project and tell it to crunch as much data as it can with idle CPU time. It is ALWAYS up and running. So, if I have this running on a machine that also uses Tor then the "create extra CPU load" method would fail.
      • Re: (Score:2, Insightful)

        by evilviper (135110)
        So, if I have this running on a machine that also uses Tor then the "create extra CPU load" method would fail.

        Not necessarily.

        If you have your CPU-intensive app running at a low priority, and TOR running at a higher priority, then your CPU will become slightly hotter when TOR is doing heavy processing.

        It may make it much harder to detect than it already is, but there you go.
        • Re: (Score:2, Insightful)

          by Anonymous Coward
          What has priority got to do with it?

          Why would heavy processing by TOR make the CPU run hotter than heavy processing by $SOME_APP ? It's still just heavy processing, CPU at 100% usage.
        • by Dion (10186)
          How?

          Please explain exactly how the CPU will know what priority the scheduler has assigned to a given process.

          A system with speedstep might turn up the clock rate when it sees that there is a high priority process wanting CPU, but that's not the norm.
          • by evilviper (135110)

            Please explain exactly how the CPU will know what priority the scheduler has assigned to a given process.

            I don't specifically know "how". What I do know is that it's a fact, and quite easy to demonstrate.

            Start a long-running CPU-intensive program (my preference is mencoder) at a low priority, and monitor the CPU tempurature. After you've given it plenty of time to cool down (a day or more if you like) start the program at the default or higher priority, and you'll see the tempurature is significantly high

            • by Dion (10186)
              Hmm, I wonder if that has something to do with the length of time slices for very nice processes?

              Did you do that test on a laptop?

              • by evilviper (135110)
                Did you do that test on a laptop?

                Not a laptop, nor a desktop with CnQ/SpeedStep...

                In fact it is a 4 year-old Athlon XP, in a motherboard that doesn't even support S2K.
    • Re: (Score:3, Insightful)

      by sjmurdoch (193425)
      Have a look at this blog posting [lightbluetouchpaper.org] for why adding random noise will not prevent the attack. Essentially, random noise doesn't change the average skew, since the computer doesn't have an independent reference clock. By taking a moving average over time, the noise can be detected and removed.
    • by instarx (615765)
      Randomizing the clock of systems serving Tor traffic would render this attack worthless.

      Since this and other such attacks are based on analyzing very small changes in the target system clock, even a tiny amount of randomization or pseudo randomization would be effective.


      Although it would certainly make it more difficult, it would not be an absolute defense against the identification of the PC. Identification of a PC that is using this defense may not occur in 30 seconds after a single challenge, but could
  • I'm changing my heatsink from copper to fiber...
  • I miss read the title the first time, the joke being I do heat my office with computers. I have three of them in the room and the 4800 dual core puts out a fair amount of heat on it's own keeping it toasty compared to the rest of the house. I used to have a dual 300 that got so hot you couldn't touch the side of the case. I literally put a box fan on that one to keep it running.
    • by Gordonjcp (186804)
      I have a PDP-11/73 [kicks-ass.net] that warms up the workshop quite nicely. I don't know why, but despite drawing around 400W (just the same as my PC) it throws out a lot more heat. Of course if you fire up the big RL02s it gets a lot noisier and the current draw goes up. Just the PDP-11 on its own is quieter than my PC, too, despite having four 5" fans.
    • I miss read the title the first time, the joke being I do heat my office with computers. I have three of them in the room and the 4800 dual core puts out a fair amount of heat on it's own keeping it toasty compared to the rest of the house. ...

      I did the same "back in the day" when I got my first personal Unix box - an Altos 68000 - one of crowd of generic Motorols 60x0 unix boxes that came out before PCs squeezed them out. With a meg of RAM and an 8" hard drive it put out enough heat to keep the computer r
  • April already? (Score:1, Offtopic)

    by daveb (4522)
    It's amazing how fast the year flies. It seems like Christmas was just this week and we're already at April 1.
  • utterly useless? (Score:4, Interesting)

    by pavera (320634) on Saturday December 30, 2006 @02:28AM (#17407116) Homepage Journal
    Ok, so if I am using Tor, presumably I've got clients behind these servers.... so according to the article, he can detect a server? What good does that do him? That doesn't identify *MY* machine the client which is actually doing the browsing. So, he can see which server is running Tor... couldn't he just portscan to find that out?
    • Re: (Score:2, Informative)

      by Anonymous Coward
      TFS mentioned "servers" and then jumped to "hidden servers".

      Hidden services are something different than a Tor user. A hidden server is reachable via some hostname in the .onion TLD and provides services like HTTP, just like in the non-Tor network. It's basically an anonymous server instead of an anonymous client.
  • by tlund (42064)
    More info on Murdochs talk can be found at the congress website [congress.ccc.de].
  • Apparently written by someone whom has never stepped in a well stocked data center before.
    • by dfoulger (1044592)
      Obviously someone who is unaware of the millions of machines that are routinely overheated by overload ... most machines running graphics intensive applications and all machines running BOINC. Bad thinking, but wishful thinking often is. Davis
  • Just run Folding 24/7, max out your CPU. Also, monitoring heat requires physical access to the server. Oh well, nice try though.
  • All the anonymised computers which heated up had Pentium 4s.
  • It looks to me like this can (somewhat) finger print a given machine but I sure don't see how it can discover an IP on TOR.
  • 1. Create a minor botnet
    2. DDoS a server, not enough to kill it but slow it down a lot
    3. Measure response times to hidden service
    4. If all requests using different paths now are slow, you got it

    Also, that attack scales to detect multiple hidden sites simultaniously - hit one server, request ten sites and see who answers quickly and not. It's just a consequence of depending on one machine. The only way you could totally avoid that is to not have services at all, only distributed datastore like e.g. Freenet.
  • Simple Defense (Score:5, Insightful)

    by Cbs228 (596164) on Saturday December 30, 2006 @06:06AM (#17407770)

    Since date and time information isn't included in TCP/IP packets, this kind of attack won't work for all services. Assuming that the "hidden servers" in question are HTTP servers, there is a rather simple workaround: simply disable sending the "Date" header. This can probably be accomplished with mod_headers [apache.org] in Apache, but I've never tried using it myself. Oddly enough, the server would still be standards compliant [w3.org]. Obviously, servers that leak the current time by some other means would still be vulnerable.

    A simpler, less precise attack of this nature would simply be to continuously ping the suspected server via both Tor and the public internet. If they (reproducibly) fail at the same time (and we could launch a denial-of-service attack to make it fail), they're probably the same machine. Attacks of this nature might even be able to confirm if a hidden server is on the same network as another computer.... But any of these attacks require someone to suspect you of running the server in the first place—and if they do, you probably have bigger problems to worry about.

    The bottom line is, as Tor's manual clearly indicates [eff.org], having a hidden server machine accessible from both Tor and the internet is a bad thing. Operators of hidden services should use a dedicated machine and block all incoming traffic (on all TCP and UDP ports) that is not via Tor.

    • by sjmurdoch (193425)
      Since date and time information isn't included in TCP/IP packets
      Actually, it is [ietf.org], and this what I mainly use, but initial sequence numbers also incorporate a timer. If both are unavailable, the link between packet emission and timer interrupts will still show up the clock skew.
  • If you leave a process running in the background consuming 100% of your cpu all the time, like setiathome or distributed.net, then your system won't get hotter, rather it will just be processing something else to load the cpu and still generating the same amount of heat.
  • What if there were a time sync server in the setup whose whole purpose in life is to keep track of the time?

    Have no other apps running on it, so that it has negligible system load. All the other systems in the TOR could be set up to sync their time with it every few seconds, i.e. before clock drift becomes detectable. Might check each and every second so as to intentionally cause a collision on the time server and add some randomness. Or, do a time sync every random(1..10) seconds. Or, use multiple NIC

  • by Terje Mathisen (128806) on Saturday December 30, 2006 @11:48AM (#17409466)
    This theoretical attack is based on using (previously covered on /.) clock skew to identify systems.

    The correct defense is the same as the last time:

    a) Make sure that there is no system clock skew, by running Network Time Protocol (NTP) on all servers.

    b) Make sure that all externally visible timestamps are based on the system clock.

    Part (b) is the only difficult step, since many current IP stacks use a private counter/clock instead of the system clock, presumably to reduce the overhead of providing timestamps. I know that Linus T have discussed using user-level library code to provide microsecond resolution (or better) timestamps, with very low overhead:

    The library code can just query the cpu/system timer, multiply by the current scale factor (which depends on things like dynamically variable cpu clock frequency), and add the base time which was stored by the OS on the last HW clock interrupt: Total runtime, including call/return overhead can be below 100 clock cycles, which is fast enough to use it everywhere timestamps are needed:

    BTW, I wrote asm code to do exactly this inside Novell's NetWare OS a little over 10 years ago. In NetWare these timestamps were used by the Packet Burst algorithms which optimized packet transmission rates.

    Terje
  • by hurfy (735314)
    What i haven't seen mentioned yet is:

    Won't this break down if more than one investigator is running this attack on a network? What if several people try this trick against a group of servers? How would they know the time skew was due to THEIR query? What if this is the best trick ever so everyone trying to track down a computer uses it ;)

    Couldn't they detect whatever the popular trick is to increase temp and have the computer try and skew others on the network. I don't suppose you would want to do it random
  • Not one. You have to know a finite set of computers that are a Tor network. In my reading of the article it seems that without this finite set you fall victim to the 16 per 1000 that have the same skew, problem.

    Without knowing as well that all systems are skewd differently you also have a problem. What if you grabbed a random set of 32, with 2 groups of 12 and one of 8 with identical skews.
  • This is good science-y stuff. It sounds like something that could actually happen, so I want to jam it into my next script for CSI:Redmond. Here's what I need from you nerds:
    1. Some dialogue explaining the process* in a step by step manner that can be spoken over stylized computer screenshots and typing noises.
    2. Some Photoshopped computer screens with GIGANTIC FONTS that look like the process is happening. Progress bars please.
    3. Some kind of hip crime that computer nerds are doing now. Pedophilia is old news--D

3500 Calories = 1 Food Pound

Working...