5 ms·

- Most services are IO bound, not CPU bound, so pegging the CPU to max might prove a non-trivial task. - Well designed services don't overload until they're ma

- Most services are IO bound, not CPU bound, so pegging the CPU to max might prove a non-trivial task. - Well designed services don't overload until they're maxing out on either CPU or any other resources, they just serve up to some capacity (say 80%) and then start flat out refusing request with response semantics like "come back later". - Timestamp sources are typically not from clocks originating inside the CPU.

jacquesm 12y ago
You won't need to peg the CPU, you only need to get it to warm up a little bit, enough to create a skew that can be detected. Worst case that means that you need to wait longer but it will still work. The crystal can be on the motherboard, it does not really matter, as long as the total heat inside the case is large enough to create a skew that can be measured the attack will work.
- mantrax5 12y ago
  If you warm it a little bit I think the problem becomes your skew becomes lost in the noise of the other people accessing. It's tempting to think that other people accessing is "perfectly uniform noise" but that's not the type of patterns people see in real web services. They get hit in waves most of the time. If a service gets hit by a wave while you're measuring some suspect server, here's your false positive right there. Nice paper but somehow I think this tactic would neither work out well in practice, nor work in court as a proof.
  - jacquesm 12y ago
    All that means is that you need to sample over a longer period. And it does not have to work 'in court as a proof' to be practically viable attack, and they are well beyond theory: "Implementing this is non-trivial as QoS must not only be guaranteed by the host (e.g. CPU resources), but by its network too. Also, the impact on performance would likely be substantial, as many connections will spend much of their time idle. Whereas currently the idle time would be given to other streams, now the host carrying such a stream cannot reallocate any resources, thus opening a DoS vulnerability. However, there may be some suitable compromise, for example dynamic limits which change sufficiently slowly that they leak little information. Even if such a defence were in place, our temperature attacks would still be effective. While changes in one network connection will not affect any other connections, clock skew is altered. This is because the CPU will remain idle during the slot allocated to a connection without pending data. Unless steps are taken to defend against our attacks, the reduced CPU load will lower temperature and hence affect clock skew. To stabilise temperature, computers could be modified to use expensive oven controlled crystal oscillators (OCXO), or always run at maximum CPU load. External access to timing information could be restricted or jittered, but unless all incoming connections were blocked, extensive changes would be required to hide low level information such as packet emission triggered by timer interrupts. While the above experiments were on Tor, we stress that our techniques apply to any system that hides load through maintaining QoS guarantees. Also, there is no need for the anonymity service to be the cause of the load."

jacquesm 12y ago

You won't need to peg the CPU, you only need to get it to warm up a little bit, enough to create a skew that can be detected. Worst case that means that you need to wait longer but it will still work. The crystal can be on the motherboard, it does not really matter, as long as the total heat inside the case is large enough to create a skew that can be measured the attack will work.

mantrax5 12y ago
If you warm it a little bit I think the problem becomes your skew becomes lost in the noise of the other people accessing. It's tempting to think that other people accessing is "perfectly uniform noise" but that's not the type of patterns people see in real web services. They get hit in waves most of the time. If a service gets hit by a wave while you're measuring some suspect server, here's your false positive right there. Nice paper but somehow I think this tactic would neither work out well in practice, nor work in court as a proof.
- jacquesm 12y ago
  All that means is that you need to sample over a longer period. And it does not have to work 'in court as a proof' to be practically viable attack, and they are well beyond theory: "Implementing this is non-trivial as QoS must not only be guaranteed by the host (e.g. CPU resources), but by its network too. Also, the impact on performance would likely be substantial, as many connections will spend much of their time idle. Whereas currently the idle time would be given to other streams, now the host carrying such a stream cannot reallocate any resources, thus opening a DoS vulnerability. However, there may be some suitable compromise, for example dynamic limits which change sufficiently slowly that they leak little information. Even if such a defence were in place, our temperature attacks would still be effective. While changes in one network connection will not affect any other connections, clock skew is altered. This is because the CPU will remain idle during the slot allocated to a connection without pending data. Unless steps are taken to defend against our attacks, the reduced CPU load will lower temperature and hence affect clock skew. To stabilise temperature, computers could be modified to use expensive oven controlled crystal oscillators (OCXO), or always run at maximum CPU load. External access to timing information could be restricted or jittered, but unless all incoming connections were blocked, extensive changes would be required to hide low level information such as packet emission triggered by timer interrupts. While the above experiments were on Tor, we stress that our techniques apply to any system that hides load through maintaining QoS guarantees. Also, there is no need for the anonymity service to be the cause of the load."