Computer's Heat May Unmask Anonymized PCs

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

Re:I didn't RTFA, but...

[KshGoddess]

the heat-up causes a shift in how much the clock drifts, and you can query time from different servers to pinpoint which one it is.

See what reading the article gets you? A tiny nugget of useless information.

FTA: Clock Skew, not temp.

[Mr. Flibble]

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

Re:I didn't RTFA, but...

[qbwiz]

You measure clock skew before, during, and after you hit the hidden service. If the change in clock skew happens at the same time you load the server, that indicates that it's probably the correct server.

Re:Trivial Solution

[Bios_Hakr]

I picture this attack being used as part of an ongoing investigation. They have a target and they just need some pattern analysis to secure the warrant. Over a month-long investigation, they could glean a lot of info by throwing up very specific requests and seeing if your hard drive springs to life or your CPU spikes.

In most cases, the wouldn't even need to be near your house. A well-positioned amp-meter with remote sensing could tell you if the CPU suddenly needed more power.

Re:Randomize the clock

[Baricom]

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.

Re:I didn't RTFA, but...

[Tweaker_Phreaker]

Read what you just said. Skew is a distortion of measurement. In normal operation there is no distortion, only when the crystal is heated. So by definition there is only one possible value for the skew and it's the change from before to after the crystal has been heated.

More info on Murdochs talk

[tlund]

More info on Murdochs talk can be found at the congress website [congress.ccc.de].

Re:Fix it with NTP?

[Anonymous Coward]

couldn't you combat this by having a local NTP server for your server farm, and then setting the servers to update from that server at frequent intervals (say every 5 sec or so)? It would waste cycles on the machines and generate some extra load on the network, but it would keep the clocks from ever drifting far, and it would narrow the window in which you'd be able to detect drift to something pretty small.

Or try a simple hardware upgrade [walmart.com]

Re:utterly useless?

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

Re:FTA: Clock Skew, not temp.

[jd]

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

Re:Fix it with NTP?

[lky]

While Herbivore sounds interesting, don't forget to mention its limitations as well.

In the Herbivore documentation, you will find this PDF: Eluding Carnivores: File Sharing with Strong Anonymity [cornell.edu]

From which we learn that: The system consists of approximately 27,000 lines of Java and C code, 2,000 of which comprise the GUI for anonymous filesharing and a helper application for k-anonymous chat while the rest form the core system. (Section 5: Performance)

So Herbivore provides anonymity for filesharing and chat. That is all it can do in its current implementation.

On the other hand, Tor works with any IP based protocol and can be integrated into the applications that a user currently uses.

The second weakness of Herbivore is that it is not ready for distribution yet. The only code available is if you request to be part of the initial rollout by non-anonymous email. Herbivore Download Page [cornell.edu]

Tor is not only available for download, it is in current use.

The third weakness of Herbivore is that it requires that a client application be run on the users system. If your system is ever confiscated and examined by the authorities, this can be judged to be evidence of potential wrong doing resulting in further examination (if you don't believe this is possible, just read: PGP Ruled as Relevant For Criminal Case [slashdot.org]). A secondary weakness of the client is that it will limit the operating systems that Herbivore will run on to those systems that support Java and that Herbivore has been developed for (I2P [i2p.net] has the same problem).

On the other hand, Tor can be used by simply configuring the users application to use a known Tor entry point as a proxy server. This configuration can be removed when the user is done, leaving little or no tracks. In this way, Tor can be used by any system that supports TCP/IP and SSL.

And the fourth and last weakness I will mention is that since Herbivore has not been released yet, it has not undergone extensive peer review and testing. On the other hand, the reason we are aware of Tors weaknesses is because it has been released, tested and peer reviewed. As we've learned from many cryptographic systems, you should not trust them until this peer review is complete and any/all weaknesses are known (which is why Tor has the disclaimer that it should not be fully trusted yet).

While Herbivore may provide strong anonymity, in no way is it a replacement for a general anonymity tool like Tor. On the other hand the more tools we have, the better. So I look forward to testing Herbivore when it becomes available.