Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 04 Apr 2021 23:47:10 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
>     Date:        Sun, 4 Apr 2021 15:28:13 +0000
>     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
>     Message-ID:  <20210404152814.3C56360A23%jupiter.mumble.net@localhost>
> 
>   | you can let NetBSD take care of it automatically
>   | on subsequent boots by running `/etc/rc.d/random_seed stop' to save a
>   | seed to disk.)
> 
> Is that file encrypted?   If it is, where does the decryption key come from?

No.  If the adversary can bypass file system privileges to read (and,
most likely, write) arbitrary data on your disk, that adversary is
outside the threat model and you need to do something else to deal
with such an adversary -- for example, by encrypting your disk with
cgd(4).

If the random seed is stored on a networked file system, then NetBSD
incorporates it but treats it as having zero entropy since a network
eavesdropper could read it.

(Side note: Disclosure of the _current_ seed file does not enable
retroactive recovery of _past_ secrets generated from /dev/urandom.)

> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that.   Regardless of
> how unproven that method might be.

The seed is hashed together with disk drive interrupt timings, so you
get security from either or both, along with RDRAND/RDSEED output if
available.  The kernel also uses the hardclock timer to periodically
sample a cycle counter as a makeshift ring oscillator, if nothing else
is available.  Every device listed in `rndctl -l' has the opportunity
to influence the output of /dev/urandom; for security it is enough
that any one of them be adequately unpredictable.

> And what's the scheme for cheap low-end devices that have no
> writable storage?  (The proverbial internet toaster, for example).

If the device has a HWRNG, great.  If not, this may be a difficult
problem for the system engineer designing the device to solve.
There's no free lunch.

> Lastly, why would anyone presume that RDRAND generates less predictable
> bits (less predictable to someone who knows how it works) than any of
> the other methods that are used.

We generally take the vendor's word in hardware documentation about
what's actually behind the device registers, just like we do for any
other device we have a driver for (e.g., we generally expect devices
not to leak the contents of arbitrary RAM across the network).

In the case of Intel RDRAND, the design is documented in

	Intel Digital Random Number Generator Software Implementation
	Guide, Revision 2.1, October 17, 2019.
	https://web.archive.org/web/20190404022757/https://software.intel.com/sites/default/files/managed/98/4a/DRNG_Software_Implementation_Guide_2.1.pdf

The design samples from ring oscillators -- two independently clocked
circuits, one of which rapidly alternates between states and the other
of which periodically samples the first, so the state is determined by
the random timing jitter between the two clocks, influenced by
unpredictable thermal noise in the silicon.  This class of designs is
reasonably well-studied in the literature -- much moreso than, e.g.,
disk seek times or network packet times.

We also incorporate new information about the devices if available.
For example, on certain AMD CPUs, RDRAND and/or RDSEED sometimes gets
into bad states, which the device driver checks for; in this event the
driver counts zero entropy.

We sometimes do a bit of science on the devices too.  See
https://nxr.netbsd.org/xref/src/sys/arch/mips/cavium/dev/octeon_rnm.c
for some notes on the Cavium Octeon HWRNG, and
https://nxr.netbsd.org/xref/src/sys/arch/arm/sunxi/sun8i_crypto.c for
an example of a driver for a thing that might be an OK HWRNG but is
not clearly endorsed by vendor documentation and has a very nonuniform
distribution so we obviously need more than 256 bits of sample
material to get 256 bits of entropy -- but how much more is not clear,
which is why it counts as zero entropy for now.

> If we want really good security, I'd submit we need to disable
> the random seed file, and RDRAND (and anything similar) until we
> have proof that they're perfect.

...right

FYI: If you really want, you can stop the kernel from counting any
particular entropy source by setting rndctl_flags in /etc/rc.conf:

rndctl_flags="-E -d rdrand; -E -d rdseed; -E -d rdrand/rdseed; -E -d seed"

Then any attempt to read from /dev/random will block until some other
entropy source has provided enough entropy.