1 2 3 4 5 6 next »

Good numbers, bad numbers

Martin Bartosch

The role that random numbers play in the OpenSSL disaster

Many users and administrators are still unsure about the causes and effects of the problems in the Debian Linux project's OpenSSL library. We help you understand how all this came about – and how you can assess your personal risk.

Since September of 2006, the random number generator in the Debian version of OpenSSL has been almost useless. As a direct and indirect result, various problems related to encrypted communication have occurred. Debian users are not the only ones affected. Indirectly, users of other systems that have encrypted communication with a Debian system or use weak Debian keys also are. Indeed, the problem can even affect those who do not use a Debian system.

Proper random numbers serve as the basis for a number of cryptographic algorithms and protocols. It is crucial that the random numbers used not be predictable. Computers naturally have a hard time creating truly random numbers. The quality of random numbers varies greatly from one operating system to the other, which is why OpenSSL, which runs on numerous platforms, has its own function to generate random numbers from an internal entropy pool. OpenSSL uses the internal function ssleay_rand_add() in the file crypto/rand/md_rand.c to add data from various sources to this pool.

In the case of Linux, the time, the current process ID, the user's ID, non-initialised memory, and – most importantly – data from the UNIX device /dev/urandom are included. Each time the entropy pool is filled up, OpenSSL takes note of how much additional entropy was added in an internal variable. In return, this variable is accordingly reduced whenever OpenSSL uses entropy from the pool to generate random numbers.

Paved with good intentions

While trying to prevent warnings being issued by memory debuggers such as Valgrind and Purify, Debian maintainer Kurt Roeckx accidentally broke the central instruction in the function ssleay_rand_add (), which is supposed to put new data into OpenSSL's entropy pool. Once this change had been made, the function simply ignored the data transmitted.

The OpenSSL function ssleay_rand_bytes() generated the quantity of random numbers specified by the caller and used the entropy pool thereby created (which is completely empty in the Debian version) to initialise a pseudo-random number generator (PRNG) with a starting value. In the process, the function once again added the current process ID, which can have 2¹⁵ different values on a normal Linux system. Consequently, only 32,767 different number combinations could be used.

The random numbers used in strong cryptography are as important as the algorithms that use them. The scope of the problem becomes clear when we remember how often secure random numbers are needed – and what the effects are if they are easy to guess. In principle, every application that uses random numbers from the OpenSSL random number generator should be checked. The list includes OpenSSH, OpenVPN and a number of other applications linked to OpenSSL libraries, but the list does not include GPG, which has its own crypto functions. The weakness of these random numbers differs from one OpenSSL function to another. While specific information for individual applications and tips on what steps to take are provided in Heise Security's OpenSSL Guide and in the Debian Wiki, the overview below will also help you understand how everything is interrelated so that you can better assess your personal risk.

1 2 3 4 5 6 next »