FIPS 140

The 140 series of Federal Information Processing Standards (FIPS) are U.S. government computer security standards that specify requirements for cryptography modules.

As of October 2020, FIPS 140-2 and FIPS 140-3 are both accepted as current and active.[1]FIPS 140-3 was approved on March 22, 2019 as the successor to FIPS 140-2 and became effective on September 22, 2019.[2] FIPS 140-3 testing began on September 22, 2020, although no FIPS 140-3 validation certificates have been issued yet. FIPS 140-2 testing is still available until September 21, 2021, creating an overlapping transition period of one year. FIPS 140-2 test reports that remain in the CMVP queue will still be granted validations after that date, but all FIPS 140-2 validations will be moved to the Historical List on September 21, 2026 regardless of their actual final validation date.[3]

Purpose of FIPS 140

The National Institute of Standards and Technology (NIST) issues the 140 Publication Series to coordinate the requirements and standards for cryptographic modules which include both hardware and software components for use by departments and agencies of the United States federal government. FIPS 140 does not purport to provide sufficient conditions to guarantee that a module conforming to its requirements is secure, still less that a system built using such modules is secure. The requirements cover not only the cryptographic modules themselves but also their documentation and (at the highest security level) some aspects of the comments contained in the source code.

User agencies desiring to implement cryptographic modules should confirm that the module they are using is covered by an existing validation certificate. FIPS 140-1 and FIPS 140-2 validation certificates specify the exact module name, hardware, software, firmware, and/or applet version numbers. 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.

The Cryptographic Module Validation Program (CMVP) is operated jointly by the United States Government's National Institute of Standards and Technology (NIST) Computer Security Division and the Communications Security Establishment (CSE) of the Government of Canada. The use of validated cryptographic modules is required by the United States Government for all unclassified uses of cryptography. The Government of Canada also recommends the use of FIPS 140 validated cryptographic modules in unclassified applications of its departments.

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.

  • FIPS 140-2 Level 1 the lowest, imposes very limited requirements; loosely, all components must be "production-grade" and various egregious kinds of insecurity must be absent.
  • FIPS 140-2 Level 2 adds requirements for physical tamper-evidence and role-based authentication.
  • FIPS 140-2 Level 3 adds requirements for physical tamper-resistance (making it difficult for attackers to gain access to sensitive information contained in the module) and identity-based authentication, and for a physical or logical separation between the interfaces by which "critical security parameters" enter and leave the module, and its other interfaces.
  • FIPS 140-2 Level 4 makes the physical security requirements more stringent, and requires robustness against environmental attacks.

In addition to the specified levels, Section 4.1.1 of the specification describes additional attacks that may require mitigation, such as differential power analysis. If a product contains countermeasures against these attacks, they must be documented and tested, but protections are not required to achieve a given level. Thus, a criticism of FIPS 140-2 is that the standard gives a false sense of security at Levels 2 and above because the standard implies that modules will be tamper-evident and/or tamper-resistant, yet modules are permitted to have side channel vulnerabilities that allow simple extraction of keys.

Scope of requirements
A FIPS 140-2 Level 4 certified PCIe HSM

FIPS 140 imposes requirements in eleven different areas:

  • Cryptographic module specification (what must be documented)
  • Cryptographic module ports and interfaces (what information flows in and out, and how it must be segregated)
  • Roles, services and authentication (who can do what with the module, and how this is checked)
  • Finite state model (documentation of the high-level states the module can be in, and how transitions occur)
  • Physical security (tamper evidence and resistance, and robustness against extreme environmental conditions)
  • Operational environment (what sort of operating system the module uses and is used by)
  • Cryptographic key management (generation, entry, output, storage and destruction of keys)
  • EMI/EMC
  • Self-tests (what must be tested and when, and what must be done if a test fails)
  • Design assurance (what documentation must be provided to demonstrate that the module has been well designed and implemented)
  • Mitigation of other attacks (if a module is designed to mitigate against, say, TEMPEST attacks then its documentation must say how)

Brief history

FIPS 140-1, issued on 11 January 1994, was developed by a government and industry working group, composed of vendors and users of cryptographic equipment. The group identified the four "security levels" and eleven "requirement areas" listed above, and specified requirements for each area at each level.

FIPS 140-2, issued on 25 May 2001, takes account of changes in available technology and official standards since 1994, and of comments received from the vendor, tester, and user communities. It was the main input document to the international standard ISO/IEC 19790:2006 Security requirements for cryptographic modules issued on 1 March 2006. NIST issued Special Publication 800-29 outlining the significant changes from FIPS 140-1 to FIPS 140-2.[4]

FIPS 140-3, issued on 22 March 2019 and announced in May 2019 is currently in the overlapping transition period to supersede FIPS 140-2 and aligns the NIST guidance around two international standards documents: ISO/IEC 19790:2012(E) Information technology — Security techniques — Security requirements for cryptographic modules and ISO/IEC 24759:2017(E) Information technology — Security techniques — Test requirements for cryptographic modules. In the first draft version[5] of the FIPS 140-3 standard, NIST introduced a new software security section, one additional level of assurance (Level 5) and new Simple Power Analysis (SPA) and Differential Power Analysis (DPA) requirements. The draft issued on 11 Sep 2009, however, reverted to four security levels and limits the security levels of software to levels 1 and 2.

Criticism

Due to the way in which the validation process is set up, a software vendor is required to re-validate their FIPS-validated module for every change, no matter how small, to the software; this re-validation is required even for obvious bug or security fixes. Since validation is an expensive process, this gives software vendors an incentive to postpone changes to their software and can result in software that does not receive security updates until the next validation. The result may be that validated software is less safe than a non-validated equivalent.[6]

This criticism has been refuted more recently by some industry experts who instead put the responsibility on the vendor to narrow their validation boundary. As most of the re-validation efforts are triggered by bugs and security fixes outside the core cryptographic operations, a properly scoped validation is not subject to the common re-validation as described.[7]

See also

References
  1. "FIPS General Information". NIST. 2010-10-05. Retrieved 2013-05-18.
  2. "Announcing Approval and Issuance of FIPS 140-3, Security Requirements for Cryptographic Modules". www.nist.gov. National Institute of Standards and Technology. May 1, 2019. Retrieved May 29, 2019.
  3. "FIPS 140-3 Transition Effort". www.nist.gov. National Institute of Standards and Technology. September 21, 2020. Retrieved October 19, 2020.
  4. "A Comparison of the Security Requirements for Cryptographic Modules in FIPS 140-1 and FIPS 140-2". NIST. 2001-06-01. Retrieved 2018-02-14.
  5. "FIPS-140 -3: DRAFT Security Requirements for Cryptographic Modules (Revised Draft)". NIST. 2013-03-07. Retrieved 2013-05-18.
  6. "Is FIPS 140-2 Actively harmful to software?". Darren Moffat, Oracle Solaris. 2014-04-16. Retrieved 2017-03-18.
  7. "Inside 'FIPS Inside'". Walter Paley, SafeLogic. 2018-04-10. Retrieved 2020-10-19.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.