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

[Theodore Ts'o]

On Mon, Jan 10, 2022 at 03:38:08PM +0100, Jason A. Donenfeld wrote:
> 
> Yea, I'm not really compelled by it as something real that we'd
> actually want to have for something serious. Keep in mind: this thread
> isn't really about cryptography, but just about compliance nonsense.
> BUT, if it turns out that the path to these people getting their green
> compliance checkbox stamp isn't actually thousands of lines of new
> code, but rather some glue bridging the /dev/urandom / getrandom(2)
> API into the blah cryptoapi thing, that's... interesting news to me.
> I'm not even saying, at this stage anyhow, that I want to do this, but
> I do find it a very interesting data point.

The last time I had the displeasure of looking into the FIPS
certification, which granted, was over a decade ago when I was in
IBM's Linux Technology Center, what I learned was it all depends on
the FIPS certification lab.  NIST writes the documentation, but what
really matters is the FIPS certification lab that a hardware or
software vendor pays $$$$ to in order to get the magic certificate
which allows you to sell into *some* government contracts.  (When I
had to go through the all of the nonsense to get a TS/SCI clearance to
support the real-time kernel for all of the IBM servers for the
DDG/1000 Zumwalt Class destroyer, they didn't care about getting FIPS
certified.  I've also seen tighter security measures for computer
rooms at NYC financial companies than at a Top Secret machine root at
said defense contractor.  Go figure....)

The other thing I learned for those customers who *did* care, was that
the only thing that got certified was a specific binary image.  If you
replace the kernel or OpenSSL library with, say, a bugfixed version
that fixed an actively exploited zero day, *boom*, that would break
the certification and the system would no longer be FIPS certified.

Some FIPS labs would allow you to certify the "cryptographic core" of
the OpenSSL library, which the OpenSSL library would then dlopen, and
so as long as the bugfix was in, say, the ASN.1 parser, and you didn't
need to change the "cryptographic core" it was OK --- and you just
needed to hope that there weren't any bugs in the cryptographic core,
since then you wouldn't be allowed to fix it --- since FIPS compliance
was more important than, say, the *actual* security of the system in
question.

So yeah, as I said, it's all about TSA-style security theatre, and
when I worked for IBM and there was millions of dollars on the line, I
might have cared.  For upstream development, (and blessedly, this is
not something that my current employer has needed to worry about) I
care far less about it.

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

> > Specifically, I think that if you change your perspective from, "how can we
> > change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within
> > its limits so that having what customers want would minimally impact the
> > quality of the RNG implementation or introduce undue maintenance burdens."
> 
> We're now starting to get some idea about how this FIPS stuff bends.

Well, if we optionally (if jitterentropy_rng is compiled in), we would
periodically pull from it as one additional entropy source into the
input_pool, it won't do any harm --- other than the CPU overhead
consumed by jitterentropy, of course.  Maybe that would make some
people happy, including some FIPS Labs?

I've also seen some FIPS certifications which didn't care about what
the kernel did, but only cared about what was in the OpenSSL library.
(Which is where the story about segregating out the cryptographic core
so that you could actually patch most zero-days without having to go
back to the FIPS certification lab, pay $$$, and wait months for the
updated binary to be certified.)

So I suspect that there will be a lot of anecdotal evidence, but the
only thing we can probably say with any amount of certainity is Your
Mileage May Vary.

Cheers,

						- Ted