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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yd2rjQhK71L2vwgb@mit.edu>
Date:   Tue, 11 Jan 2022 11:08:45 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Simo Sorce <simo@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jeffrey Walton <noloader@...il.com>,
        Stephan Mueller <smueller@...onox.de>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Willy Tarreau <w@....eu>, Nicolai Stange <nstange@...e.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Andy Lavr <andy.lavr@...il.com>,
        Petr Tesarik <ptesarik@...e.cz>,
        John Haxby <john.haxby@...cle.com>,
        Alexander Lobakin <alobakin@...lbox.org>,
        Jirka Hladky <jhladky@...hat.com>,
        Eric Biggers <ebiggers@...nel.org>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

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