World Library  
Flag as Inappropriate
Email this Article

Fips 140-2

Article Id: WHEBN0000885948
Reproduction Date:

Title: Fips 140-2  
Author: World Heritage Encyclopedia
Language: English
Subject: Common Criteria, Dual EC DRBG, LibreSSL, RSA BSAFE, Security-evaluated operating system
Collection: Computer Security Standards, Cryptography Standards, Standards of the United States
Publisher: World Heritage Encyclopedia

Fips 140-2

The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2),[1][2] is a U.S. government computer security standard used to accredit cryptographic modules. The title is Security Requirements for Cryptographic Modules. Initial publication was on May 25, 2001 and was last updated December 3, 2002.


  • Purpose 1
  • Security Levels 2
    • Level 1 2.1
    • Level 2 2.2
    • Level 3 2.3
    • Level 4 2.4
  • Operating platform 3
  • Cryptographic Module Validation Program 4
  • FIPS 140-2 testing in this program 5
  • Laboratories doing the testing 6
  • Validation 7
  • Annexes 8
  • Reception 9
  • See also 10
  • References 11
  • External links 12


The National Institute of Standards and Technology (NIST) issued the FIPS 140 Publication Series to coordinate the requirements and standards for cryptography modules that include both hardware and software components. Protection of a cryptographic module within a security system is necessary to maintain the confidentiality and integrity of the information protected by the module. This standard specifies the security requirements that will be satisfied by a cryptographic module. The standard provides four increasing, qualitative levels of security intended to cover a wide range of potential applications and environments. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.[3]

Federal agencies and departments can validate that the module in use is covered by an existing FIPS 140-1 or FIPS 140-2 certificate that specifies the exact module name, hardware, software, firmware, and/or applet version numbers. The cryptographic modules are produced by the private sector or open source communities for use by the U.S. government and other regulated industries (such as financial and health-care institutions) that collect, store, transfer, share and disseminate sensitive but unclassified (SBU) information. A commercial cryptographic module is also commonly referred to as a hardware security module.

Security Levels

FIPS 140-2 defines four levels of security, simply named "Level 1" to "Level 4". It does not specify in detail what level of security is required by any particular application.

Level 1

Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one Approved algorithm or Approved security function shall be used). No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. An example of a Security Level 1 cryptographic module is a personal computer (PC) encryption board.

Level 2

Security Level 2 improves upon the physical security mechanisms of a Security Level 1 cryptographic module by requiring features that show evidence of tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access.

Level 3

In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroes all plain text CSPs when the removable covers/doors of the cryptographic module are opened.

Level 4

Security Level 4 provides the highest level of security.

At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.

Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate deletion of all plaintext CSPs.

Security Level 4 cryptographic modules are useful for operation in physically unprotected environments. Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature. Intentional excursions beyond the normal operating ranges may be used by an attacker to thwart a cryptographic module's defenses. A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and delete CSPs, or to undergo rigorous environmental failure testing to provide a reasonable assurance that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module.

Operating platform

For Levels 2 and higher, the operating platform upon which the validation is applicable is also listed. Vendors do not always maintain their baseline validations.

Cryptographic Module Validation Program

FIPS 140-2 establishes the Cryptographic Module Validation Program (CMVP) as a joint effort by the NIST and the Communications Security Establishment (CSE) for the Canadian government.

Security programs overseen by NIST and CSE focus on working with government and industry to establish more secure systems and networks by developing, managing and promoting security assessment tools, techniques, services, and supporting programs for testing, evaluation and validation; and addresses such areas as: development and maintenance of security metrics, security evaluation criteria and evaluation methodologies, tests and test methods; security-specific criteria for laboratory accreditation; guidance on the use of evaluated and tested products; research to address assurance methods and system-wide security and assessment methodologies; security protocol validation activities; and appropriate coordination with assessment-related activities of voluntary industry standards bodies and other assessment regimes.

FIPS 140-2 testing in this program

The FIPS 140-2 standard is an information technology security accreditation program for cryptographic modules produced by private sector vendors who seek to have their products certified for use in government departments and regulated industries (such as financial and health-care institutions) that collect, store, transfer, share and disseminate sensitive but unclassified (SBU) information.

