4

I'm doing some reading into the security issues surrounding /dev/random but it's proving to be hard to find good sources of information. Can anybody help? I've asked Google and got a bunch of articles from pre-2006 so I'm assuming a lot of the issues pointed out there have been fixed. I've also been going through the source but I'm not an encryption or security expert so there's a good chance my personal analysis wont be sufficient. Any help or direction would be greatly appreciated.

EDIT: to make my question more specific, what I want to know about is how the entropy pool is mixed, how the level of the pool is estimated, and how /dev/random actually calculates its values based on what is in the pool. I want to know why things are done how they are done and what are the weaknesses of the methods used. I know how the pool is populated.

My end goal is to implement a TRNG that will populate /dev/random. Now, I can get its output (nice and white) to the pool, I just want to know if it's worth bypassing the pool completely and writing a module to directly populate /dev/random. I'm assuming here that an assailant can poison the pool to mess with the random device output.

At the moment I'm working with Ubuntu, the kernel version is 2.6.32

Sheena
  • 149
  • 5
  • 1
    It would help if you mention the specific issues you're wondering about – chris Sep 12 '11 at 07:48
  • The only kind of issue I can think of would be predictable random numbers - and of course any such issue that has been publicized is already fixed. – Wladimir Palant Sep 12 '11 at 09:15
  • I'm mostly worried about how the pool is mixed, and how random numbers are derived and why – Sheena Sep 12 '11 at 11:22
  • Sheena - please update your question to describe the scenario and what you want, otherwise it is likely to be closed. – Rory Alsop Sep 12 '11 at 11:30
  • You also really need to pick a platform. The plumbing of Linux in this regard is completely different from a non blocking Yarrow implementation found in many BSD variants. – Tim Post Sep 12 '11 at 12:00
  • If the tag "linux" is reliable (and other things point to that as well), then this is about the current Linux /dev/random. I am interested in the question as well - I haven't seen any recent security evaluations of the Linux /dev/random pool implementation. – Nakedible Sep 13 '11 at 09:21
  • 1
    The base paper referred so everybody can get on track as to what vulnerabilities were found the last time: http://eprint.iacr.org/2006/086.pdf – Nakedible Sep 13 '11 at 09:22
  • 3
    there's some interesting commentary on /dev/random and /dev/urandom in the answers to this question http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key – Rory McCune Sep 14 '11 at 12:46
  • Dude, just read random.c in the Linux kernel. Its more comments than actual code. – rook Nov 22 '11 at 21:25

2 Answers2

3

For many cryptographic applications, /dev/random is a secure way to gather (pseudo) random data. There are, however, several key issues that seem to be along the lines of what you're asking.

One of the issues is that it is possible to write to /dev/random. According to Wikipedia,

It is also possible to write to /dev/random. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate. The current amount of entropy and the size of the Linux kernel entropy pool are available in /proc/sys/kernel/random/.

This makes sense for a non-compromised machine, however if someone has rooted a box, they could theoretically write non-random data (that appears random) to /dev/random and cause problems with cryptographic keys generated from that point forward. It's tough to determine the severity of such an attack, since if root was already compromised, more significant attack vectors would certainly exist (all software could, at that point, be backdoored).

The second set of issues, detailed in the paper Analysis of the Linux Random Number Generator (March 2006), focuses on problems with saved-state machines. This is primarily found in Linux live-cd's that have the same built-in (read-only) entropy when booting, but in today's world can also apply to virtualized machines that have states restored, or machines using software that can revert to a "known good" state upon shutdown. If the entropy can be determined upon boot, then /dev/random can be compromised (as it is a known starting value).

There are several ways to improve upon the standard /dev/random, the most well-known of which may be the Entropy Gathering Daemon (http://egd.sourceforge.net/). EGD can work as a "userspace substitute" for /dev/random, which can allow applications to have a significantly more secure PRNG.

Lastly, if you are interested in "true random" entropy, consider using a service like Random.org which uses atmospheric noise to create true, not pseudo, random numbers.

Hope this helps!

dshaw
  • 845
  • 5
  • 11
  • 4
    Using random.org to generate cryptographic keys sounds dangerous. You would need to use HTTPS to secure them on transit, but see the [note in their FAQ](http://www.random.org/faq/#Q2.4): *anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.* – Paŭlo Ebermann Nov 22 '11 at 21:00
  • 1
    This is certainly a very valid point. My use case was more along the lines of downloading significant amounts of truly random data and using chunks of it for seeding /dev/random vs. downloading new random data to create each new key. ENG would be more suited towards key creation. – dshaw Nov 22 '11 at 21:17
  • 1
    Rooting a box and messing with `/dev/random`? I wouldn't even bother with such a possibility. – Camilo Martin Jul 27 '12 at 13:12
  • -1 for suggesting something as silly as using an online randomness service for these purposes. – forest Apr 03 '18 at 04:45
1

Resources:

You can pick the version of interest to you from the top. The source for the software RNG is pretty well commented, so I'll leave interpretation up to you.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171