Are GNU coreutils SHA digest functions FIPS-validated (in NIST's Cryptographic Module Validation Program)?

Question

My Challenge

My project has a requirement that we use only FIPS-validated modules to do anything cryptographic, including generating checksums for binaries. We've been using the SHA-2 utilities provided by GNU coreutils for a long time to generate checksums. Now we need to be compliant. SHA-2 comes from FIPS-180-2, and I can't find a validation program like NIST CMVP for FIPS-180. I did see on some CMVP certifications that a Secure Hash Standard (FIPS-180) certificate was also listed, so I had hoped to find GNU holding a certification for their implementation in NIST's CMVP database, but I couldn't find one.

My Question

Can anyone point me to documentation that shows GNU coretuils is validated for FIPS-180-2 compliance? If not, I'd love suggestions for where to look for an alternative provider. I did find that Red Hat holds a certification for an OpenSSL implementation, which also lists SHA-3 and SHS certificates, Cert #3781, but that's for RHEL8 and we're on RHEL7.

Barring alternatives, is there a way to prove GNU coreutils's SHA-2 implementations are "sufficiently secure"? I feel that question is asking for trouble and a whole lot of math proofs... The GNU website doesn't say much about SHA-2. I read the source code for the utility here, but found nothing interesting.

Answer 1

I can't find a validation program like NIST CMVP for FIPS-180.

You did, actually. CMVP covers compliance for all cryptographic mechanisms approved by NIST, including the hashes defined by FIPS 180. FIPS 180 is the definition of some hash algorithms. FIPS 140 is the standard that defines what it means to be compliant. All “FIPS compliance” is compliance to FIPS 140.

I did see on some CMVP certifications that a Secure Hash Standard (FIPS-180) certificate was also listed, so I had hoped to find GNU holding a certification for their implementation in NIST's CMVP database, but I couldn't find one.

You looked in the right place. You couldn't find one because there isn't one.

FIPS 140 validation is expensive. You don't just do it on a whim: you do it because you have a clear business requirement. Furthermore, you can only validate one specific version of a program, so it's bad for maintenance (no bug fixing, no new features, no porting to a different environment, …) and it's bad for security (no bug fixing). So it's no surprise that very few programs are FIPS certified.

If not, I'd love suggestions for where to look for an alternative provider. I did find that Red Hat holds a certification for an OpenSSL implementation, which also lists SHA-3 and SHS certificates, Cert #3781, but that's for RHEL8 and we're on RHEL7.

Several vendors have certified a version of OpenSSL, including RHEL 7, which does cover the NIST hash algorithms. So you could use that.

Barring alternatives, is there a way to prove GNU coreutils's SHA-2 implementations are "sufficiently secure"? I feel that question is asking for trouble and a whole lot of math proofs...

FIPS 140 certification has nothing to do with security. In fact, it's detrimental to security, since it forbids applying security updates. If you want FIPS certification, use the certified version of OpenSSL. If you want security, use an up-to-date system.

If you care about security, the software that calculates hashes is the least of your worry: of all cryptographic primitives, they're the hardest to mess up. What you use the hashes for is more important and can be susceptible to subtle pitfalls.

Answer 2

The coreutils implementations are almost certainly not validated. Generally, FIPS validation requires submitting a binary for approval and getting that implementation certified, and it costs a decent amount of money. As a result, generally distro vendors certify only entire cryptographic libraries, since that reduces the costs of certification by allowing the greatest amount of reuse across binaries and libraries. Since the FSF generally doesn't distribute binaries except as part of their own distros, the likelihood that they would hold a certification for any software is quite low.

I should also point out that while this doesn't apply to RHEL 7, since it's too old, RHEL 8 ships b2sum, a BLAKE2b implementation, as part of coreutils, and that wouldn't be permitted if they were FIPS validated, since you're not allowed to include unapproved algorithms like BLAKE2b. However, people would be rightfully upset that the coreutils were incomplete if they were missing useful and valuable binaries in such a case. That further lends credence to the fact that they are not validated.

A reasonable person could perform tests on the coreutils binaries with a set of test vectors and a shell script and conclude that the digests are properly implemented. In fact, I'm certain that the coreutils testsuite contains adequate tests to exercise the relevant code paths, and I believe they are sufficiently secure. Certainly they interoperate with a variety of other implementations, and the likelihood that all known implementers have made the exact same mistake is very low.

However, if your project has a requirement that only FIPS-validated modules can be used, then you're looking for a rubber stamp for compliance purposes, and not an assessment that the code is properly implemented and secure. There are many secure implementations (and algorithms) which are not FIPS validated and the coreutils binaries are generally considered to be one of them. As a result, you should probably contact Red Hat for a FIPS-validated OpenSSL version and use that for your compliance needs.