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

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 [twitter.com]

Here's the whole thread:

[reiisi]

The thread [marc.info] on marc.

Re:

[rastoboy29]

It would be more accurate to say, "isn't *believed* to be vulnerable..." don't you think?

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.

How much of this is FUD?

[alcourt]

This sounds like another the sky is falling alert. That alone makes me suspicious.

I'm not exactly an expert on this, but reading it, I see several assumptions built in that seem at best infeasible. First, while they admit that they can do it on a LAN, they admit that it is much harder, and over a larger or busier network crossing multiple routers, this may not be feasible. Second, they seem to believe that "cloud computing" makes it more feasible because they believe the odds of being stacked on the same

Re:

[Ja'Achan]

Ah, but is he any good at it?

Re:

[betterunixthanunix]

It depends on the environment you are in. Doing it across a LAN could be feasible if you are a bank employee trying to defraud your employer.

The real question is, how many people are using ECDSA right now?

Re:

[alcourt]

That still impacts the risk factor.

As for ECDSA, I've seen extremely few implementations that used it, but I'm focused on the OS side, not the application side, so maybe apps use it more than I realize.

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:

[alcourt]

The Q&A linked from the summary isn't cryptographic researchers communicating with each other, but speaking specifically to the public saying how terrible this is. More than one statement is made about real world exploitability and how vulnerable the world is.

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.

Re:

[account_deleted]

Comment removed based on user account deletion

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:

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

[Anonymous Coward]

There are alternatives to adding fixed or random delays to mitigate timing channel attacks (see Askarov, Zhang, and Myers, 2010)

Re:

[solinym]

See also: http://www.subspacefield.org/security/security_concepts/index.html#toc-Subsection-31.2 [subspacefield.org] Especially section 31.2.4

Re:

[thsths]

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

We already have a random delay, it is called "the internet". And of course it only makes it more difficult to use this side channel attack, but not impossible.

However, you could also respond a fixed delay after the *start* of the calculation. That should eliminate any timing difference in the algorithm itself.

You still have access to the timing side

Re:

[Co0Ps]

Random delays don't work in theory. All you have to do is to get a couple of extra data points and then average them. The result should be pretty accurate. It might be effective in practice though if the number of extra data points is too great.

Re:

[Anonymous Coward]

OpenSSH isn't vulnerable. OpenSSL is.

Re:

[russotto]

OpenSSH isn't vulnerable. OpenSSL is.

Should we expect an OpenSSM to correct this regression?

Radio Community

[ah_kanta]

It would be more accurate to say, it will be vulnerable..." don't you think? http://www.ruposhibangla.net/ [ruposhibangla.net]

Who actually uses ECDSA?

[WaffleMonster]

While I'm sure people are using it.. I never have and I don't know of anything that does.

Incompetence here? (TFA)

[udippel]

Though I have a pretty good idea what a side-channel attack is (I am a cryptographer), I can't fathom the 'intercept private key' part of the message. Eavesdropping means interception and interception means that Eve can intercept the private key as sent. There is, however, no reason to send the private key, ever. So the term 'intercept the private key' sounds suspicious.
Like in the Bernstein Attack (google for it, I'm too lazy to offer a link), a symmetric key (AES) can be reconstituted from the timing sequ