[Cryptography] where shall we put the random-seed?

[Theodore Ts'o]

On Tue, Dec 27, 2016 at 02:33:27PM +0000, Jason Cooper wrote:
> Here's a hitherto un-addressed problem.  Currently, system init scripts
> read 512 bytes from /dev/urandom and write it to random-seed during
> _startup_.  This is in case of a hard shutdown.  Iff there is a clean
> shutdown, then the shutdown script reads 512 bytes from /dev/urandom and
> writes it to random-seed.

Not true; this is not a problem.  Since the very beginning, this is
what I recommended for system init scripts.  From
drivers/char/random.c:

 *	echo "Initializing random number generator..."
 *	random_seed=/var/run/random-seed
 *	# Carry a random seed from start-up to start-up
 *	# Load and then save the whole entropy pool
 *	if [ -f $random_seed ]; then
 *		cat $random_seed >/dev/urandom
 *	else
 *		touch $random_seed
 *	fi
 *	chmod 600 $random_seed
 *	dd if=/dev/urandom of=$random_seed count=1 bs=512

What this means is that the random_seed file is rewritten during the
boot sequence.  It won't necessarily have much in the way of new
entropy, but it is cryptographically secure in that if you believe the
attacker didn't have access to the prior contents of the random_seed
file, and if you believe the cryptographic algorithm used in the crng
(SHA1 or ChaCha20, depending on the version of the kernel), the
attacker won't be able to predict the new contents of the random_seed
file.

> Unfortunately, in the embedded world, clean shutdowns rarely happen.
> And, as is well established, the entropy pool sucks at boot time.  This
> means that the random-seed used at the next boot up was most likely
> sampled at the worst possible time. :-(

As long as you had one clean shutdown --- for example, if you take a
Nexus or Pixel handset fresh out of the box, it almost certainly will
be taking a security update and then rebooting, that will be a clean
shutdown, and there should hopefully be uncertainty that will be hard
for an attacker to reverse engineer accumulating in the entropy pool
while downloading the update and then installing to the flash device,
and then the clean shutdown will initialize random-seed.

Another useful thing you could do in userspace is to use the username
and password of the user signing into the device, and mixing that into
the entropy pool.  And certainly userspace can decide to update the
random_seed file at times other than at clean shutdowns.  So having
userspace initialize random_seed after communicating with the user,
which hopefully will have some uncertainty available during setup
process, is certainly quite possible.  On a Debian system, you can do
this very easily simply by running the command "/etc/init.d/urandom
stop".

It's true that for specific embedded systems, you may need to do
something special, but that's always been true.  Especially an IOT
where there is no user I/O and where it blindly believes any initial
connection over the network as coming from the owner.....  but I'd
argue that cryptography and random entropy initialization is the
_least_ of your problems.  The bigger problem is that by that between
the time that the IOT firmware was flashed, and when the device was
delievered to the user, there are probably *already* publically known
security vulernabilities, and if the IOT device manufacturer isn't
providing monthly security updates, why worry about random entropy
initialization?  That's not how the hackers are going to break into
your Smart Home....

						- Ted