Please create an account to participate in the Slashdot moderation system


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
Encryption Security

OpenSSL Timing Attack Can Intercept Private Keys 31

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."
This discussion has been archived. No new comments can be posted.

OpenSSL Timing Attack Can Intercept Private Keys

Comments Filter:
  • by Mysteray ( 713473 ) on Friday May 27, 2011 @05:32PM (#36268340) Homepage
    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.
  • by dmiller ( 581 ) <djm.mindrot@org> on Friday May 27, 2011 @05:32PM (#36268344) Homepage
    OpenSSH isn't vulnerable to this attack:!/damienmiller/status/72814031941017600 []
  • 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

    • 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?
      • by alcourt ( 198386 )

        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.

    • by Mysteray ( 713473 ) on Friday May 27, 2011 @07:08PM (#36269136) Homepage

      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.

      • by alcourt ( 198386 )

        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.

        • by Mysteray ( 713473 ) on Friday May 27, 2011 @08:28PM (#36269768) Homepage

          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.

      • by houghi ( 78078 )

        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.

  • by Co0Ps ( 1539395 ) on Friday May 27, 2011 @05:45PM (#36268452)
    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).
    • by bersl2 ( 689221 )

      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.

      • by Co0Ps ( 1539395 ) on Friday May 27, 2011 @06:31PM (#36268782)
        "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.
      • by Anonymous Coward

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

      • by thsths ( 31372 )

        > 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

        • by Co0Ps ( 1539395 )
          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.
    • by Anonymous Coward

      OpenSSH isn't vulnerable. OpenSSL is.

      • OpenSSH isn't vulnerable. OpenSSL is.

        Should we expect an OpenSSM to correct this regression?

  • It would be more accurate to say, it will be vulnerable..." don't you think? []
  • While I'm sure people are using it.. I never have and I don't know of anything that does.

  • 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

If I'd known computer science was going to be like this, I'd never have given up being a rock 'n' roll star. -- G. Hirst