3 ms·

Side-channel attacks like this are always a little hard to follow, and there's a lot of detail in here, so here's my best synopsis of the technical details behi

Side-channel attacks like this are always a little hard to follow, and there's a lot of detail in here, so here's my best synopsis of the technical details behind why this works: In many modern Intel CPUs (all Sandy Bridge, maybe Nehalem and Core 2 too, not Haswell) you can get cache bank conflicts, where two instructions try to read the same bank (cross-cutting segment) of the CPU cache in quick succession. When that happens one of the instructions has to wait for the other to complete, so takes fractionally longer. If you trigger a whole bunch of these cache bank conflicts yourself, while OpenSSL is working, you'll get tiny delays in your reads from parts of the cache that OpenSSL is using. If you do this an enormous number of times, you can then look at the accumulated average delays in your requests, and work out how OpenSSL's memory accesses are distributed over these banks. Depending on the value of one part of the secret that OpenSSL is using to sign or decrypt data (specifically, the multipliers used in the multiplication steps in RSA), its access pattern for the cache is actually slightly biased. This is the bug. Once you know which banks are most active, you know the overall access pattern, and you can use this to drastically reduce the number of possibilities for each multiplier. That gives you enough information about the value of the key that with some subsequent offline processing you can recover the rest (apparently doable in about 3 minutes on a high-end CPU). The fix is to ensure that the patterns of cache access that OpenSSL makes are totally independent of the secret data being used. The latest patch effectively does this, fixing the bug. You can still use cache bank conflicts to work out which bits of the cache OpenSSL is hitting, but that's no longer useful information. (I think this is broadly right; I'd love to know if there's details I'm missing though!)

wolf550e 11y ago
small nit: 2 CPU-hours, 3 minutes wallclock time on a high end server (40 cores).
jqueryin 11y ago
Would implementation of a very minute, random delay (if you give it a range) be an acceptable fix for some of these timing attacks? I'm thinking along the lines of adding a config param to /usr/lib/ssl/openssl.cnf (Ubuntu).
- AngrySkillzz 11y ago
  No; if you add a random delay, your adversary can just repeat the attack multiple times and the timing data will average out to the real value, removing your added noise. It might increase the time/number of observed messages needed to perform the attack, but it won't defeat it.
- philh 11y ago
  (Not at all confident about this.) AngrySkillzz aside, I think there's another reason this won't work. From the sound of pimterry's explanation, the timing effects happen in your own code, not OpenSSL's. It's not "hit the cache to slow down OpenSSL", but "hit the cache and see if OpenSSL slows me down". Adding random delays to OpenSSL wouldn't help guard against that.
- stygiansonic 11y ago
  This is unlikely to help against a determined adversary. The reason is that the bias introduced by the timing differences can still be detected using statistical methods, provided you have enough samples. (In general, I would expect that you'd need more samples when the randomness is large relative to the timing attack difference) See this blog post [1] for examples of how differences as small as 20 microseconds over the Internet could be detected, despite the effect of latency. Latency can be considered a random variable, albeit maybe not with the same distribution as a RNG, but the same principles likely apply. 1. http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/ http://rdist.root.org/2010/07/19/exploiting-remote-timing-at...

wolf550e 11y ago

small nit: 2 CPU-hours, 3 minutes wallclock time on a high end server (40 cores).

jqueryin 11y ago

Would implementation of a very minute, random delay (if you give it a range) be an acceptable fix for some of these timing attacks? I'm thinking along the lines of adding a config param to /usr/lib/ssl/openssl.cnf (Ubuntu).

AngrySkillzz 11y ago
No; if you add a random delay, your adversary can just repeat the attack multiple times and the timing data will average out to the real value, removing your added noise. It might increase the time/number of observed messages needed to perform the attack, but it won't defeat it.
philh 11y ago
(Not at all confident about this.) AngrySkillzz aside, I think there's another reason this won't work. From the sound of pimterry's explanation, the timing effects happen in your own code, not OpenSSL's. It's not "hit the cache to slow down OpenSSL", but "hit the cache and see if OpenSSL slows me down". Adding random delays to OpenSSL wouldn't help guard against that.
stygiansonic 11y ago
This is unlikely to help against a determined adversary. The reason is that the bias introduced by the timing differences can still be detected using statistical methods, provided you have enough samples. (In general, I would expect that you'd need more samples when the randomness is large relative to the timing attack difference) See this blog post [1] for examples of how differences as small as 20 microseconds over the Internet could be detected, despite the effect of latency. Latency can be considered a random variable, albeit maybe not with the same distribution as a RNG, but the same principles likely apply. 1. http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/ http://rdist.root.org/2010/07/19/exploiting-remote-timing-at...