Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B5C6C433EF for ; Tue, 11 Jan 2022 16:10:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349840AbiAKQKo (ORCPT ); Tue, 11 Jan 2022 11:10:44 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:48653 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1343495AbiAKQKn (ORCPT ); Tue, 11 Jan 2022 11:10:43 -0500 Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20BG8jiU007374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Jan 2022 11:08:45 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 24DC415C00C8; Tue, 11 Jan 2022 11:08:45 -0500 (EST) Date: Tue, 11 Jan 2022 11:08:45 -0500 From: "Theodore Ts'o" To: "Jason A. Donenfeld" Cc: Andy Lutomirski , Marcelo Henrique Cerri , Simo Sorce , Greg Kroah-Hartman , Jeffrey Walton , Stephan Mueller , Linux Crypto Mailing List , Willy Tarreau , Nicolai Stange , Linux Kernel Mailing List , Arnd Bergmann , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Florian Weimer , Lennart Poettering , Peter Matthias , Neil Horman , Randy Dunlap , Julia Lawall , Dan Carpenter , Andy Lavr , Petr Tesarik , John Haxby , Alexander Lobakin , Jirka Hladky , Eric Biggers Subject: Re: [PATCH v43 01/15] Linux Random Number Generator Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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