What is FIPS 140-2 Compliance?
If your work involves liaising with US government IT, or you produce hardware and/or software solutions you hope to supply to the US government, you will likely have heard of FIPS 140-2 compliance, but what does it mean to be FIPS compliant, and should it matter to you?
What does FIPS stand for?
The acronym “FIPS” refers to the, “Federal Information Processing Standards”. The FIPS 140 series are computer security standards set by the National Institute of Standards & Technology (NIST) for the US government.
Glossary of Terms
The FIPS 140-2 compliance standard deals heavily with encryption keys and physical protection of them. For those seeking to understand what this all means, but aren’t cryptographic professionals themselves, here’s a breakdown of some essential terms.
- Cryptology – Deals with the research and development of secure communication methods, including the development and advancement of encryption and other methods of keeping data private and secure
- Cryptographic Key – A plaintext series of characters used by an encryption algorithm to encrypt or decrypt text
- Cryptographic Module – A device that handles encryption, decryption, digital signatures, user authentication, and random number generation
- Critical Security Parameter (CSP) – Per the NIST Glossary, CSPs include security-related information whose disclosure or modification can compromise the security of a cryptographic module
- Common Criteria (CC) – Also known as the Common Criteria for Information Technology Security Evaluation. Serves as the technical basis for the Common Criteria Recognition Arrangement (CCRA), an international agreement ensuring that security products are adequately tested by independent licensed laboratories
- Encryption – The process of encoding a message or file, typically with an algorithm designed to be impractical to reverse engineer, so that only authorized parties can view it
- Plaintext – Text that hasn’t been hashed or obfuscated by an encryption algorithm. Any casual onlooker can view and read unsecured and/or unencrypted plaintext
What is the FIPS 140 Series?
FIPS 140 is the set of requirements and standards for cryptographic modules for both software and hardware components for use by US government departments and agencies. FIPS 140-2 is the second and current (as of this blog’s publication date) set of FIPS 140 standards issued by NIST. Released May 25, 2001, FIPS 140-2 expands on FIPS 140-1 (issued Jan. 11, 1994), leverages Common Criteria (CC) Evaluation Assurance Levels (EAL) to determine security level, and considers community feedback as well as new IT developments and technologies since 1994.
It is important to note that while these standards address cryptographic and security standards for both hardware and software, a product’s adherence to FIPS 140-2 does not guarantee security. FIPS 140-2 is only intended to apply to cryptographic modules interacting with workloads managing sensitive but unclassified (SBU) information.
What are the Evaluation Assurance Levels?
Common Criteria establishes seven (7) different Evaluation Assurance Levels (EAL) aptly named EAL1-EAL7. It is also common to see a “+” next to a given EAL (e.g. EAL5+) to signify a given device has met certain requirements beyond the minimum for a given EAL. Since the highest level of FIPS 140-2 only requires EAL4, we will only discuss EAL1-EAL4 in this blog.
- EAL1: Intended for Targets of Evaluation (TOE) where threats to security are not viewed as serious, but there is a need for confidence the implemented security works as intended. EAL1 is valuable for supporting the claim that a given organization has put due care into protection of personal information
- EAL2: Ideal for products that need a reasonable assurance of security when the development record for a TOE is not available, such as with longstanding legacy IT environments
- EAL3: Designed to provide a moderate level of assured security. EAL3 looks at the TOE in more depth, including its development. This level is ideal for organizations with solid security engineering practices baked in at the design level and who don’t expect to need to significantly re-engineer the TOE
- EAL4: The highest level that is economically feasible to retrofit to an existing product line (that is, the testing and re-engineering of products not built with higher EALs in mind will likely be overly costly and time consuming). EAL4 is designed to grant maximum security assurance based on development best practices
What are the different levels of FIPS 140-2?
The FIPS 140-2 publication establishes four different levels of security. Level 1 has the lowest level of security requirements, whereas Level 4 provides the highest level of security.
FIPS 140-2 Level 1
The lowest level of security requirements specified for a cryptographic module. Security Level 1 does not require any physical security mechanisms beyond basic requirements for production-grade components and allows for a cryptographic module to be executed on a general-purpose computer using an unevaluated operating system.
An example of a Security Level 1 cryptographic module is an encryption board on a personal computer (PC).
FIPS 140-2 Level 2
Security Level 2 expands on Security Level 1 by adding three main requirements:
- Tamper-evidence on cryptographic modules: This can include tamper-evident coatings, seals, or pick-resistant locks. Tamper-evidence measures must be applied in a fashion so that seals and/or coatings must be broken to gain physical access to the plaintext cryptographic keys and critical security parameters (CSPs).
- Role-based authentication: The minimum requirement for Security Level 2 states that a given user must have their specific role and authorization level authenticated by the cryptographic module
- Operating system requirements: Security Level 2 allows a cryptographic module to be executed on a general-purpose PC leveraging an approved or evaluated trusted operating system. Operating systems must be evaluated at the Common Criteria (CC) evaluation assurance level EAL2 or higher. For more information, reference Section 1.2 of the FIPS 140-2 publication.
FIPS 140-2 Level 3
The security requirements established by Security Level 3 expand on those set by Level 2 in four key areas:
- Intrusion prevention: Going beyond the tamper-evidence implemented in Security Level 2, Security Level 3 requires physical security mechanisms designed to prevent an intruder from gaining access to CSPs within the cryptographic module. These mechanisms are intended to have a high probability of detecting and reacting to attempts to physically access, tamper with, or use a cryptographic module without authorization. Example mechanisms include strong enclosures and circuitry designed to zeroize (erase) plaintext CSPs when a module is tampered with.
- Identity-based authentication: A more granular authentication method, identity-based authentication improves on the role-based authentication requirement in Security Level 2. This is achieved by authenticating the identity of a given user rather than authenticating that user’s role. An example of the difference would be a network that requires specific user log ins instead of a network that may have general use or guest accounts plus a generic admin account.
- Physical (or logical) separation: To be compliant with Security Level 3, the input and/or output of plaintext CSPs must be performed using ports that are physically (or interfaces logically separated, if a virtual environment) separated from other ports. Plaintext CSPs may be entered into or output from the cryptographic module through an enclosing or intervening system only if they are in an encrypted form.
- Operating system requirements: Much like Security Level 2, Security Level 3 allows for a cryptographic module to be executed on a general-purpose PC using an operating system meeting the minimum requirements. The requirements for Security Level 3 are more stringent than Level 2 and include a CC evaluation assurance level EAL3 or higher. More information on the Security Level 3 operating system requirements can be found in Section 1.3 of the FIPS 140-2 publication.
FIPS 140-2 Level 4
Security Level 4 provides for the highest level of security of the four FIPS 140-2 security levels and is ideal for cryptographic modules operating in physically unprotected environments. To get an idea of what constitutes a physically unprotected environment, consider anywhere government information or communications might be processed, stored, or transited through, such as satellites and unmanned aerial vehicles. The intention of Security Level 4 is for physical security mechanisms to completely envelop and protect the cryptographic module from all unauthorized attempts to physically access it. Mechanisms must provide a very high probability of detecting an intrusion and must be designed to immediately zeroize all plaintext CSPs in the event an intrusion is detected.
To be compliant with FIPS 140-2 Level 4, a given cryptographic module must also be protected against environmental conditions that might push the module outside of its normal operating ranges. It is common for potential intruders to push a cryptographic module outside its normal voltage and temperature to compromise the module’s security. Examples would include hyper heating or freezing the module container in an effort to make it brittle (consider the popular movie motif of a spy using liquid nitrogen to freeze and break a lock).
Environmental protection can come in the form of features that zeroize CSPs if the cryptographic module detects fluctuations outside the normal operation range. Using the above example, if the spy in the movie were to freeze a lock to a cryptographic module to break it, the environmental protection measures would detect that the lock is being subjected to temperatures below a set threshold and zero out the module. This makes it useless to the spy, even if the module is eventually obtained.
Alternatively, the environmental protection requirement can be met via a reasonable assurance that fluctuations outside the normal operating range will not compromise the module’s security.
Much like Security Levels 2 and 3, Security Level 4 also requires an operating system that meets a certain CC evaluation assurance level. For a cryptographic module to be FIPS 140-2 Level 4 compliant, the operating system it is running on must receive a CC evaluation of EAL4 or higher.
Becoming FIPS 140-2 Certified
For a given cryptographic module to be validated as compliant with FIPS 140-2, an organization must submit that module to the Cryptographic Module Validation Program (CMVP). The CMVP is a joint effort by the NIST and the Communications Security Establishment (CSE) for the Canadian Government.
To have their module evaluated by the CMVP, an organization must submit the module to an accredited Cryptographic Module Testing Laboratory. Accredited laboratories are third party laboratories that have been certified by the National Voluntary Laboratory Accreditation Program (NVLAP).
Maintaining FIPS 140-2 Certification
FIPS 140-2 certification can be a long and time-consuming process, usually taking several months to over a year from start to finish. Additionally, a module must be re-evaluated for each change made to the software, no matter how small. In the event a problem is discovered in a FIPS-compliant module, the solution will lose its FIPS certification until it has been reassessed and certified. During this period, the organization will be unable to supply their module to vendors and agencies requiring the standard.
Criticisms of FIPS 140-2
While being validated as FIPS 140-2 compliant is an essential part of working with US government IT, the validation process does lead to some valid criticisms of FIPS 140-2.
The leading point of criticism is related to the lengthy validation process. Due to the months to year-long validation process and the fact an organize must revalidate their product for each change, no matter how minor, many companies are reluctant to update or upgrade software even if a bug is detected. This can result in falling behind on critical updates and can even incentivize organizations to hide minor bugs in their code.
Organizations have discovered bugs and vulnerabilities in their software but were met with difficulties and an unclear process for quickly getting a fix validated as FIPS 140-2 compliant. In one example, an organization discovered a vulnerability in a certified module and had the patch ready for deployment the same day but was unable to get the patch validated within an appropriate timeframe. The result was that the organization announced the vulnerability in their software and CMVP almost immediately revoked the module’s FIPS 140-2 validation, leaving them and their customers in limbo until the new validation was completed.
What makes this case especially noteworthy is that the vulnerability was found in an open source derivative of OpenSSL, which their proprietary validation was based on. While there were several other proprietary validations based on that same code, few to none received a revocation. This is because other organizations slightly modified and re-validated the code under a different name, rather than leverage the code identified as open source. This effectively hid the origin of the code and other companies were able to avoid revocation resulting from a vulnerability found in open source code.
Questions You Should Ask
Considering the criticisms of the FIPS 140-2 validation process, any organization that wishes to have their cryptographic module used by the US government should ask the module creator a few important questions:
- When was the last time the cryptographic module updated/validated?
- Is there a new version of the cryptographic module currently undergoing validation?
- Are there any known bugs or vulnerabilities in the module or its underlying code that may not have been disclosed?
- Are there plans to update and/or re-validate the cryptographic module in the near future?
- What does the update process/cadence for the FIPS-compliant module look like?
- Has the cryptographic module undergone any testing or validation outside the CMVP?
XMedius is a global leader in the field of enterprise communications solutions. Its suite of enterprise-grade on-premises and cloud communications solutions enable businesses to benefit from secure and unified communication, as well as to exchange sensitive and confidential data that meets and exceeds industry regulatory compliance requirements. Based in Montreal (Canada), with offices in Seattle (USA) and Paris (France), the company serves businesses, enterprises and service providers through a global team of customer focused employees. Its solutions are deployed worldwide across a number of sectors, including education, finance, government, healthcare, manufacturing, retail, and legal services. For more information about XMedius and its solutions, visit www.xmedius.com, and connect on LinkedIn and Twitter.