`
`
`
`
`
`
`
`
`
`
`
`ARCHIVED PUBLICATION
`
`
`
`The attached publication,
`
`FIPS Publication 140-1
`(dated January 11, 1994),
`
`has been superseded and is provided here only for
`historical purposes.
`
`
`
`For the most current revision of this publication, see:
`http://csrc.nist.gov/publications/PubsFIPS.html#140-2.
`
`
`
`IBM-1015
`Page 1 of 56
`
`

`

`FIPS PUB 140-1
`
`FEDERAL INFORMATION
`PROCESSING STANDARDS PUBLICATION
`
`1994 January 11
`
`U.S. DEPARTMENT OF COMMERCE / National Institute of Standards and Technology
`
`SECURITY REQUIREMENTS
`FOR
`CRYPTOGRAPHIC MODULES
`
` CATEGORY: COMPUTER SECURITY
` SUBCATEGORY: CRYPTOGRAPHY
`
`IBM-1015
`Page 2 of 56
`
`

`

`U.S. DEPARTMENT OF COMMERCE, Ronald H. Brown, Secretary
`NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY,
`
`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 111(d) of the Federal Property and
`Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-
`235. These mandates have given the Secretary of Commerce and NIST important responsibilities for
`improving the utilization and management of computer and related telecommunications systems in the
`Federal Government. The NIST, through its Computer Systems Laboratory, provides leadership, technical
`guidance, and coordination of Government efforts in the development of standards and guidelines in these
`areas.
`
`Comments concerning Federal Information Processing Standards Publications are welcomed and
`should be addressed to the Director, Computer Systems Laboratory, National Institute of Standards and
`Technology, Gaithersburg, MD 20899.
`
`James H. Burrows, Director
`Computer Systems Laboratory
`
`Abstract
`
`The selective application of technological and related procedural safeguards is an important
`responsibility of every Federal organization in providing adequate security in its computer and
`telecommunication systems. This publication provides a standard to be used by Federal organizations
`when these organizations specify that cryptographic-based security systems are to be used to provide
`protection for sensitive or valuable data. Protection of a cryptographic module within a security system
`is necessary to maintain the confidentiality and integrity of the information protected by the module. This
`standard specifies the security requirements that are to be satisfied by a cryptographic module. The
`standard provides four increasing, qualitative levels of security intended to cover a wide range of potential
`applications and environments. The security requirements cover areas related to the secure design and
`implementation of a cryptographic module. These areas include 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.
`
`Key words: computer security, telecommunication security, cryptography, cryptographic modules, Federal
`Information Processing Standard (FIPS).
`
`IBM-1015
`Page 3 of 56
`
`

`

`FIPS PUB 140-1
`
`Federal Information
`Processing Standards Publication 140-1
`
`1994 January 11
`
`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 111(d) of the Federal Property and
`Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235.
`
`1.
`
`2.
`
`Name of Standard. Security Requirements for Cryptographic Modules (FIPS PUB 140-1).
`
`Category of Standard. Computer Security Standard, Cryptography
`
`Explanation. This standard specifies the security requirements that are to be satisfied by a
`3.
`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.
`
`Maintenance Agency. Department of Commerce, National Institute of Standards and
`5.
`Technology, (Computer Systems Laboratory).
`
`6.
`
`Cross Index.
`
`a.
`b.
`
`c.
`
`d.
`
`FIPS PUB 46-2, Data Encryption Standard.
`FIPS PUB 48, Guidelines on Evaluation of Techniques for Automated Personal
`Identification.
`FIPS PUB 74, Guidelines for Implementing and Using the NBS Data Encryption
`Standard.
`FIPS PUB 81, DES Modes of Operation.
`
`1
`
`IBM-1015
`Page 4 of 56
`
`

`

