FIPS 140

Last updated • 6 min readFrom Wikipedia, The Free Encyclopedia

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

Contents

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, and a small number of validation certificates have been issued. FIPS 140-2 testing is still available until September 21, 2021 (later changed for applications already in progress to April 1, 2022 [3] ), 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. [4]

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.

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

FIPS 140 imposes requirements in eleven different areas:

Brief history

FIPS 140-1, issued on 11 January 1994 and withdrawn on May 25, 2002, [5] 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. [6]

FIPS 140-3, issued on 22 March 2019 and announced [7] 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 [8] 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. [9]

This criticism has been countered 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. [10]

See also

Related Research Articles

<span class="mw-page-title-main">Advanced Encryption Standard</span> Standard for the encryption of electronic data

The Advanced Encryption Standard (AES), also known by its original name Rijndael, is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001.

The Common Criteria for Information Technology Security Evaluation is an international standard for computer security certification. It is currently in version 3.1 revision 5.

<span class="mw-page-title-main">Zeroisation</span>

In cryptography, zeroisation is the practice of erasing sensitive parameters from a cryptographic module to prevent their disclosure if the equipment is captured. This is generally accomplished by altering or deleting the contents to prevent recovery of the data.

In cryptography, a message authentication code (MAC), sometimes known as an authentication tag, is a short piece of information used for authenticating and integrity-checking a message. In other words, to confirm that the message came from the stated sender and has not been changed. The MAC value allows verifiers to detect any changes to the message content.

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

<span class="mw-page-title-main">Cryptographic Module Validation Program</span> Joint American-Canadian security accreditation program for cryptographic modules

The Cryptographic Module Validation Program (CMVP) is a joint American and Canadian security accreditation program for cryptographic modules. The program is available to any vendors who seek to have their products certified for use by the U.S. Government and regulated industries that collect, store, transfer, share and disseminate "sensitive, but not classified" information. All of the tests under the CMVP are handled by third-party laboratories that are accredited as Cryptographic Module Testing Laboratories by the National Voluntary Laboratory Accreditation Program (NVLAP). Product certifications under the CMVP are performed in accordance with the requirements of FIPS 140-2 and FIPS 140-3.

Information security standards or cyber security standards are techniques generally outlined in published materials that attempt to protect the cyber environment of a user or organization. This environment includes users themselves, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks.

<span class="mw-page-title-main">Hardware security module</span> Physical computing device

A hardware security module (HSM) is a physical computing device that safeguards and manages secrets, performs encryption and decryption functions for digital signatures, strong authentication and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. A hardware security module contains one or more secure cryptoprocessor chips.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

A cryptographic module is a component of a computer system that implements cryptographic algorithms in a secure way, typically with some element of tamper resistance.

Cryptographic Module Testing Laboratory (CMTL) is an information technology (IT) computer security testing laboratory that is accredited to conduct cryptographic module evaluations for conformance to the FIPS 140-2 U.S. Government standard.

ISO/IEC 27002 is an information security standard published by the International Organization for Standardization (ISO) and by the International Electrotechnical Commission (IEC), titled Information security, cybersecurity and privacy protection — Information security controls.

The Federal Information Processing Standard Publication 140-3 is a U.S. government computer security standard used to approve cryptographic modules. The title is Security Requirements for Cryptographic Modules. Initial publication was on March 22, 2019 and it supersedes FIPS 140-2.

The tables below compare cryptography libraries that deal with cryptography algorithms and have API function calls to each of the supported features.

Storage security is a specialty area of security that is concerned with securing data storage systems and ecosystems and the data that resides on these systems.

FinalCode, Inc. is a multi-national software company that provides data-centric security and information rights management (IRM) to help enterprises mitigate data leakage and meet compliance requirements. FinalCode allows users to securely collaborate and share files using any communication channel, including existing Enterprise Content Management (ECM), Cloud Storage and collaboration applications.

The IBM 4765 PCIe Cryptographic Coprocessor is a hardware security module (HSM) that includes a secure cryptoprocessor implemented on a high-security, tamper resistant, programmable PCIe board. Specialized cryptographic electronics, microprocessor, memory, and random number generator housed within a tamper-responding environment provide a highly secure subsystem in which data processing and cryptography can be performed.

The IBM 4767 PCIe Cryptographic Coprocessor is a hardware security module (HSM) that includes a secure cryptoprocessor implemented on a high-security, tamper resistant, programmable PCIe board. Specialized cryptographic electronics, microprocessor, memory, and random number generator housed within a tamper-responding environment provide a highly secure subsystem in which data processing and cryptography can be performed. Sensitive key material is never exposed outside the physical secure boundary in a clear format.

The IBM 4768 PCIe Cryptographic Coprocessor is a hardware security module (HSM) that includes a secure cryptoprocessor implemented on a high security, tamper resistant, programmable PCIe board. Specialized cryptographic electronics, microprocessor, memory, and random number generator housed within a tamper-responding environment provide a highly secure subsystem in which data processing and cryptography can be performed. Sensitive key material is never exposed outside the physical secure boundary in a clear format.

ISO/IEC 19790 is an ISO/IEC standard for security requirements for cryptographic modules. It addresses a wide range of issues regarding their implementation, including specifications, interface definitions, authentication, operational and physical security, configuration management, testing, and life-cycle management. The first version of ISO/IEC 19790 was derived from the U.S. government computer security standard FIPS 140-2, Security Requirements for Cryptographic Modules.

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. June 2, 2021. Retrieved August 18, 2021.
  4. "FIPS 140-3 Transition Effort". www.nist.gov. National Institute of Standards and Technology. September 21, 2020. Retrieved October 19, 2020.
  5. "Federal Information Processing Standard (FIPS) 140-1: Security Requirements for Cryptographic Modules". NIST.
  6. Snouffer, Ray; Lee, Annabelle; Oldehoeft, Arch (2001-06-01). "A Comparison of the Security Requirements for Cryptographic Modules in FIPS 140-1 and FIPS 140-2". NIST. CiteSeerX   10.1.1.110.6970 . doi:10.6028/NIST.SP.800-29 . Retrieved 2018-02-14.{{cite journal}}: Cite journal requires |journal= (help)
  7. "Announcing Approval and Issuance of FIPS 140-3, Security Requirements for Cryptographic Modules". May 2019.
  8. "FIPS-140 -3: DRAFT Security Requirements for Cryptographic Modules (Revised Draft)". NIST. 2013-03-07. Retrieved 2013-05-18.
  9. "Is FIPS 140-2 Actively harmful to software?". Darren Moffat, Oracle Solaris. 2014-04-16. Retrieved 2017-03-18.
  10. "Inside 'FIPS Inside'". Walter Paley, SafeLogic. 2018-04-10. Retrieved 2020-10-19.