OpenSSL FIPS 140-2 - Part One - Security and the infinite regress fallacy

Building the FIPS object module for OpenSSL must be done in a very strict manor. Deviation from the mandated compilation instructions means we cannot consider the resulting binaries as validated. They would then require “private label” validation that costs thousands of dollars. Let’s try to avoid that, shall we?

The OpenSSL and FIPS object module source code can be downloaded from the Internet. However, the build won’t be valid for FIPS 140-2. Why not? The FIPS tarball wasn’t obtained through a “trusted path.” From section 4.1 of the User Guide for the OpenSSL FIPS Object Module v2.0:

The CMVP introduced significant new requirements for verification of the 2.0 source code distribution. This requirement is discussed in more detail in §4.1.3; but in summary, it can no longer be downloaded and used as before. A “trusted path” must be used for transfer of the source code distribution.

At present the one method known to satisfy the “trusted path” requirement is obtain the source code distribution from the vendor of record (OVS) on physical media (CD). For instructions on requesting this CD see http://openssl.com/fips/verify.html.

You may ask, “What about a SHA-256 hash? Isn’t that good enough? Maybe SHA-512? GPG public key encryption?” Nope. A physical disc must be mailed to you.

Okay, I get it. The whole point of the FIPS module is to ensure the encryption algorithms used by OpenSSL meet the standards put forth by the National Institute of Standards and Technology (NIST). There’s no difference between the encrypted files produced by the regular OpenSSL build versus the FIPS ones, but the source code of the standard strong OpenSSL ciphers probably won’t meet the NIST’s high standards. Fine. We’ll use the FIPS object module. How do we know the FIPS object module that’s been downloaded hasn’t been tampered with? Here’s section 6.6 of the User Guide for the OpenSSL FIPS Object Module v2.0 titled, “The ‘Secure Installation’ Issue” in its entirety:

This latest of the OpenSSL FIPS Object Module (“FIPS module”) FIPS 140-2 validations saw the introduction of a new requirement by the CMVP:

The distribution tar file, shall be verified using an independently acquired FIPS 140-2 validated cryptographic module...

We’re told that this distribution tar file verification requirement comes directly from the assertions AS10.03 and AS14.02 of the Derived Test Requirements document:

AS10.03: (Levels 1, 2, 3, and 4) Documentation shall specify the procedures for secure installation, initialization, and startup of the cryptographic module.

AS14.02: (Levels 1, 2, 3, and 4) The cryptographic module security policy shall consist of: a specification of the security rules, under which the cryptographic module shall operate, including the security rules derived from the requirements of the standard and the additional security rules imposed by the vendor.

Subsequent discussions mediated by the test lab elaborated this “secure installation” requirement to mean that one of the following conditions must be true:

1. The distribution file is obtained via a “trusted path”, which is one of:
   1. Transfer via physical media (e.g. CD-ROM disk) sent by postal or delivery service (USPS, UPS, FedEx);
   2. Electronic transfer using cryptography (e.g. SSH, HTTPS, IPsec) implemented by FIPS 140-2 validated products. That requirement was further elaborated to state that those products must themselves be a result of “secure installation”.
2. The distribution file is verified (HMAC-SHA-1 digest checked) using a pre-existing FIPS 140-2 validated product that is itself the result of a “secure installation”.

Note the recursive nature of the “secure installation” requirement represents a non-trivial challenge; in order to transfer or verify a new validated product an existing securely installed validated product must already be present. We’re still struggling to understand the scope and implications of this requirement. The FIPS 140-2 scripture (The FIPS 140-2 standard [Reference 1], the DTR [Reference 4], and the IG [Reference 3] documents) doesn’t shed a lot of light -- the term “trusted path” for instance is only referenced in the context of Level 3 validations. Note those “secure installation” and “trusted path” requirements as explained to us say that validated software cannot be distributed by traditional methods, which leads to some interesting questions about the use of other validated modules (puzzlement over why all other modules aren’t similarly impacted is a large part of our confusion). Those questions aside, prospective users of this FIPS module need to determine at least one known valid way to satisfy the requirement for this specific validation -- a way not at risk of being ruled invalid by the CMVP after software has been shipped or deployed.

