Security Experts:

Stack Ranking SSL Vulnerabilities: DUHK and ROCA

Even with catchy branding and cute mascot and a theme song, these two SSL/TLS vulnerabilities nearly went unnoticed last week. The WPA2 Key Reinstallation Attack (KRACK) overshadowed them both, vacuuming up the tech media attention.

DUHK and ROCA are both implementation-specific vulnerabilities concerning one of my favorite topics, random number generators.

The “Don’t Use Hardcoded Keys” (DUHK) vulnerability is sponsored by that amazing team of researchers Nadia Heninger and Matthew Green, though they are honest and explicitly say that their graduate student, Shaanan Cohney, did all the grunt work. Heninger has been behind a ton of interesting crypto attacks, including the DROWN attack, and my personal favorite, the cracking of 1% of SSL keys due to bad random numbers, Mining your Ps and Qs. 

General purpose computers have a difficult time generating random numbers without a true random source. Many computers use a pseudo-random number generator (PRNG); typically, a deterministic algorithm that attempts to expand a small amount of random data into larger amount. But that process was known to be fraught with error even before the invention of computers themselves.

Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin.” – John Von Neumann, 1951.

The Green/Heninger/Cohney team didn’t invent anything new with DUHK; the ANSI X.931 PRNG used in some ancient versions of FortiOS VPNs and firewalls has been known to be garbage for years because of its use of a static key. Fortinet patched the problem over three years ago, and if someone is still running software that old, they probably have easier vulnerabilities to target. 

But keeping true to my original premise of ranking SSL-related vulnerabilities against each other, let me compute a score for DUHK. A PRNG compromise may not yield the system’s private key to an attacker, but it would let them passively crack sessions and decrypt network traffic, which could contain sensitive data like admin credentials.

DUHK stack rank score = 3

- Impact = session key derivation = 3

- Exploitability = (low exposure) = 1

Meanwhile, in the non-academic world, many are rolling their eyes at another branded SSL vulnerability. Check out the comments on Green’s excellent write-up of DUHK. Even Green admits that DUHK is a “fairly absurd” vulnerability. His conclusion that government crypto specifications are worthless, based on a few examples, is a tad too dismissive. Standards prevent vendors from using ancient or insecure ciphers like RC2, or designing their own crypto algorithms (which is such a bad idea that it is called “Schneier’s Law”). The answer to a bad or outdated standard is to design a new one, which is what happened with ANSI X9.31 (it was deprecated by NIST in 2011).

But look at it this way; graduate student Cohney got a whole vulnerability and his name in the papers, and good for him. I’d have done the same thing for him if I were Green and Heninger. But for the rest of the world, if you haven’t patched your Fortinet systems since the summer of 2014, man, you had better take another look at your life decisions.

List of Dangerous Software Vulnerabilities

Everything Old Is New Again

The Return of Coppersmith’s Attack (ROCA) is also an ancient problem. And, like DUHK, ROCA is specific to a particular implementation—in this case, Infineon chipsets that are often used in smart cards and embedded, high-security (trusted computing) environments. The authors of ROCA claim these chipsets are found in FIPS 140-2 and CC EAL 5+ certified hardware, both of which are solutions you pay tens of thousands of dollars for to keep your private keys, well, private.

The majority of keys vulnerable to ROCA are associated with smartcards (which are actually not smart at all, having very little in the way of computation power and thus need tricks like “fast prime” for generating keys). But researchers have found a handful of vulnerable TLS and Github keys.

With ROCA, an attacker could factor a 2048-bit private key with $20,000 to $40,000 in CPU time. Factoring a 1024-bit key is only about $50 (peanuts)! ECC keys are probably not vulnerable to ROCA, though DH keys might be. What’s really interesting is that you can easily tell by examining the public key whether or not the private one is crackable.

The actual paper for ROCA will be released later this week at the ACM Conference on Computer and Communications Security. But if we assume the early details are correct, when we plug ROCA into my stack-rank table for SSL vulnerabilities, it gets a score of 20, much higher than DUHK.

ROCA stack rank score = 20

- Impact = recover private key = 10

- Exploitability = non-trivial = 2 

Keep in mind that both DUHK and ROCA are limited to a handful of SSL/TLS sites, which is what we’re evaluating these vulnerabilities against.

If you are an administrator for a medium to large enterprise, there is little chance that ROCA is going to be a fire drill for you. Sure, the larger your organization, the higher the chance that somewhere you have a device vulnerable to DUHK or ROCA. And very likely your biggest headache is that of inventory. And if you haven’t solved the inventory problem, at least you’re in very common company as it is becoming the hardest problem to solve. 

For crypto implementors, don’t rely only on deterministic inputs like timestamps and static keys. Seed your PRNG with a small bit of real random numbers instead. You can get a Quantum RNG for practically nothing these days. Here’s one that someone sent me; it’s the size of a typical USB.

USB for Quantum Random Number Generation (RNG)

Disclosure: I have no ties to that particular vendor, and am not endorsing it, I just thought it was cool that they sent me a sample. QRNG as an input into a PRNG would be much more secure than timestamps. Intel’s Ivy Bridge has been leveraging quantum effects in its onboard RNG, using it since 2011. 

Even though they’re both old and vendor-specific, I’m glad to be writing about DUHK and ROCA, because anything that sheds light on the difficulty of generating real random numbers is a good thing. More people should be trying to solve the RNG problem, because it is so fundamental to cryptography, as DUHK and ROCA both show. 

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.