In our last blog post, we looked at why FIPS compliance is fundamentally different from and not nearly as desirable as achieving FIPS validation. Some organizations try to address this problem via a “rebranding” process where they work with a lab to duplicate an existing third-party CMVP certificate in their name. Doing so requires getting permission from the certified module’s OEM. Some open-source projects now offer to do so for their clients, usually for a yearly fee. After a rebrand, the organization will have a certificate in its name listed on the CMVP website. Does that solve the problem? Only temporarily, because, as we have mentioned previously, attaining certification is only part of the problem. Maintaining it over time is far more challenging.
Here at SafeLogic, we know a lot about rebranding. SafeLogic revolutionized the FIPS 140 validation industry over a decade ago. We started offering an accelerated FIPS 140 validation journey that allowed organizations to get their own CMVP certificates in under eight weeks instead of 18-24 months. At the heart of that innovation is rebranding, a technique that essentially creates a new certificate by inheriting from a base CMVP certificate that corresponds to a previously validated FIPS 140 module. We call that RapidCert. Since then, other companies have begun to leverage the same technique to get somebody else a certificate in their name quickly.
With all our experience with rebrands, we can say unequivocally that rebranding is not enough. Not even close. Yes, it gets an organization its own certificate quickly, but that is it. It is a snapshot in time. The initial certificate that CMVP grants may indicate that it is good for about five years. However, that unfortunately will not be the case. Unless the certification and the associated module are properly maintained, it will become historical very quickly and will no longer be valid.
How often do certificates go historical? The answer is very often. In fact a quick review of the CMVP databases shows that 3,559 of the 4,500 certificates listed are currently Historical! That means only 20% of all FIPS certificates can be used to support new procurements.
That is why SafeLogic has a managed service called MaintainCert that maintains software and certifications for our clients in a white-glove fashion.
Let us examine more specifically why rebranding is not enough.
FIPS 140 requirements are constantly changing because of Moore’s Law and because the cryptoanalytic techniques of adversaries are not standing still. When NIST changes FIPS 140 requirements, CMVP will have what it calls a “transition.” That means that cryptographic module developers must update their modules and associated documentation, get the labs to perform additional testing, and then get CMVP to review the changes. Without going through this process, the previously validated FIPS 140 module and the associated certificate will go historical and can no longer be used.
These transitions may involve factors such as changes in allowed algorithms, changes to key sizes, changes to wrapping/padding schemes, etc. Transitions tend to happen about every 6-12 months, sometimes cutting the useful lives of certificates quite significantly below their theoretical five-year sunsets. In fact, a transition occurred in 2022, and roughly 50% of previously active FIPS 140 validated modules did not survive it. The bottom line is that someone must keep doing significant work to maintain the certificate and the underlying module to keep up with the latest FIPS 140 standards.
Outside of FIPS 140 requirements changing, new security vulnerabilities are continuously being discovered. If fixes to these security vulnerabilities fall within the cryptographic boundary of a validated module, the fixed module will need to go through lab and CMVP validation processes again. The certificates may then need to be updated as well. This is also where a cryptographic module’s original design and implementation matter. A poorly designed module may be very difficult to maintain and require constant revalidation efforts.
Sometimes, the FIPS 140 validated module must be tested in an organization’s specific operating environment (OE). In those cases, an organization will need someone to help with that testing, work with the lab, and then work with CMVP to update its certificates with its own tested OEs. For instance, Common Criteria requires such a testing regimen.
Operational testing may also be required if an organization wants to add an OE to the certificate not part of the initially tested configuration. Algorithm testing may also be necessary when an organization wants to add an additional cryptographic algorithm to its certification. In those cases, much extra work will need to be done as part of the rebranding effort or afterward.
Many potential administrative changes may also require working with the lab and CMVP to update the certificate after the initial rebrand. These may include organizational name changes, product name changes, product version updates, operating system updates, etc. All of these mean additional work must be done to keep everything up to date.
The above examples hopefully demonstrate that attaining a CMVP certificate, even if done in an accelerated manner via a rebrand, is not a one-and-done deal. FIPS 140 validated modules and their certificates must be maintained to ensure everything remains up to date, active, and in good standing for when the organization needs them to win a key public sector deal.