Laboratories doing the testing

All of the tests under the CMVP are handled by third-party laboratories that are accredited as Cryptographic Module Testing laboratories[4] by the National Voluntary Laboratory Accreditation Program.[5] Vendors interested in validation testing may select any of the thirteen accredited labs.

NVLAP accredited Cryptographic Modules Testing laboratories perform validation testing of cryptographic modules.[6][7] Cryptographic modules are tested against requirements found in FIPS PUB 140-2, Security Requirements for Cryptographic Modules. Security requirements cover 11 areas related to the design and implementation of a cryptographic module. Within most areas, a cryptographic module receives a security level rating (1–4, from lowest to highest), depending on what requirements are met. For other areas that do not provide for different levels of security, a cryptographic module receives a rating that reflects fulfillment of all of the requirements for that area.


An overall rating is issued for the cryptographic module, which indicates:

  1. the minimum of the independent ratings received in the areas with levels, and
  2. the fulfillment of all the requirements in the other areas.

On a vendor's validation certificate, individual ratings are listed, as well as the overall rating.

NIST maintains validation lists[8] for all of its cryptographic standards testing programs (past and present). All of these lists are updated as new modules/implementations receive validation certificates from NIST and CSE. Items on the FIPS 140-1 and FIPS 140-2 validation list reference validated algorithm implementations that appear on the algorithm validation lists.


FIPS PUB 140-2 Annexes:

  • Annex A: Approved Security Functions (Draft 01-04-2011)
  • Annex B: Approved Protection Profiles (Draft 06-14-2007)
  • Annex C: Approved Random Number Generators (Draft 11-22-2010)
  • Annex D: Approved Key Establishment Techniques (Draft 01-04-2011)


Steven Marquess has posted a criticism that FIPS 140-2 validation can lead to incentives to keep vulnerabilities and other defects hidden. CMVP can decertify software in which vulnerabilities are found, but it can take a year to re-certify software if defects are found, so companies can be left without a certified product to ship. As an example, Steven Marquess mentions a vulnerability that was found, publicised, and fixed in the FIPS-certified open source derivative of OpenSSL, with the publication meaning that the OpenSSL derivative was decertified. This decertification hurt companies relying on the OpenSSL-derivative's FIPS certification. By contrast, companies which had renamed and certified a copy of the open source OpenSSL derivative were not decertified, even though they were basically identical, and did not fix the vulnerability. Steven Marquess therefore argues that the FIPS process inadvertently encourages hiding software's origins, to de-associate it from defects since found in the original, while potentially leaving the certified copy vulnerable.[9]

See also


  1. ^ "FIPS PUB 140-2: Security Requirements for Cryptographic Modules".  
  2. ^ "Federal Information Processing Standards (FIPS) Publications: FIPS 140--2, Security Requirements for Cryptographic Modules". NIST. May 2001. Retrieved 2013-05-18. 
  3. ^ "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES" (PDF). National Institute of Standards and Technology. 2001-05-25. Retrieved 2014-01-09. 
  4. ^ "Testing Laboratories". NIST. 2013-04-01. Retrieved 2013-05-18. 
  5. ^ "National Voluntary Laboratory Accreditation Program". NIST. Retrieved 2013-05-18. 
  6. ^ "Cryptographic Module Validation Program (CMVP)". Retrieved 2015-08-04. 
  7. ^ "NVLAP Cryptographic and Security Testing LAP". Retrieved 2015-08-04. 
  8. ^ "Module Validation Lists". NIST. 2013-05-13. Retrieved 2013-05-18. 
  9. ^ Steven Marquess. "Secure or Compliant, Pick One". Archived from the original on December 27, 2013. 

External links

  • "FIPS PUB 140-2" ( 
  • "FIPS PUB 140-2 - Effective 15-Nov-2001". NIST. 2013-05-01. Retrieved 2013-05-18. 
  • "FIPS Validation".  
  • "OpenSSL and FIPS 140-2".  
  • "OpenFIPS Project". Retrieved 2013-05-18. 
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.