Why FIPS 140-2?
One of our customers recently approached us with an interesting use case inquiry. The goal was to leverage Device42 to audit their entire SSL certificate deployment for FIPS-140-2 compliance, but they didn’t have a good way to determine which ciphers the certificates were using.
Device42 has featured SSL certificate autodiscovery since v6.5.0, but wasn’t pulling the cipher data in. We quickly realized the benefit pulling in this data offered, and our dev team tweaked the certificate discovery module to pull & display SSL cipher data.
Meanwhile, we wanted to learn more about the NIST standard FIPS 140-2. While researching, we noticed that though there were a lot of resources scattered around, including plenty of references to the standard itself, there weren’t too many that gave an easy to understand, high-level overview of FIPS 140-2. Since we did the legwork, we’re sharing!
What is FIPS 140-2, anyway?
TL; DR – Software and hardware companies should understand that FIPS-140-2 is much more than a good standard for your marketing material. If your product uses cryptography, and there are plans to sell to the US Federal government, FIPS-140-2 validation is a legal requirement. Only NIST can certify your product “FIPS-140-2 Validated”, but you can audit yourself to prepare for submission to NIST, and Device42 can help you. Finally, note that buying FIPS-140-2 validated software doesn’t guarantee security; validated software can sometimes be operated in a non-compliant mode.
FIPS stand for ‘Federal Information Processing Standards’, and each is followed by a number or set of numbers to identify the exact standard being referenced. In general, FIPS standards reference security and cryptographic standards that have been approved for use in computing systems used by the United States Federal Government.
FIPS-140-2 was authored by NIST (National Institute of Standards and technology) on 5/25/2001 for the purpose of coordinating the requirements and standards for cryptographic modules that are procured from both private sector and open source community sources. FIPS compliant software can be utilized to protect “Sensitive but unclassified” information in possession of both the US Government, and industries it regulates [e.g. healthcare & finance].
FIPS-140-2 was last updated on 12/03/2002, and there were plans to update every 5 years. FIPS-140-3 was drafted and announced 1/12/2005, but was never formally released. In the interim, ISO developed a standard based on the FIPS-140-3 draft: ISO/IEC 19790:2012.
FIPS-140-2 ‘Compliant’ vs. ‘Validated’ (vs. FIPS Inside)
“FIPS-140-2 Compliant” is a marketing term. Products claiming FIPS 140 2 compliance are self designating, and this terminology is often used in reference to products that utilize FIPS-approved algorithms or libraries, but themselves have not taken the necessary steps to complete NIST’s FIPS-140-2 validation. Designing software in accordance with FIPS regulations is a great idea to help ensure that the software design is secure, and will also help should NIST’s “full validation” be sought in the future – but in and of itself, is not validation.
“FIPS Inside” refers to products that similarly have incorporated a cryptographic module (that is itself FIPS Validated). Designing a software product around a FIPS-validated module is a great way to quickly bring a saleable product to market at reasonable cost, however, the overall product itself is not FIPS-140-2 compliant. In the case of “FIPS Inside”, only the cryptographic module has completed validation. Although embedding a FIPS-validated product is acceptable, this in-between compliance level may only suffice for certain government use cases, as further additions to a codebase could compromise security outside of the validated module.
“FIPS-140-2 Validated” denotes software that has undertaken the FIPS-140-2 validation process. In this case, a certificate of validation is issued by NIST that declares your software or system compliant with FIPS-140-2 and issues a “FIPS Verified” certificate. Per Congress, the now FIPS-verified software is eligible for US government procurement and use. Though this full validation route is the most expensive, it leaves no questions as to software’s FIPS security status.
The Four Security Levels of FIPS-140-2
FIPS-140-2 is broken down by NIST into four cryptographic security “Levels”. The different levels are aimed at protecting different classes of data, higher levels for data deemed more sensitive.
Do keep in mind that FIPS-140-2 isn’t meant for any data that is deemed classified by the US Government; all four levels target unclassified data. See the link for an in depth look at each of the four levels and their specific requirements, as they’re beyond the scope of this article.
Nonetheless, here is a high level overview the four levels of FIPS validation:
- Level 1: The least secure level.
- Level 2: Improved physical security vs. level 1 with tamper evident coatings or seals protecting cryptographic keys.
- Level 3: In addition to Level 2 protections, “CSP’s (critical security parameters) protected at this level attempt to render themselves unusable if modification or forceful access is attempted, including strong enclosures and active tamper detection circuitry. This level provides for identity-based authentication.
- Level 4: The highest security level defined by the standard. Devices that meet this level must meet all previous, plus provide ‘reasonable assurance’ that the modules will operate properly even during exposure to extreme environmental conditions [high voltage, temp swings, etc.]
Each of the above FIPS-140-2 security levels has its own set of detailed testing requirements, which is handled by third party laboratories that are accredited as “Cryptographic Module Testing Labs”.
Getting a FIPS-140-2 Head Start:
Officially Certifying software or hardware “FIPS 140-2 Validated” is something only NIST (specifically, one of its 13 validation labs) can do. You can, however, get a head start. Many of the documents you’ll need are part of normal software development cycles, and the list provided by NIST is below. The different security levels of FIPS-140-2 validation each have different documentation requirements, but all levels draw from this list:
|
|
|
|
|
|
|
|
|
If your SDLC didn’t produce the above documents, preparing for a FIPS validation audit could prove a very involved process. As an alternative, you might choose to certify only parts of your application. Another more easily attainable alternative is using an algorithm that is already FIPS Validated, creating a “FIPS Inside” application, which can still be offered for sale to the US Government.
Per FIPS Annex A, the following list of cryptographic algorithms is certified by NIST “FIPS-140-2 Validated”, all theoretically being candidates for use in a “FIPS Inside” application.
FIPS 140-2 Annex A – Compliant Algorithms:
- Symmetric Key
- AES, Triple-DES, Escrowed Encryption Standard
- Asymmetric Key
- DSA, RSA, ECDSA
- Hash Standards
- SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256
- Random number generators
- See annex c
- Message authentication
- CCM, GCM, GMAC, CMAC, HMAC
Even if you aren’t building hardware or software, this list can still be useful to you. A self-audit to ensure all of the algorithms in use across your enterprise have been FIPS validated as secure is a great step to take to help ensure the cryptography your business is using is safe and up to date.
Device42 Can Help You Ensure Your Certificates are FIPS-140-2 Compliant
The latest release of Device42 adds extra features that help audit your SSL certificates for FIPS-140-2 compliance (as well as compliance with standards like GDPR, PCI, HIPAA, CIS etc.). Device42 can discover all of your SSL certificates and can identify the Ciphers they’re using. You can thus easily know if you are operating in a FIPS-140-2 compliant manner, as the list of approved security functions / ciphers can be found in the NIST’s FIPS-140-2 PDF Annex A.
Only NIST can officially certify an individual piece of hardware of software “FIPS-140-2 Validated”. You can, however, get a head start by auditing yourself for FIPS 140-2 compliance, ensuring that when you do apply for official validation you’ll pass without issue.
Device42 can help, and it’s as easy as running an auto-discovery with “find cipher suites supported by the server” enabled. Leveraging details on in-use ciphers combined with your complete certificate inventory, the devices they are deployed on, and your entire IT asset library and its inter-dependencies means you’ll practically never come across an audit question you can’t find the answer to.
Questions? Comments? We’d love to hear any related stories you might have to share. Feel free to leave them here, or to drop us an e-mail at [email protected]
If you aren’t a Device42 user already, download a free 30-day trial and see just how easy Device42 makes documenting and understanding your infrastructure and its interdependencies.