`FIPS PUB 140-1
`
`e.
`
`f.
`g.
`h.
`i.
`j.
`
`k.
`l.
`
`FIPS PUB 83, Guideline of User Authentication Techniques for Computer Network
`Access Control.
`FIPS PUB 112, Password Usage.
`FIPS PUB 113, Computer Data Authentication.
`FIPS PUB 171, Key Management Using ANSI X9.17.
`FIPS PUB 180, Secure Hash Standard.
`Special Publication 500-157, Smart Card Technology: New Methods for Computer
`Access Control.
`Special Publication 800-2, Public Key Cryptography.
`Federal Information Resources Management Regulations (FIRMR) subpart 201.20.303,
`Standards, and subpart 201.39.1002, Federal Standards.
`
`Other NIST publications may be applicable to the implementation and use of this standard. A list (NIST
`Publications List 91) of currently available computer security publications, including ordering
`information, can be obtained from NIST.
`
`Applicability. This standard is applicable to all Federal agencies that use cryptographic-based
`7.
`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.
`
`Applications. Cryptographic-based security systems may be utilized in various computer and
`8.
`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.
`
`Specifications. Federal Information Processing Standard (FIPS) 140-1, Security Requirements
`9.
`for Cryptographic Modules (affixed).
`
`2
`
`IBM-1015
`Page 5 of 56
`
`

`

`FIPS PUB 140-1
`
`Implementations. This standard covers implementations of cryptographic modules including,
`10.
`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.
`
`FIPS Approved Security Methods. Cryptographic modules that comply with this standard shall
`11.
`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:
`
`a.
`
`b.
`
`specified in a Federal Information Processing Standard (FIPS), or
`
`adopted in a FIPS and specified either in an appendix to the FIPS or in a document
`referenced by the FIPS.
`
`If a cryptographic module is required to incorporate a trusted operating system, then the module shall
`employ trusted operating systems that have been evaluated by a NIST accredited evaluation authority
`and against a FIPS approved evaluation criteria.
`
`Information about approved cryptographic methods and approved operating system evaluation authorities
`and criteria can be obtained from NIST.
`
`Interpretation. Resolution of questions regarding this standard will be provided by NIST.
`12.
`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.
`
`Export Control. Certain cryptographic devices and technical data regarding them are deemed
`13.
`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.
`
`3
`
`IBM-1015
`Page 6 of 56
`
`

`

`FIPS PUB 140-1
`
`Implementation Schedule. Table 1 summarizes the implementation schedule for FIPS 140-1.
`14.
`The effective date of this standard is June 30, 1994.
`
`From approval of FIPS 140-1 to its effective date, agencies may purchase equipment with FIPS 140-1
`cryptographic modules that have been affirmed in writing from the manufacturer as complying with this
`standard. From June 30, 1994 until six months after the establishment of the FIPS 140-1 validation
`program by NIST, agencies that have determined a need for equipment with cryptographic modules shall
`purchase equipment with FIPS 140-1 cryptographic modules that have been affirmed in writing by the
`manufacturer as complying with this standard. A copy of the written affirmation shall have been sent
`to the Director, Computer Systems Laboratory, National Institute of Standards and Technology,
`Gaithersburg, MD 20899.
`
`Table 1: FIPS 140-1 Implementation Schedule
`
`4
`
`IBM-1015
`Page 7 of 56
`
`

`

`FIPS PUB 140-1
`
`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.
`
`Table 2: FIPS 140 Schedule for Acquisition of Validated Products
`
`5
`
`IBM-1015
`Page 8 of 56
`
`

`

`FIPS PUB 140-1
`
`Qualifications. The security requirements specified in this standard are based upon information
`15.
`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:
`
`a.
`
`b.
`
`Compliance with a standard would adversely affect the accomplishment of the mission
`of an operator of a Federal computer system, or
`
`cause a major adverse financial impact on the operator which is not offset by
`Government-wide savings.
`
`Agency heads may act upon a written waiver request containing the information detailed above. Agency
`heads may also act without a written waiver request when they determine that conditions for meeting
`the standard cannot be met. Agency heads may approve waivers only by a written decision which
`explains the basis on which the agency head made the required finding(s). A copy of each such
`decision, with procurement sensitive or classified portions clearly identified, shall be sent to: National
`Institute of Standards and Technology; ATTN: FIPS Waiver Decisions, Technology Building, Room B-
`154; Gaithersburg, MD 20899.
`
`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
`
`6
`
`IBM-1015
`Page 9 of 56
`
`

`

`FIPS PUB 140-1
`
`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.
`
`7
`
`IBM-1015
`Page 10 of 56
`
`

`

`1
`
`2
`
`3
`
`4
`
`FIPS PUB 140-1
`
`Federal Information
`Processing Standards Publication 140-1
`
`January 11, 1994
`
`Specifications for the
`
`SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
`
`OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
`1.1
`Security Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
`1.2
`Security Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
`1.3
`Security Level 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
`1.4
`Security Level 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
`
`DEFINITIONS AND ACRONYMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`2.1
`Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`2.2
`Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
`
`FUNCTIONAL SECURITY OBJECTIVES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
`
`4.4
`4.5
`
`SECURITY REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
`4.1
`Cryptographic Modules
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
`4.2
`Module Interfaces
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
`4.3
`Roles and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
`4.3.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
`4.3.2
`Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
`4.3.3 Operator Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
`Finite State Machine Model
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
`Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
`4.5.1
`Single-Chip Cryptographic Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 29
`4.5.2 Multiple-Chip Embedded Cryptographic Modules . . . . . . . . . . . . . . . . . 30
`4.5.3 Multiple-Chip Standalone Cryptographic Modules
`. . . . . . . . . . . . . . . . 32
`4.5.4 Environmental Failure Protection/Testing . . . . . . . . . . . . . . . . . . . . . . . 34
`4.5.4.1 Environmental Failure Protection Features
`. . . . . . . . . . . . . . . . 34
`4.5.4.2 Environmental Failure Testing Procedures
`. . . . . . . . . . . . . . . . 35
`Software Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
`Operating System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
`Cryptographic Key Management
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
`4.8.1 Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
`4.8.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
`4.8.3 Key Entry and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
`4.8.4 Key Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
`
`4.6
`4.7
`4.8
`
`8
`
`IBM-1015
`Page 11 of 56
`
`

`

`FIPS PUB 140-1
`
`4.9
`4.10
`4.11
`
`4.8.5 Key Destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
`4.8.6 Key Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
`Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
`Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) . . . . . . 42
`Self-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
`4.11.1 Power-Up Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
`4.11.2 Conditional Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
`
`APPENDIX A: SUMMARY OF DOCUMENTATION REQUIREMENTS . . . . . . . . . . . . . . . 47
`
`APPENDIX B: RECOMMENDED SOFTWARE DEVELOPMENT PRACTICES . . . . . . . . . . 50
`
`APPENDIX C: SELECTED REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
`
`9
`
`IBM-1015
`Page 12 of 56
`
`

`

`FIPS PUB 140-1
`
`1
`
`OVERVIEW
`
`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.
`
`10
`
`IBM-1015
`Page 13 of 56
`
`

`

`FIPS PUB 140-1
`
`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.
`
`11
`
`IBM-1015
`Page 14 of 56
`
`

`

`FIPS PUB 140-1
`
`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 mo