FIPS compliance includes support for dubious cryptography and protocol standards. While it doesn't necessitate things like Dual_EC and extended_random, it does create a hospitable environment for their inclusion.
"FIPS support" also demands configurations that rule out some cryptography, some of it bad, some of it reasonable. FIPS support doesn't require OpenSSL not to implement those algorithms, but it does require a mode of operation that does.
Against that complexity, the only win is the ability to deploy the FIPS-compliant code in FedGov settings, which is something that an OpenBSD fork of OpenSSL doesn't need to do to be successful.
Also, I believe that only binaries can be FIPS certified, not source code, so there are times when one has to use an old, out-dated openssl binary in order to be compliant.
OpenSSL FIPS certification (#1747) is for source code, not for binary. This is highly unusual indeed, but it is not the case that only binaries can be FIPS certified.
On the other hand, you can't change the source without losing the certification, so it doesn't actually matter.
I think the GP is talking about a trusting trust attack on OpenSSL: Change the compiler to compile OpenSSL differently, rather than change the source itself.
I guess it begs the question (FIPS mode seems to fail the "talk to a cryptographer rule"): why don't/aren't sec folks more involved to assure standards are meaningful? Was this a NIST-driven process or was it open to public comments?
Rather than explain (which I would fail at), let me cite the best sources I know of.
Here's the bug I submitted to the chromium project while I beta tested the Cr-48, requesting FIPS support. The closeout comments cite excellent sources. Interesting that this was done right about the time the Heartbleed bug was probably being found as well.
The tactic that the OpenSSL project took to get the FIPS 140-2 validation, but to avoid having to do it over again every time a new openssl release was issued, was to build all the parts of openssl that were audited into a single object (fipscanister.o) that is to be loaded at run time. It is stored at some location on the machine along with a fingerprint, and when one enables FIPS mode, fipscanister.o's fingerprint is confirmed, and then the object is loaded.
In practice, what this means is that you take one of the fips-openssl-x.y.z releases, and build fipscanister.o from it; that has the fundamental crypto bits in it, it's released as infrequently as possible. Then you build a plain old openssl-x.y.z release with a flag to enable the fips feature. At runtime when you enable FIPS mode, your local openssl library would switch to using crypto functions from fipscanister.o, which might be a year or two old. The idea is that the crypto bits don't generally change, although the rest of libssl/libcrypto might change several times during the year.
Anyway building and using openssl this way is a giant pain in the ass, especially if you statically link. To make matters even more confusing, Redhat took an altogether different tack, and have their own variant of openssl that, when FIPS mode is enabled, switches to using the Linux Kernel crypto functions, which they got independently NIST validated, so if you're deploying the RHEL machines in the .gov space, a different FIPS 140-2 validation applies to you.
It leads to a fair amount of crap in the configure scripts, and macros throughout the code.
My understanding is the FIPS requires that the SSL library implements a certain suite of protocols (including the Dual EC DRBG discussed in the linked mailing list post) which have known cryptographic weaknesses.
FIPS requires that any 'approved' included crypto algorithm implementations are self-tested, and pass a verification program (just a big bunch of somewhat poorly conceived known answer tests).
It also has a list of 'allowed' algorithms, which don't need to be tested but can be offered by a FIPS crypto module.
The CSPRNG used for key generation must be of an approved construction, but there are a number of choices ranging from stupid shit nobody sane would choose (Dual EC DRBG) to ones which are trivial variations on hashes, HMAC or block ciphers in OFB or CTR mode. Sadly, it says nothing about the quality or construction of actual entropy sources.
Naturally, everything not 'approved' or 'allowed' cannot be offered by a FIPS crypto module.
On the plus side, this means vendors can't offer proprietary stupid-shit like LFSR stream ciphers. Unfortunately, the approved and allowed list rarely keeps up with good quality or fixed crypto (you'll not find any eSTREAM finalists, or EdDSA, or deterministic DSA, or curve25519 ECDH, for example).
Also, the rules are pretty poorly enforced: you'll still find new FIPS certificates issued for boxes which do TLS < 1.2. This is a lie: MD5 is not allowed or approved, and is a fundamental (if conservatively used) part of the protocol in those versions.
Source: I used to make FIPS-approved HSMs. AMA? :)
A question if I may:
Could you "accidentally" make a FIPS compliant library? Assuming that the LibreSSL fork where to include ONLY the FIPS approved ciphers and hashing algorithms, it should be possible to have a library that could be passed of a compliant.
If I understand you correctly, the issue with FIPS is that you would have to be able to disable all but a subset of the features, regardless of these feature being worse or better than what is defined in the FIPS documents?
That's a bit more that one question, but I would like to know. Thanks.
It is not just that the library can only contain those specific approved ciphers and hashing algorithms, they also have to be certified through a lab, then that lab has to sign off on it (this costs thousands of dollars). You have to build in a self-test system that verifies the integrity of the FIPS components using known answer tests, and the FIPS module itself has to be able to self-check itself against a known hash, so your linker has to be nice enough to put the FIPS module at a known location (making exploitation simpler).
The whole FIPS canister thing in OpenSSL is a HUGE pain in the behind when you are building a library/product using it, and overall doesn't increase security one single bit. Yes your crypto is now FIPS 140 certified, big whoop.
[Note: I am going off the OpenSSL FIPS canister implementation details here...]
> Could you "accidentally" make a FIPS compliant library?
Let's differentiate between "FIPS compliant" and "FIPS certified".
FIPS complaint: you could get a FIPS certified product if you wanted, without changing your product.
FIPS certified: you paid NIST and a FIPS test lab some money, the lab tested your module, submitted a test report to NIST, and NIST published certificates saying that a certain version of your product (running on a particular OS and CPU architecture, for software modules) is FIPS certified.
So, yes, you could accidentally come up with a FIPS compliant crypto module. But getting certified costs actual money (last time I did it, as I recall just shy of $100k).
> the issue with FIPS is that you would have to be able to disable
> all but a subset of the features, regardless of these feature
> being worse or better than what is defined in the FIPS documents?
To some extent it depends what you mean by 'feature' here. If it's a crypto algorithm offered by your module for external use, there is quite little leeway. If it's a fundamental feature of your product that internally uses exotic crypto, you can often convince your test lab to gloss over it.
Thanks for the correction. I'm on the hardware side of things, so my understanding was that the "allowed" algorithms were actually required, and I'm relieved to hear that's not the case.
Worse than that, AFAIK, the cheapest way to keep up FIPS certification is essentially to change nothing (except as FIPS requirements change, which is "not really often").
