Plain life is just not random enough

While trying to generate a gpg keypair on a remote server, I discovered I lack entropy. Eventually I had to physically type on the keyboard in order to generate enough random bytes.
A short research led me to the following startling thread in the Linux kernel mailing list; Someone suggested to disable the entropy gathering from network cards: http://marc.theaimsgroup.com/?l=linux-kernel&m=114684809230875&w=2
* Note that in stock kernel version, entropy is still gathered from network cards.

I see this as an extremely bad move. ‘Headless’ servers with no keyboard and mouse have very few ways to create random entropy.
Web servers are an extreme example. There are few disk events that can contribute to the amount of entropy, and on the other hand SSL connection requires a lot of randomness.

This decision, if indeed accepted, is completely absurd. If someone decides to cancel network card as a source to random number generation, at least leave it as an option to the kernel module, a /proc entry or something. Why just diff it out??

To make things worse, Intel used to provide an onboard random number generator. This initiative was torpedoed, and the chip no longer exists in modern boards. There goes another source of random entropy out the window.

Modern day servers requires more sources of entropy than ever. We use VPNs, SSH and HTTPS. Let’s face it, SSL is ubiquitous.

As an example, try to run 4 simultaneous ssh connections to a dedicated web server (for some time, at least 4-5 hours), and try to generate a GPG keypair. 9 out of 10 times you’ll be out of entropy.

Suggested solutions like gathering entropy from the sound card don’t cut it for production servers.
There are the of course the dedicated PCI cards: http://www.broadcom.com/collateral/pb/5802-PB05-R.pdf
http://www.idquantique.com/products/quantis.htm

But then we could also ask for a Schrödinger’s cat that sits in a conveniently located alternate universe to establish SSL handshakes for us.

Attacks on PRNGs are well documented. Today no one believes that clock interrupts are cryptographically random. For example, look at: http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf

I would love to hear your opinions and suggestions from security point of view.

Share
  • Daniel Jackson

    How do security decisions get done for linux development? What is the process?

  • doorman

    Linux isn’t the same as the Kernel.

  • Sara

    Ami, how was this Intel project torpedoed?

  • http://www.beyondsecurity.com ami

    The status of the chip is quite obscure. It was released in 1999 as a feature to Pentium 4 chipsets.
    From Intel:
    “82802 Firmware Hub Device Random Number Generator (RNG). The RNG is dedicated hardware that harnesses system thermal noise to generate random and in-deterministic values.”

    It appears that Intel was very supportive of this. Intel supplies a simple programmers manual to the 298029. There is also a Driver for various Windows Operating systems.

    At some point in time, Intel removed the feature. I could not find a reference to the change, but it looks like a ‘political’ move, rather than a technical issue. I would imagine that some security vendor and government agencies could have an influence in this step :-)

    By the way, this page has a utility to check if the RNG is present on your motherboard (basically the same test the kernel does while loading the hw_random module).

    The only chipset vendor I am aware of that has a similar built-in capability is VIA.

    *Note that theoretically there is no difficulty in creating the same capability the chip provides via the motherboard temperature / voltage / fan / etc. sensors.