FIPS PUB 140-2 CHANGE NOTICES (12-03-2002) FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION (Supercedes FIPS PUB 140-1, 1994 January 11) SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES CATEGORY: COMPUTER SECURITY SUBCATEGORY: CRYPTOGRAPHY Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8900 Issued May 25, 2001 U.S. Department of Commerce Donald L. Evans, Secretary Technology Administration Phillip J.
Foreword The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official series of publications relating to standards and guidelines adopted and promulgated under the provisions of Section 5131 of the Information Technology Management Reform Act of 1996 (Public Law 104-106) and the Computer Security Act of 1987 (Public Law 100-235).
Federal Information Processing Standards Publication 140-2 May 25, 2001 Announcing the Standard for SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Management Reform Act of 1996 (Public Law 104-106) and the Computer Security Act of 1987 (Public Law 100-235). 1.
e. f. g. h. i. FIPS PUB 171, Key Management Using ANSI X9.17. FIPS PUB 180-1, Secure Hash Standard. FIPS PUB 186-2, Digital Signature Standard. Special Publication 800-2, Public Key Cryptography. Special Publication 800-20, Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures These documents may be found at the CMVP URL http://www.nist.gov/cmvp. Other NIST publications may be applicable to the implementation and use of this standard.
12. Interpretation. Questions concerning the content and specifications of this standard should be addressed to: Director, Information Technology Laboratory, ATTN: FIPS 140-2 Interpretation, National Institute of Standards and Technology, 100 Bureau Drive, Stop 8900, Gaithersburg, MD 20899-8900. Resolution of questions regarding this standard will be provided by the validation authorities at NIST and CSE. 13. Export Control.
While the security requirements specified in this standard are intended to maintain the security provided by a cryptographic module, conformance to this standard is not sufficient to ensure that a particular module is secure. The operator of a cryptographic module is responsible for ensuring that the security provided by a module is sufficient and acceptable to the owner of the information that is being protected and that any residual risk is acknowledged and accepted.
TABLE OF CONTENTS 1. OVERVIEW........................................................................................................................................... 1 1.1 Security Level 1.............................................................................................................................. 1 1.2 Security Level 2.............................................................................................................................. 2 1.3 Security Level 3....................
APPENDIX E: APPLICABLE INTERNET UNIFORM RESOURCE LOCATORS (URL)...................... 53 CHANGE NOTICE...................................................................................................................................... 54 Change Notice 1 (Superceded by Change Notice 2) ................................................................................ 54 Change Notice 2 ............................................................................................................................
1. OVERVIEW This standard specifies the security requirements for a cryptographic module utilized within a security system protecting sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. FIPS 140-1 was developed by a government and industry working group composed of both operators and vendors.
Security Level 1 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an unevaluated operating system. Such implementations may be appropriate for some low-level security applications when other controls, such as physical security, network security, and administrative procedures are limited or nonexistent.
Security Level 3 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that • meets the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1) and • is evaluated at the CC evaluation assurance level EAL3 (or higher) with the additional assurance requirement of an Informal Target of Evaluation (TOE) Security Policy Model (ADV_SPM.
2. 2.1 GLOSSARY OF TERMS AND ACRONYMS Glossary of Terms The following definitions are tailored for use in this standard: Approved: FIPS-Approved and/or NIST-recommended. Approved mode of operation: a mode of the cryptographic module that employs only Approved security functions (not to be confused with a specific mode of an Approved security function, e.g., DES CBC mode). Approved security function: for this standard, a security function (e.g.
Cryptographic key component (key component): a parameter used in conjunction with other key components in an Approved security function to form a plaintext cryptographic key or perform a cryptographic function. Cryptographic module: the set of hardware, software, and/or firmware that implements Approved security functions (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary.
Finite state model: a mathematical model of a sequential machine that is comprised of a finite set of input events, a finite set of output events, a finite set of states, a function that maps states and input to output, a function that maps states and inputs to states (a state transition function), and a specification that describes the initial state. Firmware: the programs and data components of a cryptographic module that are stored in hardware (e.g.
Password: a string of characters (letters, numbers, and other symbols) used to authenticate an identity or to verify access authorization. Personal identification number (PIN): an alphanumeric code or password used to authenticate an identity. Physical protection: the safeguarding of a cryptographic module, cryptographic keys, or CSPs using physical means. Plaintext key: an unencrypted cryptographic key.
Software: the programs and data components within the cryptographic boundary, usually stored on erasable media (e.g., disk), that can be dynamically written and modified during execution. Split knowledge: a process by which a cryptographic key is split into multiple key components, individually sharing no knowledge of the original key, that can be subsequently input into, or output from, a cryptographic module by separate entities and combined to recreate the original cryptographic key.
CAPP Controlled Access Protection Profile CBC Cipher Block Chaining CC Common Criteria CMVP Cryptographic Module Validation Program CSE Communications Security Establishment of the Government of Canada CSP Critical Security Parameter DES Data Encryption Standard DOD Department of Defense DPA Differential Power Analysis DTR Derived Test Requirements EAL Common Criteria Evaluation Assurance Level EDC Error Detection Code EEPROM Electronically-Erasable Programmable Read-Only Memory EF
NIST National Institute of Standards and Technology NTIS National Technical Information Service PIN Personal Identification Number PROM Programmable Read-Only Memory RAM Random Access Memory RNG Random Number Generator ROM Read-Only Memory SPA Simple Power Analysis TOE Target of Evaluation TSF Target of Evaluation Security Functions TSP Target of Evaluation Security Policy URL Uniform Resource Locator 10
3. FUNCTIONAL SECURITY OBJECTIVES The security requirements specified in this standard relate to the secure design and implementation of a cryptographic module. The requirements are derived from the following high-level functional security objectives for a cryptographic module: • To employ and correctly implement the Approved security functions for the protection of sensitive information. • To protect a cryptographic module from unauthorized operation or use.
4. SECURITY REQUIREMENTS This section specifies the security requirements that shall be satisfied by cryptographic modules conforming to this standard. The security requirements cover areas related to the design and implementation of a cryptographic module.
module will receive a rating that reflects the maximum security level for which the module fulfills all of the requirements of that area. In areas that do not provide for different levels of security (i.e., standard set of requirements), the cryptographic module will receive a rating commensurate with the overall level of security. In addition to receiving independent ratings for each of the security areas, a cryptographic module will also receive an overall rating.
• Documentation shall specify: ! a block diagram depicting all of the major hardware components of a cryptographic module and component interconnections, including any microprocessors, input/output buffers, plaintext/ciphertext buffers, control buffers, key storage, working memory, and program memory, and ! the design of the hardware, software, and firmware components of a cryptographic module.
provided or maintained internally to the cryptographic boundary of the cryptographic module (e.g., an internal battery). The cryptographic module shall distinguish between data and control for input and data and status for output. All input data entering the cryptographic module via the "data input" interface shall only pass through the input data path. All output data exiting the cryptographic module via the "data output" interface shall only pass through the output data path.
4.3.1 Roles A cryptographic module shall support the following authorized roles for operators: User Role. The role assumed to perform general security services, including cryptographic operations and other Approved security functions. Crypto Officer Role: The role assumed to perform cryptographic initialization or management functions (e.g., module initialization, input/output of cryptographic keys and CSPs, and audit functions).
1) the bypass capability is not activated, and the module is exclusively providing services with cryptographic processing (e.g., plaintext data is encrypted), 2) the bypass capability is activated and the module is exclusively providing services without cryptographic processing (e.g.
verification of personal characteristics (e.g., biometrics). Authentication data within a cryptographic module shall be protected against unauthorized disclosure, modification, and substitution. The initialization of authentication mechanisms may warrant special treatment. If a cryptographic module does not contain the authentication data required to authenticate the operator for the first time the module is accessed, then other authorized methods (e.g.
4.4 Finite State Model The operation of a cryptographic module shall be specified using a finite state model (or equivalent) represented by a state transition diagram and/or a state transition table.
• the input events, including data inputs and control inputs, that cause transitions from one state to another, and • the output events, including internal module conditions, data outputs, and status outputs resulting from transitions from one state to another. 4.
General Requirements for all Embodiments Single-Chip Cryptographic Modules Multiple-Chip Embedded Cryptographic Modules Multiple-Chip Standalone Cryptographic Modules Security Level 1 Production-grade components (with standard passivation). No additional requirements. If applicable, production-grade enclosure or removable cover. Production-grade enclosure. Security Level 2 Evidence of tampering (e.g., cover, enclosure, or seal). Opaque tamper-evident coating on chip or enclosure.
! the maintenance access interface shall include all physical access paths to the contents of the cryptographic module, including any removable covers or doors, ! any removable covers or doors included within the maintenance access interface shall be safeguarded using the appropriate physical security mechanisms, ! all plaintext secret and private keys and CSPs shall be zeroized when the maintenance access interface is accessed, and ! documentation shall specify the maintenance access interface and h
• 4.5.2 The cryptographic module shall either include environmental failure protection (EFP) features or undergo environmental failure testing (EFT) as specified in Section 4.5.5. Single-Chip Cryptographic Modules In addition to the general security requirements specified in Section 4.5.1, the following requirements are specific to single-chip cryptographic modules. SECURITY LEVEL 1 There are no additional Security Level 1 requirements for single-chip cryptographic modules.
4.5.3 Multiple-Chip Embedded Cryptographic Modules In addition to the general security requirements specified in Section 4.5.1, the following requirements are specific to multiple-chip embedded cryptographic modules. SECURITY LEVEL 1 The following requirement shall apply to multiple-chip embedded cryptographic modules for Security Level 1. • If the cryptographic module is contained within an enclosure or removable cover, a productiongrade enclosure or removable cover shall be used.
SECURITY LEVEL 4 In addition to the requirements for Security Levels 1, 2, and 3, the following requirements shall apply to multiple-chip embedded cryptographic modules for Security Level 4. • The cryptographic module components shall be covered by potting material or contained within an enclosure encapsulated by a tamper detection envelope (e.g.
• the cryptographic module shall be contained within a strong enclosure such that attempts at removal or penetration of the enclosure will have a high probability of causing serious damage to the module (i.e., the module will not function). SECURITY LEVEL 4 In addition to the requirements for Security Levels 1, 2, and 3, the following requirements shall apply to multiple-chip standalone cryptographic modules for Security Level 4.
4.5.5.2 Environmental Failure Testing Procedures (Alternative 2) Environmental failure testing (EFT) shall involve a combination of analysis, simulation, and testing of a cryptographic module to provide reasonable assurance that environmental conditions or fluctuations (accidental or induced) outside the module's normal operating ranges for temperature and voltage will not compromise the security of the module.
4.6.1 Operating System Requirements SECURITY LEVEL 1 The following requirements shall apply to operating systems for Security Level 1. • For Security Level 1 only, the operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded).
• The operating system shall prevent all operators and executing processes from modifying executing cryptographic processes (i.e., loaded and executing cryptographic program images). In this case, executing processes refer to all non-operating system processes (i.e., operator-initiated), cryptographic or not. • The operating system shall prevent operators and executing processes from reading cryptographic software stored within the cryptographic boundary.
SECURITY LEVEL 4 In addition to the applicable requirements for Security Levels 1, 2, and 3, the following requirements shall also apply to operating systems for Security Level 4. • 4.7 All cryptographic software, cryptographic keys and CSPs, and control and status information shall be under the control of ! an operating system that meets the functional requirements specified in the Protection Profiles listed in Annex B.
4.7.2 Key Generation A cryptographic module may generate cryptographic keys internally. Cryptographic keys generated by the cryptographic module for use by an Approved algorithm or security function shall be generated using an Approved key generation method. Approved key generation methods are listed in Annex C to this standard. If an Approved key generation method requires input from a RNG, then an Approved RNG that meets the requirements specified in Section 4.7.1 shall be used.
All encrypted secret and private keys, entered into or output from a cryptographic module and used in an Approved mode of operation, shall be encrypted using an Approved algorithm. Public keys may be entered into or output from a cryptographic module in plaintext form. A cryptographic module shall associate a key (secret, private, or public) entered into or output from the module with the correct entity (i.e., person, group, or process) to which the key is assigned.
4.7.5 Key Storage Cryptographic keys stored within a cryptographic module shall be stored either in plaintext form or encrypted form. Plaintext secret and private keys shall not be accessible from outside the cryptographic module to unauthorized operators. A cryptographic module shall associate a cryptographic key (secret, private, or public) stored within the module with the correct entity (e.g., person, group, or process) to which the key is assigned.
Documentation shall specify: • the self-tests performed by a cryptographic module, including power-up and conditional tests, • the error states that a cryptographic module can enter when a self-test fails, and • the conditions and actions necessary to exit the error states and resume normal operation of a cryptographic module (i.e., this may include maintenance of the module, or returning the module to the vendor for servicing.) 4.9.
Section 4.1). If the calculated result does not equal the previously generated result, the software/firmware test shall fail. If an EDC is used, the EDC shall be at least 16 bits in length. Critical functions test. Other security functions critical to the secure operation of a cryptographic module shall be tested when the module is powered up as part of the power-up tests. Other critical security functions performed under specific conditions shall be tested as conditional tests.
Continuous random number generator test. If a cryptographic module employs Approved or nonApproved RNGs in an Approved mode of operation, the module shall perform the following continuous random number generator test on each RNG that tests for failure to a constant value. 1. If each call to a RNG produces blocks of n bits (where n > 15), the first n-bit block generated after power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit block to be generated.
4.10.2 Delivery and Operation Delivery and operation specifies the security requirements for the secure delivery, installation, and startup of a cryptographic module, providing assurance that the module is securely delivered to authorized operators, and is installed and initialized in a correct and secure manner. SECURITY LEVEL 1 For Security Level 1, documentation shall specify the procedures for secure installation, initialization, and startup of a cryptographic module.
• All software and firmware components within a cryptographic module shall be implemented using a high-level language, except that the limited use of a low-level language (e.g., assembly language or microcode) is allowed if essential to the performance of the module or when a high-level language is not available. • If HDL is used, all hardware components within a cryptographic module shall be implemented using a high-level specification language.
• the administrative functions, security events, security parameters (and parameter values, as appropriate), physical ports, and logical interfaces of the cryptographic module available to the crypto officer, • procedures on how to administer the cryptographic module in a secure manner, and • assumptions regarding user behavior that are relevant to the secure operation of the cryptographic module.
module, revealing certain features and implementations of cryptographic algorithms and subsequently revealing the values of cryptographic keys. Cryptographic modules with limited physical security appear to be at greatest risk. Proper selection of physical security features may be used to reduce the risk of this attack.
APPENDIX A: SUMMARY OF DOCUMENTATION REQUIREMENTS The following check list summarizes the documentation requirements of this standard. All documentation shall be provided to the validation facility by the vendor of a cryptographic module. CRYPTOGRAPHIC MODULE SPECIFICATION • Specification of the hardware, software, and firmware components of a cryptographic module, specification of the cryptographic boundary surrounding these components, and description of the physical configuration of the module.
• Specification of the services, operations, or functions provided by a cryptographic module, both Approved and non-Approved. For each service, specification of the service inputs, corresponding service outputs, and the authorized role(s) in which the service can be performed.
• Specification of the key establishment methods employed by a cryptographic module. (Security Levels 1, 2, 3, and 4) • Specification of the key entry and output methods employed by a cryptographic module.
• If a cryptographic module contains hardware components, specification of the schematics and/or Hardware Description Language (HDL) listings for the hardware components. (Security Levels 1, 2, 3, and 4) • Functional specification that informally describes a cryptographic module, the external ports and interfaces of the module, and the purpose of the interfaces.
APPENDIX B: RECOMMENDED SOFTWARE DEVELOPMENT PRACTICES This Appendix is provided for informational purposes only and does not contain security requirements applicable to cryptographic modules within the scope of the standard. Life-cycle software engineering recommendations (dealing with the specification, construction, verification, testing, maintenance, and documentation of software) should be followed.
• Equivalence of variables should not be used to permit multiple memory usage for conflicting purposes. • Robust command parsing and range checking mechanisms should be implemented to guard against malformed requests, out-of-range parameters, and I/O buffer overflows. IN-LINE DOCUMENTATION • Each software module, procedure, and major programming construct should be documented specifying the functions performed along with a (formal or informal) specification of preconditions and postconditions.
APPENDIX C: CRYPTOGRAPHIC MODULE SECURITY POLICY A cryptographic module security policy shall be included in the documentation provided by the vendor. The following paragraphs outline the required contents of the security policy. C.
C.3.1 Identification and Authentication Policy The cryptographic module security policy shall specify an identification and authentication policy, including • all roles (e.g., user, crypto officer, and maintenance) and associated type of authentication (e.g., identity-based, role-based, or none) and • the authentication data required of each role or operator (e.g., password or biometric data) and the corresponding strength of the authentication mechanism. C.3.
Role Type of Authentication Authentication Data … … … … … … … … Table C1. Roles and Required Identification and Authentication Authentication Mechanism Strength of Mechanism … … … … Table C2. Strengths of Authentication Mechanisms Role … Authorized Services … … … … … Table C3. Services Authorized for Roles Service … … Cryptographic Keys and CSPs Type(s) of Access (e.g., RWE) … … … … … … … … Table C4.
Physical Security Mechanisms Recommended Frequency of Inspection/Test Inspection/Test Guidance Details … … … … … … … … … … Table C5. Inspection/Testing of Physical Security Mechanisms Other Attacks Mitigation Mechanism … … … … … … Specific Limitations … … … … Table C6.
APPENDIX D: SELECTED BIBLIOGRAPHY American Bankers Association, Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (rDSA), ANSI X9.31-1998, Washington, D.C., 1998. American Bankers Association, Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52-1998, Washington, D.C., 1998. American Bankers Association, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm, American National Standard X9.
National Institute of Standards and Technology and Communications Security Establishment, Derived Test Requirements(DTR) for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, available at URL: http://www.nist.gov/cmvp. National Institute of Standards and Technology, DES Modes of Operation, Federal Information Processing Standards Publication 81, December 2, 1980.
APPENDIX E: APPLICABLE INTERNET UNIFORM RESOURCE LOCATORS (URL) Communications Security Establishment (CSE): http://www.cse-cst.gc.ca Cryptographic Module Validation Program (CMVP): http://www.nist.gov/cmvp NIST Information Technology Laboratory (NIST ITL): http://www.nist.gov/itl NIST Security Publications including FIPS and Special Publications: http://csrc.nist.gov/publications National Technical Information Service (NTIS): http://www.ntis.
CHANGE NOTICES Change Notice 1 (Superseded by Change Notice 2) FIPS PUB 140-2, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES U.S.
Change Notice 2 FIPS PUB 140-2, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES U.S.
Approved deterministic RNG or 2) to generate initialization vectors (IVs) for Approved security function(s). The seed and seed key shall not have the same value. Documentation shall specify each RNG (Approved and non-Approved) employed by a cryptographic module. 4.9.1 Power-Up Tests Power-up tests shall be performed by a cryptographic module when the module is powered up (after being powered off, reset, rebooted, etc.).
If a cryptographic module includes two independent implementations of the same cryptographic algorithm, then: • the known-answer test may be omitted, • the outputs of two implementations shall be continuously compared, and • if the outputs of two implementations are not equal, the cryptographic algorithm test shall fail. Software/firmware integrity test. A software/firmware integrity test using an error detection code (EDC) or Approved authentication technique (e.g.
A run is defined as a maximal sequence of consecutive bits of either all ones or all zeros that is part of the 20,000 bit sample stream. The incidences of runs (for both consecutive zeros and consecutive ones) of all lengths (≥ 1) in the sample stream should be counted and stored. The test is passed if the runs that occur (of lengths 1 through 6) are each within the corresponding interval specified in the table below. This must hold for both the zeros and ones (i.e.
Security Level 1 Security Level 2 Security Level 3 Security Level 4 Cryptographic Module Specification Specification of cryptographic module, cryptographic boundary, Approved algorithms, and Approved modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. Statement of module security policy. Cryptographic Module Ports and Interfaces Required and optional interfaces. Specification of all interfaces and of all input and output data paths.
Change Notice 3 FIPS PUB 140-2, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES U.S.
Change Notice 4 FIPS PUB 140-2, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES U.S.