So far the CMVP has declined to answer specific questions about options for satisfying this requirement; they quote the formal documentation (as noted above) and refer us to the test labs. We have actively discussed this issue with several accredited test labs and selected members of the FIPS validation community. Unfortunately the test labs are not in close agreement. So far we have collected a lot of opinions but not much certainty. If you have experience or insights directly relevant to this issue we’d love to hear from you⁵⁰.

Very Important Note:

The conclusions presented here are still tentative as they have neither been confirmed nor refuted by the CMVP; they simply represent our best understanding of the situation at this point in time. These conclusions could change dramatically based on relevant feedback from the CMVP, or more slowly in response to an accumulated consensus of opinion from the test labs and FIPS 140-2 community of interest.

I don’t blame you if your eyes glazed over reading that and decided to skip down here. Part of the issue is a chicken-and-egg problem. Let’s say there’s a file server with a valid tarball of source code. It has to be transmitted with a FIPS approved encryption layer. Let’s also assume the sender has a proper FIPS encryption setup, but the receiver doesn’t. How can it be securely transmitted across the Internet? The receiver needs the source code to build a FIPS compliant encryption layer, but they can’t download it because they don’t have a FIPS compliant encryption layer! The only option left is to send it though the mail. Yes, the MAIL! What about a SHA-256 hash? Nope. The tools to generate the hashes aren’t FIPS certified. What if the receiver had a FIPS compliant copy of OpenSSL (somehow) and used that to run a hash on the downloaded source code? Nope! Not allowed. Why not? Even if there was a FIPS approved secure network encryption layer, there’s no agreement on how to ensure a “secure installation” exists. How can the source code be verified as valid on an environment that cannot be known to be secure?

I trust the available non-validated utilities that generate SHA hashes more than a disc sent through the post office. The NIST cannot allow it since that would be hypocritical. How can they demand the use of FIPS 140-2 encryption software if the encryption used to transmit and/or validate isn’t held to the same standards? The alternative bypasses this issue entirely since it involves a non-electronic transmission method. Ironically, the risks involved with that method are hand-waved away.

These kinds of absurd security protocols are a frequent source of irritation. Let’s say that I need to sign an important document and the other party wants to ensure I am who I say I am. No problem. Go to a notary public and let them witness and certify my identity. How do I and the other party know the notary public is who they say they are? Whoops! Get a notary to validate the other notary? Who validates that notary? An endless recursion of notaries doesn’t happen in real life. We as a society have decided that one notary provides verification with a reasonable level of risk of failure. This kind of common sense cap on verification is unfortunately absent in our endeavor to validate OpenSSL. It reminds me of the anecdote illustrating the infinite regression fallacy.¹

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!”

The Sisyphean security standards of the FIPS module apparently don’t apply to the rest of the process. Why shouldn’t they? I put in my request for a CD of the FIPS object module source code and received it a few days later. I have officially obtained it though an approved method. The source code is secure. Huzzah! What about the OpenSSL source code? Can I just download that from the Internet? Apparently I am allowed and expected to do just that. What about the compiler? Can I download it over the Internet using a non-FIPS approved secure encryption layer? Heck, maybe even no layer! What about the operating system that allows the compiler to run? What about the hardware and firmware the operating system is running on? Has the motherboard BIOS been vetted? Have I been vetted? Symantec, McAfee, and WinZip had their products vetted, but how do we know those products haven’t been tampered with after the fact? How can we verify the product purchased is valid considering we no way to ensure our environment is “secure?” How can anyone? It’s turtles all the way down.

The most ironic thing is that the validated FIPS 140-2 OpenSSL binaries that I have built probably can be distributed over the Internet regardless of the security protocols and retain its status as verified. If I’m wrong about that, then how do any of the other companies who offer products validated for FIPS 140-2 distribute their software?

Part two of this series will explain how to build OpenSSL with the FIPS object module on Unix operating systems. Part three will tackle Windows operating systems.

References

1. Hawking, Stephen W. “Our Picture of the Universe.” A brief history of time, Bantam Books, 1998, p. 8.