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

[Jason Cooper]

Hi Ted,

On Wed, Dec 28, 2016 at 07:39:37PM -0500, Theodore Ts'o wrote:
> 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.

Mmm, yes, I didn't write that very clearly, but we agree on the current
state of things.

> > 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.

Agreed.

> 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".

dd if=/etc/shadow of=/dev/urandom

> 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....

Well, I disagree.  I'd prefer not to give up just because the rest of it
is crappy.  It may not always be that way.  We should fix what we have
the power to fix as soon as we can.  Especially with the long deployment
cycles of embedded systems.

Those devices are typically wireless, so there are A/D converters.
Microphones and cameras as well.  So, even without dedicated hw-rngs,
and no user input, there is still wiggle room.  And TLS connections :-P

thx,

Jason.