FIPS 186-2 Restrictions in CMVP's Implementation Guidance G.18

After several false starts and revisions, Implementation Guidance G.18, governing the use of FIPS 186-2 in FIPS 140-2 validated encryption modules, has been published and finalized. As always, consider this blog post purely informational, since our strategic advice is ultimately and consistently the same - use CryptoComply, get a RapidCert, and let SafeLogic take care of these details to keep your validation perpetually active.

That said, let’s dive into it.

The FIPS 186-2 Digital Signature Standard was replaced by FIPS 186-3 in June 2009 and subsequently by FIPS 186-4 in July 2013. Oddly, however, algorithm testing for FIPS 186-2 has continued and has been accepted for FIPS 140-2 validations. Earlier this year, CMVP announced that this alg testing would cease on December 31, 2019, and even more impactful, validations that included 186-2 testing would be moved to the Historical List on the very next day. 

Does it seem odd to have them converge on the same date? The industry thought so.

After a fair amount of discussion, it was both pushed back and separated. No longer will a module be able to successfully test for 186-2 and be blacklisted for it literally the next day. Testing will now cease on July 1, 2020, while September 1, 2020 marks the banishment to the Historical List.

This extra 6/9 months will buy time for folks to figure out how to modify existing modules to conform with 186-4 requirements and to avoid the Historical List… except for the many modules currently FIPS 140-2 validated list that either cannot or will not make alterations. Highest profile among this group? OpenSSL’s three remaining certs: #1747, #2398, and #2473.

OpenSSL has been vocal about their stance. These three validations, all based on the FIPS Object Module 2.0 and built for the OpenSSL 1.0.2 architecture, are static and will not be altered. This ensures that all three validations, along with the many, many validations completed in the last 7+ years based on these modules, will be archived and banned from Federal procurement on September 1, 2020.

Beware consultants that claim that these modules (and their descendants) are still acceptable for use as long as they have already been “installed”. This is an extremely gray interpretation of a pretty black-and-white issue. If a current customer that has already deployed your solution, reliant on a #1747 clone, wants to purchase more seats, is that kosher? What if your solution has already been released - does that count as “installed”? The answer should be a resounding “NO!” Your solution is no longer leveraging a validated module and it doesn’t matter whether it is in development, already released, already sold and deployed to one federal agency or one hundred. It doesn’t matter whether a buyer is an existing customer or even an existing user of that exact solution. Your FIPS module will be obsolete on September 1, 2020 and the onus is on you to replace it.

I realize that OpenSSL hasn’t left you very many options. Ok, ok… they haven’t left you any options at the moment. But let’s be honest. You were always dancing on the edge of a razorblade, trying to claim “compliance” while everyone else was deploying a module that carried a full FIPS 140-2 validation in their own name. And if you decided to whitelabel an OpenSSL validation just to try to save a few bucks, you knew the risk. Without someone actively maintaining the module and the validation, you were in danger of landing in this exact situation.

All is not lost, however. If you’re here, you’re probably looking for answers. Maybe your search terms were “OpenSSL FIPS module replacement” or something similar. 

Don’t worry, we have you covered. SafeLogic’s CryptoComply is actively and aggressively maintained, so our validation and our customers’ RapidCert validations will not evaporate. In fact, we’re more committed than ever to our future roadmap, and that includes OpenSSL.

In 2020, we will be providing Extended Support for vendors who are reliant on the OpenSSL 1.0.2 architecture. This will keep it patched for vulnerabilities after the End of Life on December 31, 2019. Folks who are not using FIPS have generally migrated to OpenSSL 1.1.1 at this point, so this is really for those leveraging FIPS mode. Without a FIPS-capable stack to move to, they are stuck on 1.0.2 and need insurance for potential issues. (Hackers are salivating at the idea that there will be a myriad of unpatched 1.0.2 deployments next year. You can bet on them doing their worst, come January 1, 2020. This will prep you for combat.)

Of course, even if you retain SafeLogic for the Extended Support of OpenSSL 1.0.2, if you are deploying the OpenSSL FOM or a clone with a dependent validation certificate, you’re going to need a new plan for September 1, 2020. Complicating matters, OpenSSL has publicly stated that they have experienced their own delays with the 3.0 architecture, which will restore FIPS capabilities to the OpenSSL stack. So even with CMVP's delayed date for moving modules to the Historical List, and even if you engage with us for Extended Support, there will be a gap in time in which you will not have a FIPS validated module… unless you deploy CryptoComply.

We are ready whenever you want to discuss the details of your use case!