Are 32,768 different keys enough?

May 30th 2008 01:30 pm

This is one for the books. Several OpenSSL implementations, including Denbian and its children, including Ubuntu, have been crippled since September 2006. It’s described on the metasploit web site.

The pseudo-random number generator (PRNG) was broken such that it only used the Unix process ID as the unchanging random input to the generator process. In other words, these security packages could not generate more than 32,768 different keys (since there were only 32,768 different process IDs on Unix).

(By the way, the question in the title is rhetorical, and the answer is a resounding NO.)

This is especially painful for sites that used this randomization process to generate SSL public/private key pairs for web sites. Those sites now have to generate new public/private key pairs and get them signed by their certificate authorities. Once they’ve posted the new key pairs, they’re safe. Otherwise, an attacker could sniff the SSL traffic (described on the metasploit site).

The interesting thing to me is how the error occurred.

In fact, the designers did a fairly careful job of designing the implementation to pick up whatever entropy it could. But randomness apparently depended on a couple of procedure calls that didn’t “look right” to the system build process.

To make the process as reliable as possible, developers include auto-checking with tools like Valgrind and Purify. These tools look for possible coding errors that aren’t picked up by the compiler. The auto-checking flagged two procedure calls that helped yield a larger random seed value, and those calls were removed.

By removing the calls, the system ended up with a cleaner compile, but it drastically reduced the system’s randomness when doing SSL. This is hard to detect, especially at the compiler or system test level.

Posted under Information Security |

Trackback URI | Comments RSS

Leave a Reply

You must be logged in to post a comment.