OpenSSL Has A Chink To Be Aware Of

The accurate generation of random numbers (or more particularly pseudo random numbers) is central to much in computer security.  Problems with random number generation are often found to be the cause of vulnerabilities, usually because someone has taken a short cut or used a source that they consider to be random when it's not.  I was a little surprised to then see a paper that documents some problems with the random number generator (RNG) in OpenSSL.

OpenSSL is one of the most widely used libraries in computer security.  It has had some problems in the past (such as Heartbleed) which were not only major concerns because of the nature of the problem but also because OpenSSL is used in many systems, particularly embedded systems that are hard to update. It's free software and open source so people have used it because they felt it was great if you were building a system to a low price whilst offering apparent security through the visibility of the code.  Heartbleed taught everyone that open source does not equal scrutinised code.

The paper I read this week was entitled "An Analysis of OpenSSL’s Random Number Generator".  The analysis revealed some issues.


The researchers took a detailed look at the lifecycle of the random number generator within OpenSSL:

As expected, before the RNG has been properly seeded it cannot produce cryptographically secure random numbers.  However, you would not expect it not to do any damage assuming it is not used in any cryptographic functions.  Unfortunately it does appear that OpenSSL allows what is termed "low entropy secret leakage".

Part of the issue is tracked down to a design flaw of OpenSSL’s core RNG, which potentially generates keys limited to 240 bits of security whereas it tries to achieve 256 bits.  In practice this is no great problem as this doesn't allow for any practical attacks of its own accord.  However, when you understand how this reduction occurs it becomes apparent that other functions might be offering less security than was thought, which could theoretically lead to an attack.  But, even this is unlikely.

Where it becomes slightly more troubling is when the researchers examine the stirring that occurs (stirring is a core function of modern practical implementation of random number generation as described here).  It appears that with the way this is implemented that, with some access to the output, an attacker might effectively render starts to render the entropy of important byte streams as low as 160 bits.

The researchers show how a "DEJA-SEED" attack might be mounted via which a key might be recovered.  By showing that under the right (or rather wrong) conditions the RNG can be reduced to a security level of effectively 80 bits.  This is seen as a danger area by cryptographers.  Although the computational power required to exploit this level of security is still beyond most it probably wont remain that way for too long.

However, it must be stressed that for the majority of systems in practice these conditions would not prevail.  Still it does demonstrate that OpenSSL is not always as secure as it might appear.  Although this is an error in the cryptographic design of OpenSSL, it shouldn't be a problem unless your system is using automated seeding.  Sadly the systems most likely to be affected by this are embedded and mobile systems.

The researchers do offer a set of countermeasures which basically involved avoiding certain configurations and functions.

What the research does show is that implementing RNGs is hard, and it isn't surprising that is so often appears the core of a problem when it is found in cryptographic software.