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

Fix it with NTP?

[Kadin2048]

Not that I think this sort of thing is really going to become anything more than an interesting proof-of-concept anytime soon, but 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.

utterly useless?

[pavera]

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:I didn't RTFA, but...

[Tweaker_Phreaker]

Yes but that's not the skew he's measuring. He's only measuring the skew caused by heating the crystal.

Use NTP to defend against all clock skew attacks

[Terje Mathisen]

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