Implementing a FIPS 140-2 validation into your product is a great way to strengthen your solution, enhance your brand, and secure your bottom line. When pursuing FIPS, you will be faced with difficult and often confusing decisions; leaving you with many questions. One such question we are always asked is the difference between being FIPS Validated and FIPS Compliant (sometimes referred to as FIPS Inside). But first, lets take a step back and uncover how the difference arose.
Early on in the pursuit of validations for cryptography-enabled products, the roadmap was clear: a crypto device meant for federal networks processing SBU information needed to undergo a FIPS validation. These products were hardware-based, and the standards written against which they’d be evaluated were written with hardware-based solutions in mind.
Fast-forward to today. Continuing improvements in cryptography has resulted in solutions that come in many forms, including software, hardware, firmware, and combinations thereof. To address the changing landscape of cryptographic enablement, the FIPS standard also had to change over time. Vendors were no longer locked into FIPS validations that targeted appliances. FIPS validations could be performed on sub-components such as server blades, embedded cards, crypto chips, and even software libraries. With the proliferation of such solutions, the concept of FIPS Inside was born.
What is FIPS Inside?
FIPS Inside is a term used to reference a device or appliance that employs a FIPS-validated subcomponent to provide its cryptographic services. This became an attractive validation alternative, particularly for vendors that only developed software, or for those that wanted to insulate their validation status from non-security-related product changes.
The option of validating a software-based FIPS Inside solution opened the door for third-party vendors to develop, validate, and market their own cryptographic solutions. Open-source libraries like OpenSSL, Crypto++, and NSS, as well as licensed libraries like RSA’s BSAFE and Mocana’s Crypto Module, have been heavily leveraged over the past few years because they offer a “plug and play” validation solution. Vendors needing to make the claim of using FIPS-validated cryptography would simply integrate these third-party libraries into their proprietary code, and voila! Mission accomplished!
Or was it?
Is FIPS Inside Right For Me?
The FIPS Inside validation approach is very convenient, and can, in fact, be a viable option in certain situations. The optimal scenario is that the vendor of the device also controls the targeted subcomponent. However, when relying on a third-party’s software solution, this path also comes with its share of very real pitfalls.
It provides very limited assurance:
Recall that the primary goal of a FIPS validation effort is to provide assurance that a cryptographic module is in conformance with the standard. This assurance comes from the knowledge that the module was independently tested by an accredited testing lab whose work was reviewed and approved by an oversight body made up of representatives for both the U.S. and Canada. That’s very powerful, and when a vendor undergoes a FIPS validation process, the resulting certificate is very marketable. However, when a vendor relies on another vendor’s certificate, the story of assurance grows considerably weaker. As a potential product consumer, which statement would you find more assuring:
“You can trust our product, because we’re trusting someone else who went through the FIPS validation process and received a certificate! Further, although we provide no proof, you can trust that we’re using that FIPS-validated product exactly as specified in other vendor’s security policy!”
or
“You can trust our product, because we went through the FIPS validation process and received a certificate! Our algorithms and module functionality were tested and found conformant … and as proof, here’s a link to our module’s entry on NIST’s Validated Modules List!”
Your product becomes dependent on a third-party’s issues and schedule:
If your third-party crypto library is discovered to have a conformance issues, then you’ve just inherited their conformance issues. Their validation may have just been revoked, so your claims of using FIPS-validated crypto functionality are no longer true. What do you do?
You do have options. If it’s a licensed library, you can buy the update. If it’s an open-source library, you can download the new release and integrate it. But in both options, you have to hope that the conformance issue is important enough to the third-party developers to (a) make the fix at all and (b) complete the fix AND re-validate in a timeframe that fits your own business pursuits. And in both options, you’re forced to wait.
When competing for time-sensitive business opportunities, waiting is not always an option. A loss of your positioning due to a third-party’s change in validation status could cost you millions of dollars in unrealized revenues and lost opportunities.
It limits your ability to compete:
Using a third-party crypto solution is a clear indication that you are not fully responsible for your product’s security functionality. In today’s security-aware industry, purchasers are looking to vendors that are performing their due diligence and taking ownership of security. In the absence of an independent FIPS validation (which provides assurance that’s accepted industry-wide), many questions will be raised about a product’s security capabilities and viability for processing SBU information.
There was a time not long ago that the U.S. Army had its own Approved Product’s List, and product vendors needed to have their own validation certificates in order to be added to this list. Today, many purchasers in the U.S. federal space still feel strongly that a vendor should obtain all of the necessary validations in order to be considered for purchase … reliance on third-parties is just not as acceptable as it once was.
It brings your company’s commitment to security into question:
Again, there are scenarios where incorporating a FIPS-validated third-party cryptographic library (FIPS Inside) into a bigger solution makes sense. But how much do you really know about that library? Consider these questions:
- Which algorithms are implemented in the library?
- Which algorithms does your solution use from the library?
- Does the library have any built-in backdoors?
- Is this the most recent version of the library?
- Does the library meet all current FIPS requirements?
- Does the library generate keys in a FIPS-Approved manner?
- Was the library built as specified in its published Security Policy?
These are very fair questions, and they are questions that any vendor should be able to answer about their own product. However, many vendors today will integrate a crypto library with a full understanding of what just got added to their solutions’ codebase … they simply trust it to work.
Conclusion:
There’s nothing wrong with trusting an embedded FIPS-validated solution. But if these questions can’t be answered, it makes it very difficult to vouch for your own product’s security, and if you can’t truly vouch for your own product’s security, that becomes a reflection of your true commitment to providing a secured solution.
When choosing a strategy to meet strict security conformance requirements, as in any business decision, one must gather as much information as possible in order to make an educated decision. Factors such as convenience, resource availability, time-to-market, sustainability, long- and short-terms costs, benefits, and risks must all be weighed to determine the most viable course of action. While integrating a third-party crypto service solution in order to meet FIPS requirements seems like the best choice (and sometimes, it actually is), there are a growing number of business-related drawbacks to this path that must be identified and weighed. Choosing a path with taking these drawbacks under careful consideration could impact your validation status and ability to compete for years to come