Re: [PATCH v43 01/15] Linux Random Number Generator

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Jan 10, 2022 at 12:38:00PM -0500, Theodore Ts'o wrote:
> If we want to add a CONFIG_RANDOM_SECURITY_THEATRE build option which
> diverts getrandom and /dev/urandom to use crypto/drbg, I'm going to
> think it's a waste of time, and there are some things about
> crypto/drbg that I'm not psyched about such as the fact that only
> reseed after 2**20 calls to drbg_generate(), and the drbg statemachine
> will initialize itself from get_random_bytes() in early boot, when the
> CRNG is least likely to be securely initialized.  So **I** wouldn't
> want to use it for my own personal security, but if it allows Ubuntu
> to sell into the US govnerment market, my only hope is that this
> wouldn't be inflicted on all of their customers, but only those US
> Government customers who care (and as near as I can tell, this is
> *not* all USG customers).
> 

So just a few thoughts:

Ubuntu, Red Hat, and Oracle all have patches which do this.  They differ
slightly; e.g., Ubuntu's patch only changes /dev/urandom while the others change
/dev/random and getrandom() too.  But the idea is the same: the userspace
interfaces to the RNG are changed to get output from a SP800-90A DRBG
(crypto/drbg.c) rather than the Linux RNG directly.  The SP800-90A DRBG in turn
is seeded from from two entropy sources combined: the Linux RNG
(get_random_bytes()) and jitterentropy (crypto/jitterentropy.c).

My understanding (and I could be totally wrong -- I am still trying to reverse
engineer all the requirements for this certification stuff) is that the reason
that these distros need this is they are certifying the whole kernel image as a
FIPS cryptographic module, and that implies that cryptographic random numbers
must conform to the SP800-90{A-C} documents.  The problem is that ChaCha20 isn't
considered an approved DRBG algorithm, nor do Linux's entropy sources have
SP800-90B continuous health-tests.  Therefore, get_random_bytes() is considered
to provide no entropy.  crypto/drbg.c works around this by using an approved
DRBG algorithm and by using jitterentropy which has SP800-90B tests.

I think the reason people are considering this to be a hack is because on paper
it ignores Linux's main RNG.  It's still *used* as an extra entropy input, but
on paper it's credited with no entropy.  That seems a bit odd.

However, even Stephan's patchset has the same issues, IIUC.  Stephan's patchset
still keeps get_random_bytes() using ChaCha20, and it provides an option to
layer crypto/drbg.c on top of it for userspace output.  So I'm not sure how much
of a hack it really is, if the supposed non-hack is basically the same.

Now, the idea of certifying the whole kernel as a FIPS cryptographic module is
stupid, given that it prevents the kernel from being updated to fix security
vulnerabilities.  However, I've been told that essentially the same RNG issues
also arise for NIAP certification of mobile devices
(https://www.niap-ccevs.org/MMO/PP/PP_MDF_V3.2.pdf), which looks at entropy
system-wide.  NIAP similarly doesn't consider ChaCha20 to be an allowed DRBG
algorithm, so they consider the entropy to be constantly depleting, and it "runs
out".  (There have been devices that passed NIAP despite this, but I've been
told that this was an oversight.)  Wiring up /dev/{u,}random and getrandom() to
crypto/drbg.c would avoid this issue too.

So again, I could be totally wrong, as I am trying to reverse engineer the
requirements here --- but to me it seems that a small patch to provide an option
to use crypto/drbg.c could solve both the FIPS and NIAP certification problems.

If Stephan could elaborate on what his patchset does that is better (as far as
certification is concerned, at least -- I know his patchset has some other
advantages such as eliminating non-cryptographic entropy processing), that would
be helpful to illuminate anything I may be missing.

- Eric