Re: FIPS requirements in lib/crypto/ APIs

[Jeff Barnes <jeffbarnes@linux.microsoft.com>]

On 9/19/25 11:22, Theodore Ts'o wrote:
> On Thu, Sep 18, 2025 at 01:06:47PM -0500, Eric Biggers wrote:
>>> I'm more trying to figure out a general approach to address these kinds of
>>> requirements. What I usually see in FIPS modules, is that the FIPS module
>>> API is as conservative as possible, rather than relying on the callers to
>>> perform the FIPS requirement checks.
>> Aren't these distros including the modules within their FIPS module
>> boundary too?  It seems they would need to.
>>
>> Either way, they've been getting their FIPS certificates despite lib/
>> including non-FIPS-approved stuff for many years.  So it can't be that
>> much of an issue in practice.
> What I would recommend for those people who need FIPS certification
> (which is a vanishingly small percentage of Linux kernel users, BTW),
> that the FIPS module use their own copy of the crypto algorithms, and
> *not* depend on kernel lib/crypto interfaces.
>
> Why?  Because FIPS certification is on the binary artifact, and if
> there is a high-severity vulnerability. if you are selling into the US
> Government market, FEDRAMP requires that you mitigate that
> vulnerability within 30 days and that will likely require that you
> deploy a new kernel binary.
That *must* not be the recommendation of the kernel crypto team. Why 
bother developing and deploying a kernel that boots in fips mode at all 
if you recommend users not use it? More below.
>
> So it would be useful if the FIPS module doesn't need to change when
> your FEDRAMP certification officer requires that you update the
> kernel, and if the FIPS module is "the whole kernel", addressing the
> high-severity CVE would break the FIPS certification.  So it really is
> much better if you can decouple the FIPS module from the rest of the
> kernel, since otherwise the FIPS certification mandate and the FEDRAMP
> certification mandate could put you in a very uncomfortable place.

While the FIPS module is "the whole kernel", re-validation for most 
types of kernel upgrades may not prompt a full submission for FIPS 
certification. A CVE re-validation can be as simple as re-filing a 
description of the change to the module or worst case, a re-test of any 
crypto functions that were changed to support the CVE fix. The most 
expensive re-validation (other than a full submission) is the UPDT 
re-validation submission. In either case, the overhead of the 
re-validation is mostly with the CSTL, not with the government. The 
lion's share of the time for a FIPS 140-3 FS (full submission) 
certificate comes *after* the CSTL submits the validation to NIST.

And to be clear, the FedRAMP requirement is that FIPS certifications or 
re-validation be *filed* (not awarded) within 6 months of release of the 
crypto module ("the whole kernel"). The caveat here is that you have to 
have a certificate to file for a re-validation submission. Given NIST 
backlog, it doesn't seem likely that you'll avoid a full submission if 
you don't already have a 140-3 certificate.


> It's also why historically many companies who need to provide FIPS
> certification will carefully architect their solution so it is only
> dependent on userspace crypto.  A number of years ago, I was involved
> in a project at a former employer where we separated the crypto core
> of the OpenSSL library from the rest of OpenSSL, so that when there
> was a buffer overrun in the ASN.1 DER decoding of a certificate (for
> example), we could fix it without breaking the FIPS certification of
> the crypto core.  And we didn't even *consider* trying add a kernel
> crypto dependency.

IMO, this is an optimal solution for a specialized distro; 
general-purpose OS's *should* update and use the actively developed 
crypto api.

BTW, I agree with you that fewer Linux kernel users need to certify at all.

>
> One of the important things to remember is that as far as FIPS
> certification is concerned, the existence of remote privilege attacks
> don't matter, so long as you meet all of the FIPS certification
> security theatre.  But in the real world, you really want to fix high
> severity CVE's....
Please see FedRAMP's differentiation between update stream and 
validation module stream. 
https://www.fedramp.gov/resources/documents/FedRAMP_Policy_for_Cryptographic_Module_Selection_v1.1.0.pdf
>
> Cheers,
>
> 					- Ted