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

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

Re:Fr1sr psot

[Anonymous Coward]

Indeed sir that sounds like a good idea

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 physical server as your target is good.

I'm not by any means saying that they haven't identified a weakness that needs to be fixed, but right now, I'd need more to accept their claim of how vulnerable everyone is to this.

Re:How much of this is FUD?

[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:How much of this is FUD?

[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:How much of this is FUD?

[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:How much of this is FUD?

[houghi]

possible that someone somewhere is really screwed by this attack, so it should be taken seriously

/I would disagree.
No systems are known. It is not certain there are even people affected. So it should NOT be taken seriously. It should be looked at with interest from an academic point of view at most.

"Taking it seriously" is already emotionally charged. People take terrorist children seriously.

Re:How much of this is FUD?

[Ja'Achan]

Ah, but is he any good at it?

Re:How much of this is FUD?

[Anonymous Coward]

What are you talking about? A viable attack is a viable attack. The only question left unanswered is whether people care enough about you to launch that attack.

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.

[Anonymous Coward]

OpenSSH isn't vulnerable. OpenSSL is.

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:Just introduce a fixed delay, problem solved.

[Anonymous Coward]

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

Re:Just introduce a fixed delay, problem solved.

[russotto]

OpenSSH isn't vulnerable. OpenSSL is.

Should we expect an OpenSSM to correct this regression?

Re:Just introduce a fixed delay, problem solved.

[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 channel if you are logged on, but a) that is a rare situation, and b) the data you get from top is typically pretty bad.

Re:Just introduce a fixed delay, problem solved.

[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:Just introduce a fixed delay, problem solved.

[solinym]

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

Here's the whole thread:

[reiisi]

The thread on marc.

Radio Community

[ah_kanta]

It would be more accurate to say, it will be vulnerable..." don't you think? http://www.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 sequence, which is a typical side-channel attack. Though without the spy-programme, no chance.
I am not trying to say the original document was crap, though I am not sure it has been interpreted correctly.
[10 minutes later]
I read the original paper and I'm vindicated: No transfer of the private key, no interception. Over.
The attack is on factorization sequences of the original message which - depending on the circumstances - allows for regeneration of the original key. Which is vastly different from the term 'interception'.