Dual EC DRBG

Exploitability in TLS

The amount of randomness actually visible in TLS is one of the questions addressed in a 2014 research paper On the Practical Exploitability of Dual EC in TLS Implementations by Checkoway, Fredrikson, Niederhagen, Everspaugh, Green, Lange, Ristenpart, Bernstein, Maskiewicz, and Shacham. The basic Dual EC attack turns out to be highly oversimplified: it ignores critical limitations and variations in the amount of the PRNG output actually exposed in TLS, additional inputs to the PRNG, PRNG reseeding, alignment of PRNG outputs, and outright bugs in Dual EC implementations.

Use of Dual EC in TLS libraries

There are many implementations of Dual EC, including hundreds of FIPS-certified implementations. The implementations analyzed in the paper are four well-known TLS libraries that implement Dual EC:

  • OpenSSL-FIPS. This is the FIPS-certified version of OpenSSL.
  • Windows SChannel. This library is used in Microsoft Internet Explorer and Microsoft IIS.
  • RSA BSAFE Share for C/C++ ("BSAFE-C").
  • RSA BSAFE Share for Java ("BSAFE-Java").

To understand how widespread these libraries are, the paper used ZMap to collect TLS handshakes from 21.8 million servers, and then checked those TLS handshakes for BSAFE-Java and SChannel fingerprints. About 12% of the servers showed SChannel fingerprints, but it is not clear how many of these servers use Dual EC; by default Windows does not use Dual EC. Fewer than 1% of the servers showed BSAFE-Java fingerprints. The paper did not find a way to recognize the default configuration of BSAFE-C through the network, so it is not clear how many servers run BSAFE-C.

Main results

The paper states its major findings as follows:

  • "The BSAFE implementations of TLS make the Dual EC back door particularly easy to exploit in two ways. The Java version of BSAFE includes fingerprints in connections, making them easy to identify. The C version of BSAFE allows a drastic speedup in the attack by broadcasting longer contiguous strings of random bits than one would at first imagine to be possible given the TLS standards."
  • "Windows SChannel does not implement the current Dual EC standard: it omits an important computation. We show that this does not prevent attacks; in fact, it allows slightly faster attacks."
  • "We discovered in OpenSSL a previously unknown bug that prevented the library from running when Dual EC is enabled. It is still conceivable that someone is using Dual EC in OpenSSL, since the bug has an obvious and very easy fix, so we applied this fix and evaluated the resulting version of OpenSSL, which we call OpenSSL-fixed. OpenSSL-fixed turns out to use additional inputs in a way that under some circumstances makes attacks significantly more expensive than for the other libraries."

The researchers were not in possession of back-door information for the standard Dual EC parameters, so they took the following approach to verify the actual performance of attacks: generate new Dual EC parameters with a new back door, modify each library (through reverse engineering in the cases of BSAFE-C, BSAFE-J, and SChannel) to use those parameters instead of the standard parameters, completely implement an attack using the new back door, and verify that the attack recovers TLS plaintext from TLS ciphertext. The researchers also successfully recovered signature keys from TLS servers that used DSA or ECDSA to sign DH/ECDH public keys.

Authors of this "Exploitability in TLS" page (alphabetical order)




Last modified: 2014.07.07