On Tue, Jan 11, 2022 at 02:16:30PM +0100, Jason A. Donenfeld wrote:

I spent some time reading about FIPS certification, compliance, and
the requirements of various customers. One thing in particular leapt
out at me, which I think you've been saying over and over in this
thread but I didn't fully understand until this morning:

The goal is generally to have particular pieces of software or
particular solutions FIPS certified. And to do this, they start from
the top of the stack and move onward down. Most OSS software out there
today isn't really FIPS ready and oftentimes a full solution needs
modifications in one place or another. Other times, it's enough to
plug in the right userspace crypto libraries. And I noticed in looking
at things that are FIPS certified that random number generation tends
to go through a userspace abstraction layer. And, it looks like these
abstraction layers all have FIPS-able RNG hooks. You mentioned OpenSSL
earlier, and it looks like even libgcrypt and wolfSSL have an
abstraction layer for this.

I know this thread is about security theatre, not real security, but
there's an even more important reason why the FIPS cryptographic
module should be as high in the stack as possible (e.g., in
userspace).  Let's consider as, Albert Einstein would put it, the
following gedanken experiment:

Let's presume that in 2008, there was a FIPS-140 certified OS
designating the Linux kernel as the "cryptographic module", and so
/dev/urandom was hacked to be "FIPS certified".  Huzzah!  Now let's
assume that OS was using Ubuntu, which, being derived from Debian, was
subject to a distribution "value add" where in blind obedience to a
valgrind warning, there was a distro-level change which resulted in
OpenSSL on Debian and Debian derivitives generating extremely
predictable keys[1].  This caused fairly massive security problems for
any use of OpenSSL, including ssh, certificate generation, etc. ---
despite the FIPS 140 certification of the OS.  Oops!

[1] https://en.wikinews.org/wiki/Predictable_random_number_generator_discovered_in_the_Debian_version_of_OpenSSL

It might be *cheaper* to claim that your OS is FIPS 140 certified by
hacking /dev/urandom.  Otherwise, you might have to have a responsible
security engineer audit the various userspace cryptographic libraries,
and that would be way more expensive.  It's much easier for a product
manager to say, "my work here is done" after applying a patch to the
Linux kernel for /dev/urandom, and not bothering to get an engineer to
certify the rest of the cryptographic stack.

And, if enterprise customers just care that an enterprise distro can
claim "FIPS 140 compliance", and they can push that claim of FIPS
compliance to the PCI certification authorities, they're happy.  So
ultimately, this is really an economic requirement, not a security
requirement.  And given that enterprise distros are the ones getting
paid $$$ in order to claim FIPS 140 compliance, then from an upstream
perspective, if our gaols is to optimzie the speed of getrandom(2) and
/dev/urandom, and to encourage application programmers to do the right
thing --- and *not* security theare for the sake of economic goals, we
should make technical decisions accordingly.

Cheers,

					- Ted