![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gdtThe Raspberry Pi's BCM2835 system-on-a-chip has a hardware random number generator. Since the Pi doesn't have a lot of the usual sources of randomness it is well worth turning on.
Edit /etc/modules and add the line:
bcm2708_rng
This will create the device /dev/hwrng at the next boot. If you can't wait until then say modprobe bcm2708_rng. When the random number generator module is installed dmesg will report:
bcm2708_rng_init=df8d6000
To drop this source of random data into the kernel's pool of randomness use the rngd daemon: sudo apt-get install rng-tools.
Edit /etc/default/rng-tools to say:
HRNGDEVICE=/dev/hwrng
The default parameters for rngd are a good fit for a inadequately described hardware random generator so there is no need to bother with setting any RNGDOPTIONS.
Restart rngd with /etc/init.d/rng-tools restart.
When rngd starts it syslogs:
rngd 2-unofficial-mt.14 starting up... entropy feed to the kernel ready
When rngd is stopped it prints the values of statistics it maintains to validate the randomness of data read from /dev/hwrng. For example:
stats: bits received from HRNG source: 140064 stats: bits sent to kernel pool: 98944 stats: entropy added to kernel pool: 98944 stats: FIPS 140-2 successes: 7 stats: FIPS 140-2 failures: 0 stats: FIPS 140-2(2001-10-10) Monobit: 0 stats: FIPS 140-2(2001-10-10) Poker: 0 stats: FIPS 140-2(2001-10-10) Runs: 0 stats: FIPS 140-2(2001-10-10) Long run: 0 stats: FIPS 140-2(2001-10-10) Continuous run: 0 stats: HRNG source speed: (min=596.574; avg=709.100; max=743.255)Kibits/s stats: FIPS tests speed: (min=5.947; avg=6.126; max=6.191)Mibits/s stats: Lowest ready-buffers level: 2 stats: Entropy starvations: 0 stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us Exiting...
If you underrun the "lowest ready-buffers level" then alter RNGDOPTIONS in /etc/default/rng-tools to decrease the --feed-interval from 60 seconds to 10s or even down to 1s; also increase the --rng-buffers from 3 to 5.
If programs read from /dev/random and block and this blocking is harming performance then make the hardware random number generator carry more of the load of filling the entropy pool. When --fill-watermark is not provided the contribution of the hardware random number generation to the entropy pool to 50%, increase that to 90% with --fill-watermark=90% (the "%" is required, 90 has a different meaning entirely). Note that this places more trust in the correct operation and non-subversion of the hardware random number generator.
Addendum 2015-12-03: Regenerating SSH host keys
One reason to use the random number generator is to generate secure SSH host keys. This is difficult to do without the hardware random number generate because of the low level of entropy available on the RPi soon after boot.
Remove the existing host keys:
$ sudo rm /etc/ssh/ssh_host_*
Then generate new keys, using the key algorithms recommended by your Debian distribution:
$ sudo dpkg-reconfigure openssh-server Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Creating SSH2 ECDSA key; this may take some time ... Restarting OpenBSD Secure Shell server: sshd. [ ok ]
Addendum 2016-03-19: Raspberry Pi 3 and Jessie
The module name has changed to bcm2835_rng.
To install say:
$ echo bcm2835_rng | sudo tee /etc/modules-load.d/rng-tools.conf $ sudo modprobe bcm2835_rng $ sudo apt-get install rng-tools $ echo 'HRNGDEVICE=/dev/hwrng' | sudo tee --append /etc/default/rng-tools $ sudo systemctl enable rng-tools $ sudo systemctl start rng-tools $ sudo systemctl status -l rng-tools
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-10-14 01:52 (UTC)Anyways, here are some responses to the issues which people have mentioned.
The people who posted with concerns that Broadcom may have subverted the random number generator miss a point. There are two things happening here: the addition of randomness to the kernel's entropy pool, and the accounting for that. If you don't trust the RNG then add the randomness, but set the accounting to count zero bits of randomness added. The entropy pool won't release bits any faster than are provided by non-RNG data sources, but the quality of the randomness may be better if the RNG is outputting any randomness at all.
You might reasonably choose not to trust the Broadcom RNG due to the lack of documentation explaining it's principles of operation. For example, what happens when you apply environmental stress? Presumably the RNG is there to allow randomness for choosing GSM and 3G session keys, and that might mean that the RNG keeps providing numbers, rather than halting -- after all no one wants their phone to stop working just because it was left in the sun or ice. Explaining to users that their phone may be operating in a subverted mode is a user interface nightmare, so it's possible that the RNG isn't even designed to signal when it is operating out of range.
You also shouldn't assume that the Linux random number system can't be subverted. You wouldn't do that through source code, but through timing and memory attacks.
If you start to audit the sources of entropy against their ability to be subverted externally the news gets bad rather quickly on a computer without spinning disk. Adding the output of /dev/hwrng to the entropy pool of /dev/random is really meant to be a simple way to overcome this major problem of a lack of system entropy where near boot. It isn't anything approaching trusted computing, where every minor problem has the be shut tightly.
If you really need a random number you are better off doing this in your application:
k = read /dev/random (whichout /dev/hwrng contributing to the entropy pool)
b = read /dev/hwrng
n = x xor b
as that will save you from timing attacks (assuming the Broadcom hwrng isn't subverted, but then you are no worse off anyways).
no subject
Date: 2014-09-27 21:00 (UTC)The fix for me was to (hard) restart the raspberry pi.
no subject
Date: 2014-09-27 21:42 (UTC)Rebooting loads the kernel from /boot. The version of this kernel matches the version of the kernel modules in /lib/modules.
no subject
Date: 2016-04-17 01:37 (UTC)