1. Name of Standard. Security Requirements for Cryptographic Modules (FIPS PUB 140-1).
2. Category of Standard. Computer Security Standard, Cryptography
3. Explanation. This standard specifies the security requirements that are to be satisfied by a cryptographic module utilized within a security system protecting unclassified information within computer and telecommunication systems (including voice systems). The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include basic design and documentation, module interfaces, authorized roles and services, physical security, software security, operating system security, key management, cryptographic algorithms, electromagnetic interference/electromagnetic compatibility (EMI/EMC), and self-testing. This standard supersedes FIPS 140, General Security Requirements for Equipment Using the Data Encryption Standard, in its entirety.
4. Approving Authority. Secretary of Commerce.
5. Maintenance Agency. Department of Commerce, National Institute of Standards and Technology, (Computer Systems Laboratory).
6. Cross Index.
7. Applicability. This standard is applicable to all Federal agencies that use cryptographic-based security systems to protect unclassified information within computer and telecommunication systems (including voice systems) that are not subject to Section 2315 of Title 10, U.S. Code, or Section 3502(2) of Title 44, U.S. Code. This standard shall be used in designing, acquiring and implementing cryptographic-based security systems within computer and telecommunication systems (including voice systems), operated by a Federal agency or by a contractor of a Federal agency or other organization that processes information (using a computer or telecommunications system) on behalf of the Federal Government to accomplish a Federal function. Federal agencies which use cryptographic-based security systems for protecting classified information may use those systems for protecting unclassified information in lieu of systems that comply with this standard. Non-Federal government organizations are encouraged to adopt and use this standard when it provides the desired security for protecting valuable or sensitive information.
8. Applications. Cryptographic-based security systems may be utilized in various computer and telecommunication (including voice) applications (e.g., data storage, access control and personal identification, radio, facsimile, video) and in various environments (e.g., centralized computer facilities, office environments, hostile environments). The cryptographic services (e.g., encryption, authentication, digital signature, key management) provided by a cryptographic module will be based on many factors which are specific to the application and environment. The security level of a cryptographic module shall be chosen to provide a level of security appropriate for the security requirements of the application and environment in which the module is to be utilized and the security services which the module is to provide. The security requirements for a particular security level include both the security requirements specific to that level and the security requirements that apply to all modules regardless of the level. System characteristics not related to security (e.g., telecommunications interoperability) are beyond the scope of this standard.
9. Specifications. Federal Information Processing Standard (FIPS) 140-1, Security Requirements for Cryptographic Modules (affixed).
10. Implementations. This standard covers implementations of cryptographic modules including, but not limited to, hardware components or modules, software programs or modules, computer firmware, or any combination thereof. Cryptographic modules that are validated by NIST, or that comply with the requirements of the FIPS 140-1 implementation and FIPS 140 acquisition schedules in Section 14 of the announcement of this standard, will be considered as complying with this standard. Information about the FIPS 140-1 validation program can be obtained from the National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD 20899.
11. FIPS Approved Security Methods. Cryptographic modules that comply with this standard shall employ cryptographic algorithms, cryptographic key generation algorithms and key distribution techniques, and authentication techniques that have been FIPS approved for protecting Federal Government unclassified information. FIPS approved cryptographic algorithms, cryptographic key generation algorithms and key distribution techniques, and authentication techniques include those that are either:
Information about approved cryptographic methods and approved operating system evaluation authorities and criteria can be obtained from NIST.
12. Interpretation. Resolution of questions regarding this standard will be provided by NIST. Questions concerning the content and specifications should be addressed to: Director, Computer Systems Laboratory, ATTN: FIPS 140-1 Interpretation, National Institute of Standards and Technology, Gaithersburg, MD 20899.
13. Export Control. Certain cryptographic devices and technical data regarding them are deemed to be defense articles (i.e., inherently military in character) and are subject to Federal government export controls as specified in Title 22, Code of Federal Regulations, Parts 120-128. Some exports of cryptographic modules conforming to this standard and technical data regarding them must comply with these Federal regulations and be licensed by the U.S. Department of State. Other exports of cryptographic modules conforming to this standard and technical data regarding them fall under the licensing authority of the Bureau of Export Administration of the U.S. Department of Commerce. The Department of Commerce is responsible for licensing cryptographic devices used for authentication, access control, proprietary software, automatic teller machines (ATMs), and certain devices used in other equipment and software. For advice concerning which agency has licensing authority for a particular cryptographic device, please contact the respective agencies.
14. Implementation Schedule. Table 1 summarizes the implementation schedule for FIPS 140-1. The effective date of this standard is June 30, 1994.
For a one year period following the six months after the establishment of the FIPS 140-1 validation program, agencies shall purchase either equipment with validated FIPS 140-1 cryptographic modules, or equipment whose cryptographic modules have been submitted for FIPS 140-1 validation. After this period, only FIPS 140-1 validated cryptographic modules will be considered as meeting the provisions of this standard.
Table 2 summarizes the schedule for acquisition of FIPS 140 compliant equipment. For up to three years following June 30, 1994, equipment with cryptographic modules complying to FIPS 140, General Security Requirements for Equipment Using the Data Encryption Standard (formerly Federal Standard 1027), may be purchased in lieu of equipment with modules that comply with this standard. These modules either shall have been endorsed by the National Security Agency (NSA) as complying to Federal Standard 1027, or shall be affirmed in writing by the manufacturer as complying to FIPS 140. NSA endorsed modules shall have been endorsed prior to January 11, 1994. A list of endorsed products (NSA Endorsed Data Encryption Standard (DES) Products List) is available from the NSA. For modules affirmed by the manufacturer as complying with FIPS 140, a copy of the written affirmation shall have been sent by the manufacturer to the Director of the Computer Systems Laboratory at NIST prior to June 30, 1994. A list of these modules is available from NIST.
Equipment purchased under the above conditions may continue to be used for the lifetime of the equipment without the need for further affirmation or validation for conformance to this standard.
15. Qualifications. The security requirements specified in this standard are based upon information provided by many sources within the Federal government and private industry. The requirements are designed to protect against adversaries mounting cost-effective attacks on unclassified government or commercial data (e.g., hackers, organized crime, economic competitors). The primary goal in designing an effective security system is to make the cost of any attack greater than the possible payoff.
While the security requirements specified in this standard are intended to maintain the security of a cryptographic module, conformance to this standard does not guarantee that a particular module is secure. It is the responsibility of the manufacturer of a cryptographic module to build the module in a secure manner.
Similarly, the use of a cryptographic module that conforms to this standard in an overall system does not guarantee the security of the overall system. The responsible authority in each agency shall assure that an overall system provides an acceptable level of security.
Since a standard of this nature must be flexible enough to adapt to advancements and innovations in science and technology, this standard will be reviewed every 5 years in order to consider new or revised requirements that may be needed to meet technological and economic changes.
16. Waiver Procedure. Under certain exceptional circumstances, the heads of Federal agencies may approve waivers to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such authority only to a senior official designated pursuant to Section 3506(b) of Title 44, U.S. Code. Waivers shall be granted only when:
In addition, notice of each waiver granted and each delegation of authority to approve waivers shall be sent promptly to the Committee on Government Operations of the House of Representatives and the Committee on Government Affairs of the Senate and shall be published promptly in the Federal Register.
When the determination on a waiver applies to the procurement of equipment and/or services, a notice of the waiver determination must be published in the Commerce Business Daily as a part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that notice is published, by amendment to such notice.
A copy of the waiver, any supporting documents, the document approving the waiver and any supporting and accompanying documents, with such deletions as the agency is authorized and decides to make under Section 552(b) of Title 5, U.S. Code, shall be part of the procurement documentation and retained by the agency.
17. Where to obtain copies. Copies of this publication are available for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication 140-1 (FIPS PUB 140-1), and title. When microfiche is desired, this should be specified. Payment may be made by check, money order, credit card, or deposit account.
CONTENTS
1 OVERVIEW 1.1 Security Level 1 1.2 Security Level 2 1.3 Security Level 3 1.4 Security Level 4 2 DEFINITIONS AND ACRONYMS 2.1 Definitions 2.2 Acronyms 3 FUNCTIONAL SECURITY OBJECTIVES 4 SECURITY REQUIREMENTS 4.1 Cryptographic Modules 4.2 Module Interfaces 4.3 Roles and Services 4.3.1Roles 4.3.2Services 4.3.3Operator Authentication 4.4 Finite State Machine Model 4.5 Physical Security 4.5.1Single-Chip Cryptographic Modules 4.5.2Multiple-Chip Embedded Cryptographic Modules 4.5.3Multiple-Chip Standalone Cryptographic Modules 4.5.4Environmental Failure Protection/Testing 4.5.4.1Environmental Failure Protection Features 4.5.4.2Environmental Failure Testing Procedures 4.6 Software Security 4.7 Operating System Security 4.8 Cryptographic Key Management 4.8.1Key Generation 4.8.2Key Distribution 4.8.3Key Entry and Output 4.8.4Key Storage 4.8.5Key Destruction 4.8.6Key Archiving 4.9 Cryptographic Algorithms 4.10 Electromagnetic Interference/ElectromagneticCompatibility (EMI/EMC) 4.11 Self-Tests 4.11.1Power-Up Tests 4.11.2Conditional Tests APPENDIX A: SUMMARY OF DOCUMENTATION REQUIREMENTS APPENDIX B: RECOMMENDED SOFTWARE DEVELOPMENT PRACTICES APPENDIX C: SELECTED REFERENCES
This standard specifies the security requirements that are to be satisfied by a cryptographic module utilized within a security system protecting unclassified information in computer and telecommunication systems (including voice systems) that are not subject to Section 2315 of Title 10, U.S. Code, or Section 3502(2) of Title 44, U.S. Code. Cryptographic modules conforming to this standard shall meet the applicable security requirements described herein.
This standard was developed by a government and industry working group composed of both users and vendors. The working group identified requirements for four security levels for cryptographic modules to provide for a wide spectrum of data sensitivity (e.g., low value administrative data, million dollar funds transfers, and life protecting data), and a diversity of application environments (e.g., a guarded facility, an office, and a completely unprotected location). Each security level offers an increase in security over the preceding level. These four increasing levels of security will allow cost-effective solutions that are appropriate for different degrees of data sensitivity and different application environments.
While the security requirements specified in this standard are intended to maintain the security of a cryptographic module, conformance to this standard does not guarantee that a particular module is secure. It is the responsibility of the manufacturer of a cryptographic module to build the module in a secure manner.
Similarly, the use of a cryptographic module that conforms to this standard in an overall system does not guarantee the security of the overall system. The security level of a cryptographic module shall be chosen to provide a level of security appropriate for the security requirements of the application and environment in which the module is to be utilized and the security services which the module is to provide. The responsible authority in each agency or department shall assure that the agency or department's computer or telecommunication systems which utilize a cryptographic module provide an acceptable level of security for the given application and environment.
NIST emphasizes the importance of computer security awareness and of making information security a management priority that is communicated to all employees. Since computer security requirements will vary for different applications, organizations should identify their information resources and determine the sensitivity to and potential impact of losses. Controls should be based on the potential risks and selected from available controls, including administrative policies and procedures, physical and environmental controls, information and data controls, software development and acquisition controls, and backup and contingency planning.
NIST has developed many of the needed basic controls to protect computer information, and has issued standards and guidelines covering both management and technical approaches to computer security. These include standards for cryptographic functions which will be implemented in cryptographic modules as specified in this standard. This standard is expected to be the foundation for NIST's current and future cryptographic standards.
1.1 Security Level 1
Security Level 1 provides the lowest level of security. It specifies basic security requirements for a cryptographic module (e.g., the encryption algorithm must be a FIPS approved algorithm), but it differs from the higher levels in several respects. No physical security mechanisms are required in the module beyond the requirement for production-grade equipment.
Examples of Level 1 systems include Integrated Circuit (IC) cards and add-on security products. It is commonly felt that IC cards enhance the security of most systems. IC cards may be used as a secure storage medium when distributing cryptographic keys and may also implement cryptographic algorithms. Many vendors produce personal computer (PC) encryption boards which will meet the Level 1 requirements. NIST has validated the correct implementation of NIST cryptographic standards in several IC cards and encryption boards.
Level 1 allows software cryptographic functions to be performed in a general purpose personal computer (PC). NIST believes that such implementations are often appropriate in low-level security applications. The implementation of PC cryptographic software may be more cost-effective than hardware-based mechanisms. This will enable agencies to avoid the situation that exists today whereby the decision is often made not to cryptographically protect data because hardware is considered too expensive.
1.2 Security Level 2
Security Level 2 improves the physical security of a Security Level 1 cryptographic module by adding the requirement for tamper evident coatings or seals, or for pick-resistant locks. Tamper evident coatings or seals, which are available today, would be placed on a cryptographic module so that the coating or seal would have to be broken in order to attain physical access to the plaintext cryptographic keys and other critical security parameters within the module. Pick-resistant locks would be placed on covers or doors to protect against unauthorized physical access. These requirements provide a low cost means for physical security and avoid the cost of the higher level of protection involving hard opaque coatings or significantly more expensive tamper detection and zeroization circuitry.
Level 2 provides for role-based authentication in which a module must authenticate that an operator is authorized to assume a specific role and perform a corresponding set of services.
Level 2 also allows software cryptography in multi-user timeshared systems when used in conjunction with a C2 or equivalent trusted operating system. The ratings C2, B1 and B2 ratings are in accordance with the TCSEC (see Appendix C). Many security experts feel that a trusted operating system is needed in order for software cryptography to be implemented with a level of trust comparable to hardware cryptography. This enables multi-user timeshared systems to implement cryptographic functions in software when this level of security is cost effective.
1.3 Security Level 3
Security Level 3 requires enhanced physical security which is generally available in many existing commercial security products. Unlike Security Level 2 which employs locks to protect against tampering with a cryptographic module, or employs coatings or seals to detect when tampering has occurred, Level 3 attempts to prevent the intruder from gaining access to critical security parameters held within the module. For example, a multi-chip embedded module must be contained in a strong enclosure, and if a cover is removed or a door is opened, the critical security parameters are zeroized. As another example, a module must be enclosed in a hard, opaque potting material to deter access to the contents.
Level 3 provides for identity-based authentication, which is stronger than the role based-authentication used in Level 2. A module must authenticate the identity of an operator and verify that the identified operator is authorized to assume a specific role and perform a corresponding set of services.
Level 3 provides stronger requirements for entering and outputting critical security parameters. The data ports used for critical security parameters must be physically separated from other data ports. Furthermore, the parameters must either be entered into or output from the module in encrypted form (in which case they may travel through enclosing or intervening systems) or be directly entered into or output from the module (without passing through enclosing or intervening systems) using split knowledge procedures.
Level 3 allows software cryptography in multi-user timeshared systems when a B1 or equivalent trusted operating system is employed along with a trusted path for the entry and output of critical security parameters. A B1 or better trusted operating system with a trusted path would have the capability to protect cryptographic software and critical security parameters from other untrusted software that may run on the system. Such a system could prevent plaintext from being mixed with ciphertext, and it could prevent the unintentional transmission of plaintext keys.
1.4 Security Level 4
Security Level 4 provides the highest level of security. Although most existing products do not meet this level of security, some products are commercially available which meet many of the Level 4 requirements. Level 4 physical security provides an envelope of protection around the cryptographic module. Whereas the tamper detection circuits of lower level modules may be bypassed, the intent of Level 4 protection is to detect a penetration of the device from any direction. For example, if one attempts to cut through the enclosure of the cryptographic module, the attempt should be detected and all critical security parameters should be zeroized. Level 4 devices are particularly useful for operation in a physically unprotected environment where an intruder could possibly tamper with the device.
Level 4 also protects a module against a compromise of its security 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 could be used to thwart a module's defense during an attack. A module is required to either include special environmental protection features designed to detect fluctuations and zeroize critical security parameters, or to undergo rigorous environmental failure testing that provides 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.
Level 4 allows software cryptography in multi-user timeshared systems when a B2 or equivalent trusted operating system is employed. A B2 trusted operating system provides additional assurances of the correct operation of the security features of the operating system.
2.1 Definitions
The following definitions are used throughout this standard:
Automated key distribution: the distribution of cryptographic keys, usually in encrypted form, using electronic means, such as a computer network (e.g., down-line key loading, the automated key distribution protocols of ANSI X9.17).
Compromise: the unauthorized disclosure, modification, substitution or use of sensitive data (including plaintext cryptographic keys and other critical security parameters).
Confidentiality: the property that sensitive information is not disclosed to unauthorized individuals, entities or processes.
Control information: information that is entered into a cryptographic module for the purposes of directing the operation of the module.
Critical security parameters: security-related information (e.g., cryptographic keys, authentication data such as passwords and PINs) appearing in plaintext or otherwise unprotected form and whose disclosure or modification can compromise the security of a cryptographic module or the security of the information protected by the module.
Cryptographic boundary: an explicitly defined contiguous perimeter that establishes the physical bounds of a cryptographic module.
Cryptographic key (key): a parameter used in conjunction with a cryptographic algorithm that determines:
Cryptographic module: the set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the cryptographic boundary of the module.
Cryptographic module security policy: a precise specification of the security rules under which a cryptographic module must operate, including the security rules derived from the requirements of this standard and the additional security rules imposed by the manufacturer.
Data authentication code (DAC): a cryptographic checksum, based on DES (see FIPS PUB 113); also known as a Message Authentication Code (MAC) in ANSI standards.
Data key: a cryptographic key which is used to cryptographically process data (e.g., encrypt, decrypt, sign, authenticate).
Data path: the physical or logical route over which data passes; a physical data path may be shared by multiple logical data paths.
Digital signature: a non-forgeable transformation of data that allows the proof of the source (with non- repudiation) and the verification of the integrity of that data.
Electromagnetic compatibility (EMC): the ability of electronic systems to operate in their intended environments without suffering an unacceptable degradation of the performance as a result of unintentional electromagnetic radiation or response.
Electromagnetic interference (EMI): electromagnetic phenomena which either directly or indirectly can contribute to a degradation in the performance of an electronic system.
Environmental failure protection (EFP): the use of features designed to protect against a compromise of the security of a cryptographic module due to environmental conditions or fluctuations outside of the module's normal operating range.
Environmental failure testing (EFT): the use of testing to provide a reasonable assurance that a cryptographic module will not be affected by environmental conditions or fluctuations outside of the module's normal operating range in a manner that can compromise the security of the module.
Electronic key entry: the entry of cryptographic keys into a cryptographic module in electronic form using a key loading device. The user entering the key may have no knowledge of the value of the key being entered.
Encrypted key (ciphertext key): a cryptographic key that has been encrypted with a key encrypting key, a PIN or a password in order to disguise the value of the underlying plaintext key.
Error detection code (EDC): a code computed from data and comprised of redundant bits of information designed to detect, but not correct, unintentional changes in the data.
Finite state machine (FSM): a mathematical model of a sequential machine which is comprised of a finite set of states, a finite set of inputs, a finite set of outputs, a mapping from the sets of inputs and states into the set of states (i.e., state transitions), and a mapping from the sets of inputs and states onto the set of outputs (i.e., an output function).
FIPS approved security method: a security method (e.g., cryptographic algorithm, cryptographic key generation algorithm or key distribution technique, authentication technique, or evaluation criteria) that is either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS.
Firmware: the programs and data (i.e., software) permanently stored in hardware (e.g., in ROM, PROM, or EPROM) such that the programs and data cannot be dynamically written or modified during execution. Programs and data stored in EEPROM are considered as software.
Hardware: the physical equipment used to process programs and data in a cryptographic module.
Initialization vector (IV): a vector used in defining the starting point of an encryption process within a cryptographic algorithm (e.g., the DES Cipher Block Chaining (CBC) mode of operation).
Integrity: the property that sensitive data has not been modified or deleted in an unauthorized and undetected manner.
Interface: a logical section of a cryptographic module that defines a set of entry or exit points that provide access to the module, including information flow or physical access.
Input data: information that is entered into a cryptographic module for the purposes of transformation or computation.
Key encrypting key: a cryptographic key that is used for the encryption or decryption of other keys.
Key loader: a self-contained unit which is capable of storing at least one plaintext or encrypted cryptographic key or key component which can be transferred, upon request, into a cryptographic module.
Key management: the activities involving the handling of cryptographic keys and other related security parameters (e.g., IVs, counters) during the entire life cycle of the keys, including their generation, storage, distribution, entry and use, deletion or destruction, and archiving.
Manual key distribution: the distribution of cryptographic keys, often in a plaintext form requiring physical protection, but using a non-electronic means, such as a bonded courier.
Manual key entry: the entry of cryptographic keys into a cryptographic module from a printed form, using devices such as buttons, thumb wheels or a keyboard.
Microcode: the elementary computer instructions that correspond to an executable program instruction.
Operator: an individual accessing a cryptographic module, either directly or indirectly via a process operating on his or her behalf, regardless of the specific role the individual assumes.
Output data: information that is to be output from a cryptographic module that has resulted from a transformation or computation in the module.
Password: a string of characters used to authenticate an identity or to verify access authorization.
Personal Identification Number (PIN): a 4 to 12 character alphanumeric code or password used to authenticate an identity, commonly used in banking applications.
Physical protection: the safeguarding of a cryptographic module or of cryptographic keys or other critical security parameters using physical means.
PIN: see Personal Identification Number.
Plaintext key: an unencrypted cryptographic key which is used in its current form.
Port: a functional unit of a cryptographic module through which data or signals can enter or exit the module. Physically separate ports do not share the same physical pin or wire.
Private key: a cryptographic key used with a public key cryptographic algorithm, uniquely associated with an entity, and not made public.
Public key: a cryptographic key used with a public key cryptographic algorithm, uniquely associated with an entity, and which may be made public.
Public key certificate: a set of data that unambiguously identifies an entity, contains the entity's public key, and is digitally signed by a trusted party.
Public key (asymmetric) cryptographic algorithm: a cryptographic algorithm that uses two related keys, a public key and a private key; the two keys have the property that, given the public key, it is computationally infeasible to derive the private key.
Secret key: a cryptographic key used with a secret key cryptographic algorithm, uniquely associated with one or more entities, and which shall not be made public. The use of the term "secret" in this context does not imply a classification level, rather the term implies the need to protect the key from disclosure or substitution.
Secret key (symmetric) cryptographic algorithm: a cryptographic algorithm that uses a single, secret key for both encryption and decryption.
Security policy: see Cryptographic Module Security Policy.
Software: the programs, and possibly associated data that can be dynamically written and modified.
Split knowledge: a condition under which two or more entities separately have key components which individually convey no knowledge of the plaintext key which will be produced when the key components are combined in the cryptographic module.
Status information: information that is output from a cryptographic module for the purposes of indicating certain operational characteristics or states of the module.
System software: the special software (e.g., operating system, compilers or utility programs) designed for a specific computer system or family of computer systems to facilitate the operation and maintenance of the computer system, programs, and data.
Trusted path: a mechanism by which a person or process can communicate directly with a cryptographic module and which can only be activated by the person, process or module, and cannot be imitated by untrusted software within the module.
Zeroization: a method of erasing electronically stored data by altering the contents of the data storage so as to prevent the recovery of the data.
2.2 Acronyms
The following acronyms and abbreviations are used throughout this standard:
ANSI American National Standards Institute ATM Automated Teller Machine CBC Cipher Block Chaining DAC Data Authentication Code DES Data Encryption Standard DOC Department of Commerce DOD Department of Defense EDC Error Detection Code EFP Environmental Failure Protection EFT Environmental Failure Testing EMC Electromagnetic Compatibility EMI Electromagnetic Interference EPROM Erasable Programmable Read-Only Memory E2PROM Electronically-Erasable Programmable Read-Only Memory FCC Federal Communications Commission FIPS Federal Information Processing Standard FIPS PUB FIPS Publication FSM Finite State Machine IC Integrated Circuit IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization ITSEC Information Technology Security Evaluation Criteria IV Initialization Vector LCD Liquid Crystal Display LED Light Emitting Diode MAC Message Authentication Code NBS National Bureau of Standards NIST National Institute of Standards and Technology (formerly the National Bureau of Standards) NSA National Security Agency PC Personal Computer PIN Personal Identification Number PROM Programmable Read-Only Memory RAM Random Access Memory ROM Read-Only Memory TCB Trusted Computing Base TCSEC Trusted Computer System Evaluation Criteria
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:
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. These areas include basic design and documentation, module interfaces, authorized roles and services, physical security, software security, operating system security, key management, cryptographic algorithms, electromagnetic interference/electromagnetic compatibility (EMI/EMC), and self-testing. Table 1 summarizes the security requirements in each of these areas.
(NOTE: The CSL Bulletin for FIPS 140-1 has important additional information concerning the Table 2 below.)
Table 2. Summary of Physical Security Requirements | ||||
---|---|---|---|---|
Security Level 1 | Security Level 2 | Security Level 3 | Security Level 3 |
Crypto Module | Specification of cryptographic module and crytographic boundary. Description of crytographic module including all hardware, software, and firmware components. Statement of module security policy. |
Module Interfaces | Required and optional interfaces. Specification of all interfaces and of all internal data paths. | Data ports for critical security parameters physically separated from other data ports. |
Roles & Services | Logical separation of required and optional roles and services. | Role-based operator authentication. | Identity-based operator authentication. |
Finite State Machine | Specification of finite state machine model. Required states and optional states. State transition diagram and specification of state transitions. |
Physical Security | Production grade equipment. | Locks or tamper evidence. | Tamper detection and response for covers and doors. | tamper detection and response envelope. |
EFP/EFT | No requirements. | Temperature and voltage. |
Software Security | Specification of software design. Relate software to finite state machine model. | High-level language implementation. | Formal model. Pre- and post- conditions. |
Operating System Security | Executable code. Authenticated. Single user, single process. | Controlled access protection (C2 or equiv.). | Labelled protection (B1 or equiv.). Trusted communications path. | Structured protection (B2 or equiv.). |
Key Manage- ment | FIPS approved generation/distribution techniques. | Entry/exit of keys in encrypted from or direct entry/exit with split knowledge procedures. |
Cryptic Algorithms | FIPS approved cryptographic algorithms for protecting unclassified information. |
EMI/EMC | FCC Part 15, Subpart J, Class A (Business use). Applicable FCC requirements (for voice). | FCC part 15. Subpart J, Class B (Home use.) |
Self-tests | Power-up tests and conditional tests. |
A cryptographic module shall be tested against the requirements of each area addressed in this section. The module shall be independently rated in each area. Several areas provide for increasing levels of security, with cumulative security requirements for each security level. In these areas, the module shall 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, the module shall receive a rating that reflects fulfillment of all of the requirements for that area.
In addition to receiving independent ratings for each of the security areas, a cryptographic module shall also receive an overall rating. The overall rating shall indicate (1) the minimum of the independent ratings received in the areas with levels, and (2) fulfillment of all the requirements in the other areas.
Many of the security requirements of this standard include specific documentation requirements. These requirements are summarized in Appendix A. The FIPS 140-1 validation procedures may require additional documentation. All documentation shall be provided to the validation facility by the manufacturer of a cryptographic module. Requirements for user documentation are beyond the scope of this standard, however, copies of the user and installation manuals for a cryptographic module shall also be provided to the validation facility.
4.1 Cryptographic Modules
A cryptographic module shall be a set of hardware, software, firmware, or some combination thereof, that implements cryptographic logic or processes. A cryptographic boundary shall be an explicitly defined contiguous perimeter that establishes the physical bounds of the cryptographic module. If a cryptographic module contains software or firmware, the cryptographic boundary shall be defined such that it contains the processor which executes the code. Parts of a cryptographic module can be excluded from the requirements of this standard if it can be shown that these parts do not affect the security of the module.
This standard allows three different physical configurations of a cryptographic module: single-chip modules, multi-chip embedded modules, and multi-chip standalone modules (see Section 4.5).
Documentation shall identify the hardware, software and firmware components of a cryptographic module, specify the cryptographic boundary surrounding these components, and describe the physical configuration of the module. The documentation shall include a block diagram depicting all of the major hardware components of the module and their interconnections, including any microprocessors, input/output buffers, plaintext/ciphertext buffers, control buffers, key storage, working memory, and program memory. The documentation shall also indicate any hardware, software or firmware components of a module that are excluded from the security requirements of this standard, and explain the rationale for the exclusion.
Documentation shall also completely specify the cryptographic module security policy, i.e., the security rules under which a module must operate. In particular, the security policy shall include the security rules derived from the security requirements of this standard and the security rules derived from any additional security requirements imposed by the manufacturer.
4.2 Module Interfaces
A cryptographic module shall be designed to restrict all information flow and physical access to a cryptographic module to logical interfaces that define all entry and exit points to and from the module. The module interfaces shall be logically distinct from each other, although they may physically share one port (e.g., input data and output data may enter and exit via the same port), or may be physically distributed over one or more ports (e.g., input data may enter via both a serial and a parallel port).
A cryptographic module shall have the following four logical interfaces ("input" and "output" are indicated from the perspective of the module):
For Security Levels 3 and 4, the data input and output port or ports used for plaintext cryptographic key components, plaintext authentication data, and other unprotected critical security parameters shall be physically separated from all other ports of the module. Furthermore, these ports shall allow for direct entry of plaintext cryptographic key components, plaintext authentication data, and other unprotected critical security parameters, as required in Section 4.8.3.
A cryptographic module optionally may include the following interfaces:
All physical and logical input and output data paths within the module shall be explicitly defined. All input data entering the module via the "data input" interface shall only pass through the input data path. All output data exiting the module via the "data output" interface shall pass through the output data path. In order to prevent the inadvertent output of sensitive information, two independent internal actions shall be required in order to output data via any output interface through which plaintext cryptographic keys or other critical security parameters or sensitive data could be output. The output data path shall be logically disconnected from the circuitry and processes performing key generation, manual key entry or key zeroization. Documentation shall include a complete specification of the defined input and output data paths.
4.3 Roles and Services
A cryptographic module shall be designed to support authorized roles and the corresponding services that can be performed within those roles. If a module can support multiple concurrent operators, then the module shall internally maintain the separation of the roles and services performed by each operator. Furthermore, depending on the security level, a cryptographic module may be required to employ access control mechanisms to authenticate an operator accessing the module (either directly or indirectly via a computer process acting on his or her behalf) and to verify that the operator is authorized to perform the desired roles and to perform the desired services within that role.
4.3.1 Roles
A cryptographic module shall support the following authorized roles:
4.3.2 Services
Services shall refer to all of the services, operations or functions that can be performed by a cryptographic module. Service inputs shall consist of all data or control inputs to the module that initiate or obtain specific services, operations, or functions. Service outputs shall consist of all data and status outputs that result from services, operations or functions initiated or obtained by service inputs. Each service shall result in a service output.
A cryptographic module shall, at a minimum, provide the following services:
4.3.3 Operator Authentication
For Security Levels 2, 3 and 4, a cryptographic module shall perform either role-based authentication or identity-based authentication of the operator accessing the module (either directly or indirectly via a computer process acting on his or her behalf) in order to verify that the operator is authorized to perform desired roles and services.
A module may implement any of a variety of authentication mechanisms, including, but not limited to, knowledge or possession of a password, PIN, cryptographic key or equivalent, possession of a physical key, token, or equivalent, or verification of personal characteristics (i.e., biometrics).
Services that are used to initialize the access control information needed to implement the access control mechanisms required herein, may require special treatment. For example, the first time that a crypto officer attempts to access a module, the module may not contain the authentication and authorization information required to authenticate the identity of the crypto officer and to verify his or her authorization to assume the crypto officer role. In these cases, other means (such as procedural controls, or factory-set or default authentication and authorization information) may be used to control access to the module.
SECURITY LEVEL 1
For Security Level 1, a cryptographic module is not required to employ authentication mechanisms to control access to the module. A module optionally may employ either role-based or identity-based authentication mechanisms in order to verify the authorization of the operator to assume the desired roles and to request corresponding services.
SECURITY LEVEL 2
For Security Level 2, a cryptographic module shall employ either role-based authentication mechanisms or identity-based mechanisms in order to verify the authorization of the operator to assume the desired roles and to request corresponding services.
SECURITY LEVELS 3 AND 4
For Security Levels 3 and 4, a cryptographic module shall employ identity-based authentication mechanisms in order to verify the authorization of the operator to assume the desired roles and to request corresponding services. Furthermore, plaintext authentication data (e.g., passwords and PINs), plaintext cryptographic key components, and other unprotected critical security parameters shall be entered via a port or ports that are physically separated from other ports, and that allow for direct entry (as required in Section 4.2).
4.4 Finite State Machine Model
All cryptographic modules shall be designed using a finite state machine model that explicitly specifies every operational and error state of the module.
A cryptographic module shall be designed using the following types of states:
4.5 Physical Security
A cryptographic module shall be designed to employ physical security mechanisms in order to restrict unauthorized physical access to the contents of the module and to deter unauthorized use or unauthorized modification of the module (including substitution of the entire module) when installed. The entire contents of a cryptographic module, including all hardware, firmware, software and data (including plaintext cryptographic keys and unprotected critical security parameters) shall be protected.
The physical security mechanisms employed by a cryptographic module depend largely on the physical embodiment of the module. The physical security requirements are separated into three distinct physical embodiments: single-chip modules, multiple-chip embedded modules, and multiple-chip standalone modules. Table 2 summarizes the physical security requirements for the three different physical embodiments of a module for each of the four security levels.
Table 2. Summary of Physical Security Requirements | |||
---|---|---|---|
Single Chip Modules | Multi-Chip Embedded Modules | Multi-Chip Standalone Modules | |
Security Level 1 | Production-grade chip (with standard passivation). | Production-grade chip and production-grade multi-chip embodiment. | production-grade-chips, production-grade multi-chip embodiment, and production-grade enclosure. |
Security Level 2 | Level 1 requirements. Opaque tamper evident coating. | Level 1 requirements. Opaque tamper evident coating. | Level 1 requirements. Opaque enclosure with mechanical locks or tamper evident seals for covers and doors. | Security Level 3 | Levels 1 and 2 requirements. Hard opaque tamper evident coating. | Levels 1 and 2 requirements. Hard opaque potting material, strong non-removable cover with removal detection and zeroization circuitry. Protected vents. | Levels 1 and 2 requirements. Hard opaque potting material, or strong enclosure with tamper response and zeroization circuitry for covers and doors. Protected vents. |
Security Level 4 | Levels 1, 2, and 3 requirements. Hard opaque removal resistant coating. EFP/EFT for temperature and voltage. | Levels 1, 2, and 3 requirements. Tamper detection envelope with tamper response and zeroization circuitry. EFP/EFT fro temperature and voltage. | Levels 1, 2, and 3 requirements. Tamper detection/response envelope with zeroization circuitry. EFP/EFT for temperature and voltage. |
Documentation shall include a complete specification of the physical embodiment and security level for which the physical security mechanisms of a cryptographic module are designed, as well as a complete description of the applicable physical security mechanisms that are employed by the module.
4.5.1 Single-Chip Cryptographic Modules
Single-chip cryptographic modules are implementations in which a single integrated circuit (IC) chip may be used as a standalone device or may be physically embedded within some other module or enclosure which may not be physically protected. Single-chip modules include single IC chips, smart cards with a single IC chip, and other systems that incorporate a single IC chip to implement cryptographic functions. Because of its small size and its fabrication, a single chip has some inherent tamper resistance. A few additional requirements provide reasonable physical security.
SECURITY LEVEL 1
The following requirement shall apply to a single-chip cryptographic module for Security Level 1.
In addition to the Security Level 1 requirement, the following requirement shall apply to a single-chip cryptographic module for Security Level 2.
In addition to the requirements for Security Levels 1 and 2, the following requirement shall also apply to a single-chip cryptographic module for Security Level 3.
In addition to the requirements for Security Levels 1, 2, and 3, the following requirements shall also apply to a single-chip cryptographic module for Security Level 4.
Multiple-chip embedded cryptographic modules are implementations in which two or more IC chips are interconnected and are physically embedded within some other module or enclosure which may not be physically protected. Multiple-chip embedded cryptographic modules include adaptors and expansion boards, and other modules that are not single chips and are not contained within physically protected standalone modules. Typical size and space constraints restrict the physical security mechanisms that can be effectively employed.
SECURITY LEVEL 1
The following requirements shall apply to a multiple-chip embedded cryptographic module for Security Level 1.
In addition to the requirements for Security Level 1, the following requirement shall apply to a multiple- chip embedded cryptographic module for Security Level 2.
In addition to the requirements for Security Levels 1 and 2, the following requirements shall apply to a multiple-chip embedded cryptographic module for Security Level 3.
In addition to the requirements for Security Levels 1, 2 and 3, the following requirements shall also apply to a multiple-chip embedded cryptographic module for Security Level 4.
Multiple-chip standalone cryptographic modules are implementations in which the entire enclosure is physically protected. The modules may contain two or more IC chips that are interconnected (e.g., an IC printed circuit board or ceramic substrate). Typical size and space constraints may no longer restrict the physical security mechanisms that can be effectively employed.
SECURITY LEVEL 1
The following requirements shall apply to a standalone cryptographic module for Security Level 1.
In addition to the requirements for Security Level 1, the following requirements shall also apply to a standalone cryptographic module for Security Level 2.
In addition to the requirements for Security Levels 1 and 2, the following requirements shall also apply to a standalone cryptographic module for Security Level 3.
In addition to the requirements for Security Levels 1, 2 and 3, the following requirements shall also apply to a standalone cryptographic module for Security Level 4.
Electronic devices and circuitry are designed to operate within a particular range of environmental conditions. If the devices or circuitry are operated outside of this range, their correct operation is not guaranteed. Deliberate or accidental excursions outside the specified normal operating range can cause erratic operation or failure of the electronic devices or circuitry within a cryptographic module that can compromise the security of the module. In order to provide reasonable assurance that the security of a cryptographic module cannot be compromised by environmental conditions, the module may either employ environmental failure protection (EFP) features or undergo environmental failure testing (EFT).
For Security Levels 1, 2, and 3, a cryptographic module is not required to employ environmental failure protection (EFP) features nor undergo environmental failure testing (EFT). At Security Level 4, a cryptographic module shall either employ environmental failure protection (EFP) features or undergo environmental failure testing (EFT).
4.5.4.1 Environmental Failure Protection Features (Alternative 1)
Environmental failure protection (EFP) features shall be designed to protect a cryptographic module against unusual environmental conditions or fluctuations (accidental or induced) outside of the module's normal operating range that can compromise the security of the module. In particular, the module shall monitor and correctly respond to fluctuations in the operating temperature and voltage outside of a module's specified normal operating ranges.
The protection features shall involve additional electronic circuitry or devices that shall continuously measure these environmental conditions. If a condition is determined to be outside of the module's normal operating range, the protection circuitry shall either (1) shutdown the module to prevent it from operating outside the normal range, or (2) immediately zeroize all plaintext cryptographic keys and other unprotected critical security parameters. Documentation shall provide a complete specification and description of the environmental failure protection features employed within a module.
4.5.4.2 Environmental Failure Testing Procedures (Alternative 2)
Environmental failure testing shall involve a combination of analysis, simulation, and testing of a cryptographic module in order to give a reasonable guarantee that environmental conditions or fluctuations (accidental or induced) outside the module's normal operating range will not result in the compromise of the security of the module. The manufacturer of a module shall perform the required testing and shall provide documentation that completely specifies the nature of the environmental failure tests performed and the results of those tests.
In particular, environmental failure testing shall show that varying the operating temperature and voltage outside of a cryptographic module's specified normal operating ranges does not cause electronic devices or circuitry within the module to fail in a manner that can compromise the security of the module. The temperature range to be tested shall be from -100 to +200 degrees Celsius. The voltage range to be tested shall be from the smallest negative voltage (with respect to ground) which causes the destruction of the electronic devices or circuitry, to the smallest positive voltage (with respect to ground) which causes the destruction of the electronic devices or circuitry, including reversing the polarity of the voltages. The module shall be subjected to excursions outside its specified normal operating range while being operated in a normal manner. The electronic devices or circuitry may fail at any point outside the normal operating ranges, but at no time shall the security of the module be compromised. If at any time during the test, the security of the module is compromised due to the failure of electronic circuitry or devices, then the design of the electronic circuitry or devices shall be corrected and the module shall be retested.
4.6 Software Security
The following software security requirements shall apply to all software and firmware contained within a cryptographic module. These requirements do not apply to microcode or system software whose source code is not available to the module manufacturer. These requirements do not apply to any software or firmware that can be shown not to affect the security of the module. Documentation shall identify any software or firmware that is excluded from the software security requirements and explain the rationale for the exclusion.
SECURITY LEVELS 1 AND 2
The following requirements shall apply for Security Levels 1 and 2.
In addition to the applicable requirements for Security Levels 1 and 2, the following requirement shall apply for Security Level 3.
In addition to the applicable requirements for Security Levels 1, 2 and 3, the following requirements shall apply for Security Level 4.
The operating system requirements in this section shall apply to a cryptographic module only if the module provides a means whereby an operator can load and execute software or firmware that was not included as part of the validation of the module.
An example of a cryptographic module for which the operating system requirements apply is a cryptographic module which is a general purpose computer running cryptographic software as well as untrusted user-supplied software (e.g., a spreadsheet or word processing program). In this case, the hardware, operating system and cryptographic software are considered part of the cryptographic module, and hence, the operating system requirements apply.
SECURITY LEVEL 1
For Security Level 1, the following requirements apply. Note that as a consequence of these requirements, multi-user, multi-processing operating systems are explicitly excluded from Security Level 1, and hence, must satisfy the requirements for Security Levels 2, 3 or 4.
In addition to the applicable requirements for Security Level 1, the following requirements shall also apply for Security Level 2.
In addition to the applicable requirements for Security Levels 1 and 2, the following requirements shall also apply for Security Level 3.
In addition to the applicable requirements for Security Levels 1, 2 and 3, the following requirements shall also apply for Security Level 4.
Cryptographic key management is concerned with the entire life cycle of the cryptographic keys employed with a cryptographic-based security system, including their generation, distribution, entry and use, storage, destruction and archiving. Cryptography may play an important role in key management. A cryptographic module will not only have its own key management requirements, but may also be utilized as part of the key management process for another cryptographic module or cryptographic-based security system.
Key management is required for all cryptographic modules, whether the module implements a secret key (symmetric) algorithm or a public key (asymmetric) algorithm. Secret keys and private keys shall be protected from unauthorized disclosure, modification and substitution. Public keys shall be protected against unauthorized modification and substitution.
4.8.1 Key Generation
A cryptographic module may optionally implement an internal key generation function. The module shall implement a FIPS approved key generation algorithm. Documentation shall specify the FIPS approved key generation algorithm that is implemented by the module.
When a random number generator is used in the key generation process, all values shall be generated randomly or pseudo-randomly such that all possible combinations of bits and all possible values are equally likely to be generated. A seed key, if used, shall be entered in the same manner as cryptographic keys (see Section 4.8.3). Intermediate key generation states and values shall not be accessible outside of the module in plaintext or otherwise unprotected form.
Key distribution may be performed by manual methods, automated methods, or a combination of automated and manual methods. A cryptographic module shall implement FIPS approved key distribution techniques (e.g. FIPS 171 - Key Management Using ANSI X9.17). Until such time as a FIPS approved public key-based key distribution technique is established, commercially available public key methods may be used. Documentation shall specify the key distribution techniques that are implemented by the module.
4.8.3 Key Entry and Output
Manually-distributed cryptographic keys may be entered into or output from a cryptographic module either by purely manual methods (e.g., via a keyboard, rotary switches, thumbwheels, or LCD displays) or by electronic methods (e.g., via memory cards/tokens such as magnetic-striped cards and integrated circuit (IC) chip devices, smart cards/tokens, or other electronic key loaders).
Manually-entered cryptographic keys (keys entered using manual methods) shall be verified during entry into a cryptographic module for accuracy using the manual key entry test specified in Section 4.11.2. During key entry, keys and key components may be temporarily displayed to allow visual verification and to improve accuracy. When encrypted keys or key components are entered, the resulting plaintext secret or private keys shall not be displayed.
A means shall be provided to ensure that a key entered into or output from a module is associated with the correct entities (i.e., person, group, or process) to which the key is assigned.
SECURITY LEVELS 1 AND 2
For Security Levels 1 and 2, when manually-distributed secret keys or private keys are entered into or output from a cryptographic module they may be entered or output as plaintext keys. Optionally, the keys may be entered or output either (1) in encrypted form, or (2) under split knowledge procedures (i.e., as two or more plaintext key components), as required below for Security Levels 3 and 4. Electronically distributed secret and private keys shall be entered and output in encrypted form.
SECURITY LEVELS 3 AND 4
For Security Levels 3 and 4, manually-distributed secret and private keys shall not be entered into or output from a cryptographic module in plaintext form. When manually-distributed secret or private keys are entered into or output from a cryptographic module, they shall be entered or output either (1) in encrypted form, or (2) using split knowledge procedures (i.e., as two or more plaintext key components). When a secret key or private key is entered or output under split knowledge procedures, the module shall provide the capability to separately authenticate the operator for each key component. Furthermore, the key components shall be entered directly into the cryptographic module or output directly from the cryptographic module (e.g., via a trusted path or directly attached cable), without traveling through any enclosing or intervening systems where the components could be stored, combined, or otherwise processed. Electronically distributed secret and private keys shall be entered and output in encrypted form.
4.8.4 Key Storage
When contained within a cryptographic module, secret and private keys may be stored in plaintext form. These plaintext keys shall not be accessible from outside the module.
A means shall be provided to ensure that all keys are associated with the correct entities (i.e., person, group, or process) to which the keys are assigned.
4.8.5 Key Destruction
A cryptographic module shall provide the capability to zeroize all plaintext cryptographic keys and other unprotected critical security parameters within the module. Zeroization of cryptographic keys and other critical security parameters is not required if the keys and parameters are either encrypted or otherwise physically or logically protected (e.g., contained within an additional embedded FIPS 140-1 cryptographic module).
4.8.6 Key Archiving
A cryptographic module optionally may output keys for archiving purposes. Keys output for archiving shall be encrypted.
4.9 Cryptographic Algorithms
Cryptographic modules shall employ FIPS approved cryptographic algorithms.
4.10 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC)
Radios shall meet all applicable FCC requirements. All other modules shall meet the following requirements. TEMPEST protection is not required by, and is beyond the scope of, this standard.
SECURITY LEVELS 1 AND 2
For Security Levels 1 and 2, a cryptographic module shall, at a minimum, conform to the EMI/EMC requirements specified by FCC Part 15, Subpart J, Class A (i.e., for business use).
SECURITY LEVELS 3 AND 4
For Security Levels 3 and 4, a cryptographic module shall, at a minimum, conform to the EMI/EMC requirements specified by FCC Part 15, Subpart J, Class B (i.e., for home use).
4.11 Self-Tests
A cryptographic module shall be able to perform self-tests in order to ensure that the module is functioning properly. Certain self-tests shall be performed when the module is powered up (i.e., Power- Up Tests). Other self-tests shall be performed under various conditions, typically when a particular function or operation is performed (i.e., Conditional Tests). A module may optionally perform other self-tests in addition to the tests specified in this standard.
Whenever a cryptographic module fails a self-test, the module shall enter an error state and output an error indicator via the status interface. The module shall not perform any cryptographic operations while in the error state and no data shall be output via the data output interface while the error condition exists. Each possible error condition shall be documented along with the conditions and actions necessary to clear the error and resume normal operation (possibly to including maintenance, servicing or repair of the module).
4.11.1 Power-Up Tests
After a cryptographic module is powered up, the module shall enter the self-test state and perform all of the following tests. The tests shall not require operator intervention in order to run. If all of the tests are passed successfully, such an indication shall be output via the "status output" interface. All data output via the output interface shall be inhibited when these tests are performed. The module shall provide a means to initiate the tests on demand for periodic testing of the module.
The Monobit Test
Length of Run Required Interval 1 2,267-2,733 2 1,079-1,421 3 502-748 4 223-402 5 90-223 6+ 90-223
The following tests shall be performed under the conditions specified for each test:
This appendix is provided for informational purposes only, and is not a part of this standard.
The following check list summarizes the documentation requirements of this standard. The FIPS 140-1 validation procedures may require additional documentation. All documentation shall be provided to the validation facility by the manufacturer of a cryptographic module. Requirements for user documentation are beyond the scope of this standard, however, copies of the user and installation manuals shall also be pro vided to the validation facility.
CRYPTOGRAPHIC MODULES
This appendix is provided for informational purposes only, and is not a part of this standard.
The following programming techniques should be used to facilitate analysis of the program, and to reduce the chances of programming errors. Deviations from these practices may be appropriate in some instances.
The following additional programming practices should be used when the implementation is in assembly language. Deviations from these practices may be appropriate in some instances.
FIPS PUB 140-1
FEDERAL INFORMATION
PROCESSING STANDARDS PUBLICATION
1994 JANUARY 11
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology