OpenSSL Timing Attack Can Intercept Private Keys

Trailrunner7 writes "Remote timing attacks have been a problem for cryptosystems for more than 20 years. A new paper shows that such attacks are still practical ... The researchers, Billy Bob Brumley and Nicola Tuveri of Aalto University School of Science, focused their efforts on OpenSSL's implementation of the elliptic curve digital signature algorithm, and they were able to develop an attack that allowed them to steal the private key of an OpenSSL server."

Comments

No one uses ECDSA certificates.

[Mysteray]

The EFF's SSL observatory project found a handful of them on servers on the internet, but none of them actually rooted to a well known CA.

OpenSSH is not vulnerable

[dmiller]

OpenSSH isn't vulnerable to this attack: https://twitter.com/#!/damienmiller/status/72814031941017600

Re:OpenSSH is not vulnerable

[dmiller]

No, it is not vulnerable to this attack. The Brumley/Tuveri paper describes a timing leak in a specific algorithm that is only used for elliptic curve crypto over binary/GF(2m) fields. OpenSSH uses ECC over prime fields that use different algorithms that have no known timing leaks. A result against ECC using prime fields would be more difficult because the curve point components are integers and so can use well-tested modular arithmetic code.

Just introduce a fixed delay, problem solved.

[Co0Ps]

Well the solution should be pretty simple. Just patch OpenSSH and introduce a delay in responding to a challenge thats makes the total time be a sufficiently large chunk to allow any crypto calculation to run in that frame for that machine. They even mention this in TFA. Isn't challenge delay crucial anyway to make dictionary attacks and other brute force attacks significantly harder? This seems like the most waterproof way to solve it since it prevents any timing attack, no matter what crypto system is used (in this case the elliptic curve digital signature algorithm).

Re:Just introduce a fixed delay, problem solved.

[bersl2]

If this attack is like previous timing attacks I've read about, then no, adding a fixed delay doesn't help, and adding a random delay doesn't help enough.

The best way to hinder timing attacks is to use invariant-time algorithms. This does tend to reduce performance, though.

Now, let me RTFA.

Re:Just introduce a fixed delay, problem solved.

[Co0Ps]

"Fixed delay" refers to a fixed and delay-padded time frame the whole operation runs in where the total time of the frame is equal or longer than the worst case of any cryptosystem - or for either of them - but preferably longer to account for safety margin and because delay makes brute force harder anyway.

Re:How much of this is FUD?

[Mysteray]

It's not FUD and it's not "the sky is falling" either.

This is cryptographers communicating with one another. Terms like "attack" are being used here in their academic meaning. It's an interesting result, exciting even, but shouldn't be emotionally charged.

If there are any real systems at risk, I don't know of them. But it's certainly possible that someone somewhere is really screwed by this attack, so it should be taken seriously. Anyone using ECDSA should probably apply the forthcoming patches as soon as is practical. This is good advice in any case.

Re:How much of this is FUD?

[Mysteray]

This is just what you get when you have a Threatpost reporter interviewing a cryptographer. I think Brumley does a fine job answering the questions factually, without feeding the hype. There really is a timing attack to which most every implementation of OpenSSL is vulnerable.

The problem is that some people interpret that kind of as some kind of armageddon for internet security, whereas the great majority of secure systems probably aren't affected at all because they don't run the vulnerable code. But for those who are affected the problem may be really really serious for them. It is to these people that the researcher must communicate (via a journalist) without being able to select his audience in advance.