Please create an account to participate in the Slashdot moderation system


Forgot your password?
Encryption Communications Network Privacy Security The Internet

DUHK Crypto Attack Recovers Encryption Keys, Exposes VPN Connections ( 59

An anonymous reader writes from a report via Bleeping Computer: After last week we had the KRACK and ROCA cryptographic attacks, this week has gotten off to a similarly "great" start with the publication of a new crypto attack known as DUHK (Don't Use Hard-coded Keys). The issue at the heart of the DUHK attack is a combination of two main factors. The first is the usage of the ANSI X9.31 Random Number Generator (RNG). This is an algorithm that takes random data and generates encryption keys used to secure VPN connections, browsing sessions, and other encrypted traffic/data. The second factor needed for a DUHK attack is when hardware vendors use a hardcoded "seed key" for the ANSI X9.31 RNG algorithm. When these two conditions take place, an attacker can brute-force encrypted data to discover the rest of the encryption parameters and deduce the master encryption key used to encrypt web sessions or VPN connections. In a research paper published today, researchers said they found 12 vendors that sold hardware/software products with hardcoded X9.31 seed keys. This issue is widespread because ANSI X9.31 is very widespread. Up until January 2016, the algorithm was on the list of U.S. government (FIPS) approved RNG algorithms. ANSI X9.31 remained on the list until 2016, even if US NIST deprecated the algorithm in 2011, and scientists warned that the algorithm could be broken if the seed key ever leaked way back in 1998.
This discussion has been archived. No new comments can be posted.

DUHK Crypto Attack Recovers Encryption Keys, Exposes VPN Connections

Comments Filter:
    • Duh! Duh! Duh! =)

      NSA wants into our shit

      Do-DUH Do-DUH

      Now it's leaked and hackers pwn it

      All the do-DUH day!

      Gonna leak all night

      Gonna leak all day

      NSA leaks and breaks our shit

      All the do-DUH day!


  • RNG (Score:5, Funny)

    by Anonymous Coward on Wednesday October 25, 2017 @06:49AM (#55428751)

    This is what you're doing if you hardcode PRNG seeds:

    int getRandomNumber()
        return 4; // chosen by fair dice roll, guaranteed to be random

    221 []

    • xkcd mod informative? Not funny? Seriously?

      Without going into the impossibility of generating a "random" (as opposed to unpredictable and/or uncorrelated) number, the sad thing is that it is so easy to generate "good" seeds, as all of the primary operating systems have entropy gathering systems that are easy to call. The one in Windows is (sadly) closed source, but it is there, and M$ programmers are rarely overtly incompetent given a specific task. And for mission critical super-duper applications, the

    • Could someone explain to me why implementing the PRNG in Rust would have prevented this vulnerability?
  • Sounds Familiar (Score:5, Interesting)

    by mentil ( 1748130 ) on Wednesday October 25, 2017 @07:11AM (#55428815)

    A vulnerability like this was speculated to be the mysterious method the NSA used to supposedly be able to break SSL connections, as revealed in the Snowden documents. It's probably not this exact vuln, though, as this seems to mostly be a problem in hardware used to route to VPNs.

    • by Anonymous Coward

      All hardware with EEPROMS or re writable firmware is a good bet. Special flags upped by say row hammering is another,
      What IS interesting is that pace of vuln discovery is picking up - maybe the millions splashed on rewards is training competent goldhats to uncover single basics -combination backdoors are somewhat harder to discover, As baked in management hardware is real, all one can do is insert BSD like handcrafted routers to drop unexpected traffic - now that whole computer usb dongles are cheap cheap.


      • by Anonymous Coward

        I see security getting worse. Mainly because there is zero reason to put out a secure product, and a ton of reasons not to. If I made a secure IoT lightbulb, I'd be put ot of business by competitors who have the exact same thing, but 1/10 the price, because they didn't bother with security, since security brings zero returns on investment.

    • OpenBSD is not vulnerable to this attack because it does not use ANSI X9.31. Therefore it is still "relatively" safe to use for hard-coded keys. That much said, the manual pages take pains to discourage people from using hard-coded keys at all. Since OpenBSD does not suffer many of the vulnerabilities, I just throw it on two (or more) systems when I need to spin up a VPN.
      • The problem isn't the use of the X9.17/X9.31 PRNG, it's the use of a hardcoded key with the PRNG and misuse of the PRNG's output. So OpenBSD could be quite vulnerable to all sorts of things that don't involve this particular PRNG. Conversely, something using this PRNG isn't automatically vulnerable.
    • by AHuxley ( 892839 )
      XKeyscore, Turmoil, Keycard, Hammerstein, Turbine, Apex, Coral Reef... Fashioncleft.
      Collect it all gets that Encapsulating Security Payload :)
  • AI (Score:3, Funny)

    by 110010001000 ( 697113 ) on Wednesday October 25, 2017 @07:42AM (#55428885) Homepage Journal
    Yet we will have "AI" becoming sentient and taking over the world real soon now, right? Meanwhile we can't even get normal software to work properly. The tech industry is so full of hype.
    • The tech industry is long on grandiose ideas and VERY short on delivery. What does get delivered is usually a crappy, half-baked app written in India that crashes when you hit the menu button.
      • by Anonymous Coward

        The tech industry's greatest trick is moving to new things so quickly that few people can ever really get their head around a given tech before it falls by the wayside. So we all end up building things, from the trivial to the critical, on technologies that we delude ourselves into thinking we understand. Because the advantages of computing and software are so massive that no one wants to wait until the day when we understand software the way we understand, say, building and bridge construction.

    • by Anonymous Coward

      Well, the point of actual AI is, that you don’t have to get shit right, because you can just use a very simple algorithm, use a _lot_ of it, and get the thing to solve the problems by itself. Which, surprisingly, actually works.
      Of course none of that shit we see being called AI, is actually AI.

      Damn! Now I wonder if there is a way to use this to get large masses of dumb humans to perform something smart! Imagine actually getting something good out of a billion Trumps*!
      (* Or insert whatever meme you cur

    • by Anonymous Coward

      I was just thinking that yesterday & yes, I am inclined to agree with you on those very grounds. What you said isn't 'funny': It's fact that is NOT funny @ all...

      * Wait till the shift is to "quantum computing" & see all the bugs (OR WORSE in horrible decision making AI might end up making since we can't create anything 100% perfect apparently) that'll pop up then to compound it even moreso, let alone AI alone on Von Neumann based (iirc, feel free to correct me here if needed) architectures we use no

  • by Anonymous Coward

    I also think a similar thing is possible for known S-Boxes in AES. I'd prefer they be generated rather than hardcoded myself. Waiting for that article.....

    • by fisted ( 2295862 )

      You cannot be serious

    • by amorsen ( 7485 )

      It is highly likely that there exists at least one set of values for S-Boxes for AES that would make the encryption trivially breakable. It is also highly likely that it would be possible to detect a datastream encrypted with that kind of broken AES. Those are not properties you want in an encryption algorithm.

  • by sinij ( 911942 ) on Wednesday October 25, 2017 @09:12AM (#55429203)
    If you compromise PRNG seed, you can predict its output. This is why seeding with full entropy for crypto applications is so important. This is why if you are running headless Linux box, you should consider XORing CPU entropy with /dev/[u]random.
    • Or, if your application is really critical (read, it will cost you a mountain of money, human lives, etc if its encryption fails) you might throw in a well-designed commercial entropy source (a number are out there, including some that at least claim to be quantum based and hence "truly random" and not JUST unpredictable) and xor in that as well. Headless boxes also have a hard time keeping up with entropy demand, so adding a fast high entropy source is a good idea to avoid delays while the system accumula

      • by HiThere ( 15173 )

        What you need is an old fashioned triode amplifier with the gain turned up and no signal fed in. Turn up the amplifier enough and you get thermal noise, to make it nice, compress it a bit and use the middle bytes. (I think most compression algorithms would work for this, all you're doing is making sure that half the bits are on and half off. You could probably do as well though by taking two sample and xor-ing them.)

      • []

        It is going to be moderately difficult not to reinvent a wheel in /. commentary. This is big business, worth a lot of money, valuable as a research tool, critical to national defenses round the world, basis of modern commerce and banking, key (so to speak) to personal privacy in the internet era, and what the heck, essential to really excellent games.

        One can buy hardware RNGs that plug into USB ports for a few tens of dollars. To efficiently whiten their output (if necessa

  • by redelm ( 54142 ) on Wednesday October 25, 2017 @09:49AM (#55429411) Homepage

    Fixed entropy [passwd] is clearly an oxymoron -- it is at most an obscurant. At the very least other sources of pseudo-entropy should be sought and mixed in. Something like low-order time bits or low order MAC bits from the network.

New systems generate new problems.