PART 1
(Sections 1-4)

Part 2 (sections 5-7)

Part 3 (sections 8-11)

Appendix A

INTRODUCTION

1. Cryptographic Module Design and Documentation
2. Module Interfaces
3. Roles and Services
4. Finite State Machine Model
5. Physical Security
6. Software Security
7. Operating System Security
8. Cryptographic Key Management
9. Cryptographic Algorithms
10. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC)
11. Self Tests
12. Appendix A: A Cryptographic Module Security Policy

The National Institute of Standards and Technology (NIST) intends to establish a FIPS 140-1 validation program using the National Laboratory Accreditation Program (NVLAP) to accredit laboratories to perform testing of cryptographic modules for conformance to FIPS 140-1. Under the proposed process, NIST would issue validation certificates based on test reports produced by NVLAP-accredited laboratories. Organizations wishing to have validations performed would contract with the laboratories for the required services.

Purpose

 This document also details the requirements for vendor information that must be provided as supplementary evidence to demonstrate conformance to FIPS 140-1 requirements. This document may be used by vendors as a guide in trying to determine if their cryptographic modules meet the security requirements of FIPS 140-1 before they apply to the laboratory for testing.

Document Organization

 Within each section, the corresponding security requirements from FIPS 140-1 are divided into a set of assertions (i.e., statements that must be true for the module to satisfy the requirement of a given area at a given level). All of the assertions are either direct quotations from FIPS 140-1, or are directly derivable from these requirements. The assertions are denoted by the form

where "requirement_number" is the number of the corresponding area specified in FIPS 140-1 (i.e., one through eleven), and "sequence_number" is a sequential identifier for assertions within a section. After the statement of each assertion, the security levels to which the assertion applies (i.e., Levels 1 through 4) are listed in parentheses.

*  In the HTML version of the DTR, after each assertion there is a reference to any relevant implementation guidance, from the FIPS 140-1 Implementation Guidance document [PDF 12-04-2001].

 Following each assertion are a set of requirements levied on the vendor. These requirements describe the types of documentation or explicit information that the vendor must provide in order for the tester to determine conformance to the given assertion. These requirements are denoted by the form

where "requirement_number" and "assertion_sequence_number" are identical to the corresponding assertion requirement number and sequence number, and "sequence_number" is a sequential identifier for vendor requirements within the assertion requirement.

 Also following each assertion and the requirements levied on the vendor are a set of requirements levied on the tester of the cryptographic module. These requirements instruct the tester as to what he or she must do in order to test the cryptographic module with respect to the given assertion. These requirements are denoted by the form

where "requirement_number" and "assertion_sequence_number" are identical to the corresponding assertion requirement number and sequence number, and "sequence_number" is a sequential identifier for tester requirements within the assertion requirement.

1. CRYPTOGRAPHIC MODULES

(Relevant Implementation Guidance:  1.1 , 1.2 )
 

Required Vendor Information

• VE01.01.01: All components that implement cryptographic logic or processes shall be identified in the vendor documentation. Components to be listed shall include, as applicable, all of the following:

 

1. Integrated circuits, including processors, memory, and (semi-) custom integrated circuits
2. Other active electronic circuit elements
3. Power inputs and outputs, and internal power supplies or converters
4. Physical structures, including circuit boards or other mounting surfaces, enclosures, and connectors
5. Software and firmware modules
6. Other component types used in the module
• VE01.01.02: The above list of components shall be consistent with the information provided for all other assertions of this section.

 

Required Test Procedures

• TE01.01.01: The tester shall verify that the documentation includes a master components list that is stated to include all hardware, software, and firmware components of the cryptographic module.

 

• TE01.01.02: The tester shall verify that the master components list includes all occurrences of the following types of components when applicable, excluding only component types that are not used in the module:

 

1. Processors, including microprocessors, digital signal processors, custom processors, microcontrollers, or any other types of processors
2. Read-only memory (ROM) integrated circuits for program executable code and data (this may include mask-programmed ROM, programmable ROM (PROM) such as ultraviolet, erasable PROM [EPROM] or electrically erasable PROM [EEPROM])
3. Random-access memory (RAM) integrated circuits for temporary data storage
4. Semi-custom, application-specific integrated circuits, such as gate arrays, programmable logic arrays, or other programmable logic devices
5. Fully custom, application-specific, integrated circuits, including any custom cryptographic integrated circuits
6. Other active electronic circuit elements (the vendor does not have to list passive circuit elements such as pull up/pull down resistors or bypass capacitors if they do not play a significant role in the security of the cryptographic module and are not at the cryptographic boundary)
7. Power supply components, including power supply, voltage conversion modules (e.g., AC-to-DC or DC-to-DC modules), transformers, input power connectors, and output power connectors
8. Circuit boards or other component mounting surfaces
9. Enclosures, including any removable access doors or covers
10. Physical connectors for devices outside the cryptographic module, or between any major independent submodules of the cryptographic module
11. Software modules, defined as executable code or data that could be changed in the future or is readily accessible to programmers
12. Firmware modules, defined as executable code or data that is unlikely to be changed (e.g., because it performs a standardized fixed function) and is not readily accessible to programmers
13. Other component types used in the module
• TE01.01.03: The tester shall verify that the master components list is consistent with information provided for other assertions of this section, as defined below:

 

1. The specification of the cryptographic boundary under assertion AS01.02: Verify that all components inside the cryptographic boundary are included in the master components list, and that any components outside the cryptographic boundary are not listed as components of the cryptographic module.
2. The specification of the processors and software/firmware under assertion AS01.03: Verify that the list of processors, software modules, and hardware modules in the master components list is the same as in the specifications under Assertion AS01.03.
3. The specification of the physical configuration under assertion AS01.04: Verify that the list of physical structures in the master components list (such as circuit boards or other mounting surfaces, enclosures, and connectors) is the same as in the specifications under Assertion AS01.04.
4. The specification of the block diagram under assertion AS01.05: Verify that any individual components called out in the block diagram (e.g., processors, application-specific integrated circuits, and large memory units) are also listed in the master components list.
5. Any components which are to be excluded from the requirements of FIPS PUB 140-1 under the provisions of assertion AS01.06: Verify that components to be so excluded are still listed in the master components list.

AS01.02: Documentation shall completely specify the module's cryptographic boundary surrounding the components. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  1.3 ,1.4  )

Required Vendor Information

• VE01.02.01: The vendor documentation shall specify the module's cryptographic boundary. The cryptographic boundary shall be an explicitly defined, contiguous perimeter that establishes the physical bounds of the cryptographic module. The perimeter definition shall define module components and connections (ports), and also module information flows, processing, and input/output signals.

 

• VE01.02.02: The cryptographic boundary shall include any hardware or software that inputs, processes, or outputs important security parameters that could lead to the compromise of sensitive information if not properly controlled.

 

Required Test Procedures

• TE01.02.01: The tester shall verify that the documentation explicitly shows where the cryptographic boundary physical perimeter lies. This can be supplied via a listing of all significant components inside the cryptographic boundary plus all ports connected to equipment outside the cryptographic boundary. The documentation must also supply a listing of all significant information flows and processing to be performed inside the cryptographic boundary plus all information signals that are input and output to the exterior of the cryptographic boundary. Alternatively, a detailed functional block diagram showing the cryptographic boundary may be used to meet some or all of the above requirements for perimeter definition, as long as there is sufficient detail to provide the information required above. (Annotations on component lists or block diagrams provided for other purposes may also be used, if the cryptographic boundary is clearly identified.)

 

• TE01.02.02: The tester shall verify that the vendor-provided documentation includes sufficient detail for components at the cryptographic boundary to precisely define the cryptographic boundary.

 

• TE01.02.03: The tester shall verify that the cryptographic boundary is physically contiguous. This means that there must be no gaps that could allow uncontrolled input, output, or other access into the cryptographic module. (Physical protection and tamper protection are covered separately in requirements under section 4.5 of FIPS PUB 140-1.) The module design must also ensure that there are no uncontrolled interfaces into or out of the cryptographic module that could pass sensitive information.

 

• TE01.02.04: The tester shall verify that the cryptographic boundary encompasses all components that are identified in the block diagram under assertion AS01.05 in this section as inputting, outputting, or processing plaintext, keys, authorization data, or other information that if misused or malfunctioned could lead to a compromise.

 

• TE01.02.05: As a partial exception to the above requirements, the vendor is allowed to exclude certain components from the requirements of FIPS PUB 140-1 after satisfying the requirements under assertion AS01.06 in this section. The vendor may then treat such excluded components as effectively outside the cryptographic boundary of the module, in the sense that they will not be further analyzed. In that case, the tester shall verify that any interfaces or physical connections between such excluded components and the rest of the module cannot allow uncontrolled release of sensitive information outside the module.

 

AS01.03: If the cryptographic module contains software or firmware, the cryptographic boundary shall be defined such that it contains any processor which executes the code. (1, 2, 3, and 4)

Required Vendor Information

• VE01.03.01: For each processor in the module, the vendor shall identify, by major function, the software or firmware that are executed by the processor, and the memory devices that contain the executable code and data.

 

• VE01.03.02: For each processor, the vendor shall identify any hardware with which it interfaces.

 

Required Test Procedures

• TE01.03.01: The tester shall verify that each processor identified under this assertion is contained in the master components list under assertion AS01.01 and in the cryptographic boundary defined under assertion AS01.02.

 

• TE01.03.02: The tester shall verify that, for each processor, the vendor has identified the software or firmware code modules executed by that processor, the functions performed by that processor and its code, and the memory devices containing the executable code and data.

 

• TE01.03.03: The tester shall verify that, for each processor, the vendor has identified any hardware with which it interfaces. This must include, as applicable, any hardware components that provide input data, control, or status signals to the processor and its software/firmware, and any hardware components that receive output data, control, or status signals from the processor and its software/firmware. Such hardware components may be within the cryptographic module, or may be user equipment outside the module such as input/output devices.

 

AS01.04: Documentation shall completely describe the physical configuration of the module. (1, 2, 3, and 4)

Required Vendor Information

• VE01.04.01: The vendor shall identify which of the three possible physical configurations the module has: single-chip module; multi-chip embedded module; or multi-chip, stand-alone module as defined in Section 4.5 of FIPS PUB 140-1.

 

• VE01.04.02: The vendor's documentation shall indicate the internal layout and assembly methods (e.g., fasteners and fittings) of the module, including drawings that are at least approximately to scale. The interior of integrated circuits need not be shown.

 

• VE01.04.03: The vendor's documentation shall describe the primary physical parameters of the module, including descriptions of the enclosure, access points, circuit boards, location of power supply, interconnection wiring runs, cooling arrangements, and any other significant parameters.

 

Required Test Procedures

• TE01.04.01: The tester shall verify that the vendor identified that the cryptographic module is either a single-chip module, a multi-chip embedded module, or a multi-chip standalone module as defined in Section 4.5 of FIPS PUB 140-1.

 

• TE01.04.02: The tester shall verify that the vendor's documentation shows the internal layout of the module, including the placement and approximate dimensions of major identifiable components of the module. This must include drawings that are at least approximately to scale. (These need not be blueprints. The vendor can use his own internal format if desired and if the information is detailed and accurate enough to meet the requirements of this section.)

 

• TE01.04.03: The tester shall verify that the vendor's documentation indicates the major physical assemblies of the module and how they are assembled or inserted into the module.

 

• TE01.04.04: The tester shall verify that the vendor's documentation describes the primary physical parameters of the module. This must include at least the following:

 

1. Enclosure shape and approximate dimensions, including any access doors or covers
2. Circuit board(s) approximate dimensions, layout, and interconnections
3. Location of power supply, power converters, and power inputs and outputs
4. Interconnection wiring runs: routing and terminals
5. Cooling arrangements, such as conduction plates, cooling air flow, heat exchanger, cooling fins, fans, or other arrangements for removing heat from the module

AS01.05: Documentation shall include a block diagram depicting all of the major hardware components of the module and their interconnections. (1, 2, 3, and 4)

Required Vendor Information

• VE01.05.01: The vendor documentation shall include a functional block diagram showing the hardware components and their interconnections. Components to be included in the block diagram shall include, as applicable:

 

1. Microprocessors
2. Input/output buffers
3. Plaintext/ciphertext buffers
4. Control buffers
5. Key storage
6. Working memory
7. Program memory
8. Any other significant components used
   
   
• VE01.05.02: The block diagram shall also include any (semi-) custom integrated circuits, such as predesigned cryptographic circuitry, gate arrays, or other programmable logic. Independent functions within such components shall be identified separately in the block diagram.

 

• VE01.05.03: The block diagram shall include the functions of major module components or subassemblies.

 

• VE01.05.04: The block diagram shall show interconnections among major components of the module and between the module and outside equipment.

 

• VE01.05.05: The block diagram shall show the cryptographic boundary of the module.

 

Required Test Procedures

• TE01.05.01: The tester shall verify that the vendor has provided one or more block diagrams indicating major submodules of the cryptographic module. These shall include at least the following, as applicable to the vendor's design:

 

1. Microprocessors or any other processors listed in the master components list under assertion AS01.01 in this section
2. Input/output buffer memory that stores or processes general input or output data other than plaintext/ciphertext message data or control information
3. Plaintext/ciphertext buffer memory that stores or processes message data to be encrypted or decrypted
4. Control buffer memory that stores or processes control and status information that is input into the module or output from the module
5. Key storage for cryptovariables
6. Working memory for processing information
7. Program memory containing executable software or firmware code
8. (Semi-) custom integrated circuits such as predesigned cryptographic circuitry, application-specific integrated circuits, gate arrays, programmable logic arrays, or other programmable logic devices. (These must be specified to the level of independent functions. If more than one function is performed by a given module, the functions shall be shown separately in the block diagram.)
9. Any other significant components used
• TE01.05.02: The tester shall verify that the block diagram indicates the major functions performed by the components or subassemblies that are blocks in the diagram. These must include at least plaintext and ciphertext message processing and routing, cryptologic (algorithms and other cryptographic processing), memory buffering and storage, control logic, key handling, zeroization, alarms and protection, and power.

 

• TE01.05.03: The tester shall verify that the block diagram indicates all significant interconnections and data flow among major components of the module, and between the module and outside equipment. In particular, each line on the block diagram indicating an interconnection must be labeled with the type of information it transmits.

 

• TE01.05.04: The tester shall verify that the block diagram indicates the cryptographic boundary for the cryptographic module, as required under assertion AS01.02 in this section.

 

AS01.06: Documentation shall indicate any hardware, software, or firmware components of the module that are excluded from the security requirements of the standard and explain why these parts do not effect the security of the module. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  1.4 , )

Required Vendor Information

• VE01.06.01: All components that are to be excluded from the security requirements shall be explicitly listed in the vendor documentation.

 

• VE01.06.02: The rationale for excluding each of the components listed in response to requirement VE01.06.01 shall be provided in the vendor documentation. The vendor shall show that each such component, even if malfunctioning or misused, cannot cause a compromise under any reasonable conditions.

 

Required Test Procedures

• TE01.06.01: The tester shall determine whether the vendor indicates that any components of the module are to be excluded from the requirements of FIPS PUB 140-1. If none are so listed, all components must meet the other requirements of this and all other sections.

 

• TE01.06.02: If the vendor has indicated that certain components of the module are to be excluded from the requirements of FIPS PUB 140-1, the tester shall determine that a rationale for the exclusion is provided. The rationale must show that even if the component is misused or malfunctions, it could not cause a compromise via potential release of sensitive information. Some reasons that might be acceptable, if adequately supported by backup information and discussion, include:

 

1. The component does not process sensitive information and is not connected with sensitive areas of the rest of the module in any way that would allow inappropriate transfer of sensitive information (e.g., structural components or filter power circuitry)
2. All information processed by the component is strictly for internal use of the module, and does not in any way impact the equipment to which the module is connected (e.g., internal housekeeping timing circuits that are reclocked before use by components that do contact outside equipment such as input/output devices)
3. The component's inputs or outputs are compared against similar redundant information elsewhere in the module that would detect and protect against any malfunction which could otherwise have released sensitive information
The tester shall determine the correctness of any rationale for exclusion such as the above. The burden of proof is on the vendor; if there is any uncertainty or ambiguity, the tester shall require the vendor to produce additional information as needed.

 

AS01.07: Documentation shall 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. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  1.5 , 4.1 )

Required Vendor Information

• VE01.07.01: The vendor shall provide a separate document, or section of a document, that specifies the security policy (i.e., the security rules under which a module must operate) enforced by the cryptographic module.

 

Required Test Procedures

• TE01.07.01: The tester shall review the security policy specification provided by the vendor. Specifically, he or she must determine that it identifies all roles, services, and security relevant data items of the cryptographic module, and specifies what access, if any, a user, performing a service within the context of a given role, has to each of the security relevant data items. The specification should be complete, and detailed enough to be able to answer the following question: "What access does operator X, performing service Y while in role Z have to security relevant data item K?" for every role, service, and security relevant data item contained in the cryptographic module.

 

• General: The vendor is encouraged to include, or reference by page number or figure in documentation, any useful supporting information. This could include data sheets, user manuals, results of prior security analyses (in-house or with NSA), etc. Such supporting information would be particularly useful where it helps evaluate the module against specific tester requirements.

 

2. MODULE INTERFACES

Required Vendor Information

• VE02.01.01: The vendor documentation shall itemize the module information flows and access points by highlighting or annotating copies of the block diagram required in section 1, and providing any other documentation necessary to clearly specify the logical interfaces. For each input to the module or output from the module, the documentation shall specify the logical interface to which the input or output belongs, and the physical entry/exit point. The information provided under this requirement shall be consistent with component information provided for assertions AS01.01, AS01.02, and AS01.05 under section 1.

 

• VE02.01.02: The vendor design shall separate the module interfaces into logically isolated categories using at least the categories defined in assertion AS02.02 and (if applicable) AS02.03 in this section. If two or more interfaces share the same physical port, the vendor shall specify how the information from different interface categories is kept logically separate.

 

Required Test Procedures

• TE02.01.01: The tester shall verify that the vendor documentation includes the following information:

 

1. A listing or diagram of all logical inputs to the module and outputs from the module
2. A listing of all physical input (entry) and output (exit) ports of the module
3. A mapping from the logical inputs/outputs to the physical input/output ports of the module
4. A highlighted or annotated copy of the block diagram showing the logical input/output interfaces
The tester shall compare the above information with the information provided under assertions AS01.01, AS01.04, and AS01.05 and verify that there are no inconsistencies in the description of components and physical layout for the input/output ports. (Note that separate pins within one connector may be considered separate ports.)

 

• TE02.01.02: The tester shall verify from vendor documentation that the module interfaces are separate for the categories of interfaces specified in assertions AS02.02 and (if applicable) AS02.03 of this section. In particular, the tester shall verify that the information flows for the input, output, control, and status interfaces are not mingled by merging any of them into the same physical interface signal line at the same time. Note that a module interface may be physically distributed across more than one port, or two or more module interfaces may physically share one port as long as the information flows are kept logically separate. However, if two or more interfaces share the same physical port, the tester shall verify that the vendor describes a workable scheme for keeping separate the information flowing through the interfaces.

 

AS02.02: The module shall have at least the following four logical interfaces: (1, 2, 3, and 4)

• Data input interface
• Data output interface
• Control input interface
• Status output interface

Required Vendor Information

• VE02.02.01: The module shall have a data input interface that is defined in the vendor documentation, including:

 

1. Plaintext data
2. Ciphertext data
3. Cryptographic keys
4. Other key management data
5. Authentication data
6. Status information
7. Any other input data
• VE02.02.02: The module shall have a data output interface that is defined in the vendor documentation including:

 

1. Plaintext data
2. Ciphertext data
3. Cryptographic keys
4. Other key management data
5. Authentication data
6. Control information
7. Any other output data
• VE02.02.03: The module shall have a control input interface that is defined in the vendor documentation used to control operation of the module, including input commands, signals, data, and manual inputs.

 

• VE02.02.04: The module shall have a status output interface that is defined in the vendor documentation used to indicate or display the status of the module including output data, signals, indicators, and physical indicators.

 

Required Test Procedures

• TE02.02.01: The tester shall verify from vendor documentation that the module has a data input interface that includes any of the following to be input or processed by the module:

 

1. Plaintext data that is to be encrypted or authenticated in the module.
2. Ciphertext data that is to be decrypted in the module.
3. Cryptographic keys that are input into and used by the module.
4. Other key management data that is input into the module (depending on the module functions, this might include initialization vectors, counters, zeroization commands, split key information, or key accounting information). (Other key management requirements are covered in section 8.)
5. Authentication data that is input into the module.
6. Status information from outside the module (for example received from another module).
7. Any other information that is input into the module for processing or storage except for control information which is covered separately in VE02.02.03 and TE02.02.03 below.
8. Note that for security levels 1 and 2, the data input port or ports for cryptographic keys, authentication data, and other critical security parameters may be shared with other ports of the module. (Corresponding requirements for security levels 3 and 4 are covered separately under assertion AS02.13 in this section.)
• TE02.02.02: The tester shall verify from vendor documentation that the module has a data output interface that includes any of the following to be output by the module:

 

1. Plaintext data that has been decrypted by the module.
2. Ciphertext data that has been encrypted by the module.
3. Cryptographic keys that are generated within and output from the module.
4. Other key management data that is output from the module (depending on the module functions, this might include initialization vectors, counters, zeroization commands, split key information, or key accounting information). (Other key management requirements are covered in section 8.)
5. Authentication data that is output from the module.
6. Control information sent outside the module (for example to be sent to another module).
7. Any other information that is output from the module after processing or storage except for status information that is covered separately in VE02.02.04 and TE02.02.04 below.
Note that for security levels 1 and 2, the data output port or ports for cryptographic keys, authentication data, and other critical security parameters may be shared with other ports of the module. (Corresponding requirements for security levels 3 and 4 are covered separately under assertion AS02.13 in this section.)

 

• TE02.02.03: The tester shall verify from vendor documentation that the module has a control input interface that is used to enter information that controls the operation of the module (as opposed to input data which is processed or stored by the module as defined in VE02.02.01 and TE02.02.01 in this section), including any:

 

1. Input commands
2. Input signals
3. Input data
4. Manual inputs (such as switches, buttons, and keyboards)
• TE02.02.04: The tester shall verify from vendor documentation that the module has a status output interface that is used to output information that indicates or displays the status of the module (as opposed to data output as defined in VE02.02.02 and TE02.02.02 in this section) including any:

 

1. Output data
2. Output signals
3. Output indicators
4. Status codes
5. Physical indicators (such as lights, LEDs, buzzers, and displays)

AS02.03: The module may include the following logical interfaces: (1, 2, 3, and 4)

• Power interface
• Maintenance access interface

 

Required Vendor Information

• VE02.03.01: If the module accepts or provides external power, it shall have a power interface well defined in the vendor documentation that includes any entry or exit points for the power.

 

• VE02.03.02: If the module allows access for maintenance purposes, it shall have a maintenance access interface, well defined in the vendor documentation, that includes any of the following inputs, outputs, or accesses used to maintain, service, or repair the module:

 

1. Data
2. Control information
3. Status information
4. All physical access paths
Any data, control, or status information used to maintain, service, or repair the module shall enter and exit via the maintenance access interface.

 

Required Test Procedures

• TE02.03.01: The tester shall determine whether the module uses power from an external source or provides power to an external source. If either or both of these conditions are met, the tester shall verify from vendor documentation that the vendor documentation shows that a logically separate power interface is provided. Note that a power interface is not required when all power is provided or maintained internally to the module (e.g., battery power or solar power).

 

• TE02.03.02: The tester shall determine whether the module allows access for maintenance purposes. If so, the tester shall verify from vendor documentation that the vendor documentation shows a logically separate maintenance interface is provided. The tester shall verify that documentation on the maintenance interface, if present, includes all of the following information that is used to maintain, service, or repair the module:

 

1. Data input into the module that may include test data to fill module storage with known data or to put the module into a known state.
2. Data output from the module (for example: for checking against known correct data or for other correctness checks).
3. Control information that puts the module into specific states required for maintenance.
4. Status information that indicates the state of the module before, during, or after maintenance actions.
5. All physical access paths including removable covers and doors used to gain physical access to the contents of the module.
6. (Other requirements on the maintenance interface are covered separately under assertions AS02.05 through AS02.08 in this section. Some requirements relating to physical access are covered in section 5.)

AS02.04: All data output via the data output interface shall be inhibited whenever an error state exists and during self-tests. (1, 2, 3, and 4)

Required Vendor Information

• VE02.04.01: The vendor design shall ensure that all data output via the data output interface is inhibited whenever the module is in an error state, as documented in section 4, and the vendor documentation shall describe how this is done.

 

• VE02.04.02: The vendor design shall ensure that all data output via the data output interface is inhibited whenever the module is in a self-test condition, as documented in section 11, and the vendor documentation shall describe how this is done.

 

Required Test Procedures

• TE02.04.01: The tester shall verify that the vendor documentation shows that all data output via the data output interface is inhibited whenever the module is in any error state. In particular, the tester shall verify from vendor documentation that once an error condition is detected and the error state is entered, all data output via the data output interface must be inhibited, unless and until error recovery, if any, is complete. (Some status output may be allowed to assist in determining the type of error, as long as it is clear that no potentially sensitive information could be released.) The tester shall also verify that the error states discussed in vendor documentation in response to this requirement are identical to those documented in the finite state machine model of section 4 (requirement VE04.00).

 

• TE02.04.02: To the extent the module design and operating procedures allow, the tester shall put the module in each error state and verify that all data output via the data output interface is disallowed. (Limited status information that may be useful in determining the type of error is allowed as long as no potentially sensitive information is released.) The error state should be induced by at least the following actions, if applicable and practical: opening a tamper protected area, entering an incorrect key, reducing input voltage,and any other possible error-inducing actions.

 

• TE02.04.03: The tester shall verify that the vendor documentation shows all data output is inhibited whenever the module is in any self-test condition. The tester shall also verify that the self-test conditions discussed in vendor documentation in response to this requirement are identical to those documented in the self tests of section 11 (requirements VE11.01.01 and TE11.01.01).

 

• TE02.04.04: If the module design and operating procedures allow it, the tester shall put the module in a self-test state and verify that data output is disallowed.

 

• TE02.04.05: The tester shall verify that the vendor documentation shows how the data output is to be inhibited, to ensure that the alarm or self-test indications can logically inhibit the data output interface, and that the data output lines are, in fact, inhibited under any reasonable conditions (for example: a logical switch connected to an alarm indicator line could open an output line).

 

AS02.05: If a maintenance access interface is provided, any removable covers or doors defined as part of it shall be safeguarded using the appropriate physical security mechanisms of section 5. (1, 2, 3, and 4)

(Relevant Guidance: 3.6)

Required Vendor Information

• VE02.05.01: The vendor documentation shall specify how the design ensures that any removable covers or doors of a maintenance access interface meet the physical security requirements of section 5.

 

Required Test Procedures

• TE02.05.01: The tester shall determine whether the vendor documentation states that a maintenance access interface is provided and any removable covers or doors are provided. If so, the tester shall refer to the evaluation of requirements in section 5 to ensure that all applicable physical security requirements of that section are met (requirements TE05.10.04, TE05.17.01, TE05.19.01, or TE05.20.04 as appropriate for the physical configuration and security level of module).

 

AS02.06: If a maintenance access interface is provided, all access defined under assertion AS02.08 in this section, including physical modifications to the contents of the module, shall be restricted to the authorized maintenance role of section 3.1. (1, 2, 3, and 4)

Required Vendor Information

• VE02.06.01: The vendor documentation shall specify how the module design and maintenance accesses, if any, ensure that any maintenance actions or physical modifications are restricted to the maintenance role(s) defined under section 3.1.

 

Required Test Procedures

• TE02.06.01: If vendor documentation states that a maintenance access interface is provided, the tester shall verify that the vendor documentation required under assertion AS02.08 in this section defines these actions in sufficient detail to allow the tester to determine whether the requirements of this assertion are met. The tester shall verify that the maintenance actions defined here are consistent with those defined in the maintenance role requirements of section 3.1 and shall also verify that the evaluation against section 3.1 shows that all applicable maintenance role requirements are met.

 

AS02.07: If a maintenance access interface is provided, all plaintext secret and private keys and other critical security parameters contained in the module shall be zeroized when accessing the maintenance interface. (1, 2, 3, and 4)

(Relevant Guidance:   2.2 , 3.6  )

Required Vendor Information

• VE02.07.01: The vendor shall ensure that all of the module's plaintext keys and other critical security parameters, as defined in section 2.1 of FIPS PUB 140-1, are actively zeroized when the maintenance interface is accessed. The vendor documentation shall show how this requirement is met.

 

Required Test Procedures

• TE02.07.01: If vendor documentation states that a maintenance access interface is provided, the tester shall verify that the vendor documentation shows that all operational plaintext keys and other unprotected critical security parameters contained in the module are actively zeroized as defined in TE02.07.02 when accessing the maintenance interface. Critical security parameters are defined in section 2.1 of FIPS PUB 140-1 to consist of cryptographic keys, authentication data such as passwords and personal identification numbers, and any other security-related information that is in a plaintext or other unprotected form, and that, if disclosed or modified, could compromise the security of the module or the security of information handled by the module.

 

• TE02.07.02: If the module has a maintenance access interface, the tester shall verify from vendor documentation that zeroization includes actively erasing keys and parameters by overwriting or otherwise altering them. Zeroization techniques may include overwriting memory, or shorting memory to ground if the vendor shows that this drains off all charge within a few seconds. However, just removing power to memory and allowing charge to slowly dissipate is not sufficient. If the module design and operating procedures allow it, the tester shall access the maintenance interface while the unit is powered up, and verify that all operational keys are zeroized (for example by attempting to encrypt or decrypt data and observing that these actions are not possible, by obtaining a report of active keys and observing that no normal keys are usable, etc.)

 

AS02.08: If a maintenance access interface is provided, documentation shall include a complete specification of the set of authorized maintenance procedures for the module. (1, 2, 3, and 4)

Required Vendor Information

• VE02.08.01: Vendor documentation shall define in detail all procedures, if any, by which authorized maintenance actions for the module are performed. These procedures shall be consistent with documentation provided under other requirements of this and all other sections.

 

Required Test Procedures

• TE02.08.01: If vendor documentation states that a maintenance access interface is provided, the tester shall verify that the vendor documentation specifies all maintenance actions that are authorized for the module in sufficient detail to allow evaluation of the requirements of other sections. In particular, the tester shall verify that the maintenance procedures defined here are consistent with the maintenance roles of section 3.1, the maintenance states of section 4, and any physical tamper protection of section 5.

 

AS02.09: Documentation shall include a complete specification describing each of the logical interfaces of the module. (1, 2, 3, and 4)

Required Vendor Information

• VE02.09.01: Documentation shall include a complete specification describing each of the interfaces of the module, including any:

 

1. Physical or logical ports and their pin assignments
2. Physical covers and doors or openings
3. Manual or logical controls
4. Physical or logical status indicators
5. Physical, logical, and electrical characteristics, as applicable, of the above interfaces

Required Test Procedures

• TE02.09.01: The tester shall verify that vendor documentation specifies the required interfaces of the module in sufficient detail to allow evaluation of the requirements under section 4.2 of FIPS PUB 140-1. The tester shall verify that this documentation is consistent with, or combined with, the description of information flows required under assertions AS01.01 and AS02.01. The required interfaces and their associated documentation shall include:

 

1. Physical or logical input and output data ports, including pin assignments, physical locations within the module, a summary of the logical signals that flow through each port, and the timing sequence of data flows if two or more signals share the same physical interface.
2. Physical covers, doors, or openings, including their physical location within the module and the components and functions that could be accessed or modified via each cover/door/opening.
3. Manual or logical controls, including their physical location within the module and a summary of the control signals that are input via the control interface.
4. Physical or logical status indicators, including their physical location within the module and a summary of the status indication signals that are output via the status interface.
5. Physical, logical, and electrical characteristics, as applicable, of the above interfaces, including summaries of pin placements, signals carried on each port, voltage levels and their logical significance (e.g., what a low or high voltage signifies in terms of a logic "0", "1", or other meaning) and the timing of signals.
6. Any other logical interfaces that the module possesses that are necessary for proper functioning of the module.

AS02.10: Documentation shall explicitly define and specify all physical and logical input and output data paths within the module. (1, 2, 3, and 4)

Required Vendor Information

• VE02.10.01: The vendor documentation shall describe all physical and logical input and output data paths in sufficient detail to specify all major categories of information input, processed, and output by the module. 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 only pass through the output data path.

 

Required Test Procedures

• TE02.10.01: The tester shall verify that the vendor documentation defines the physical and logical paths, for both input and output, to the level of detail required below. The data paths must be systematically itemized (for example: by highlighting or annotating copies of the block diagram or other information required under AS01.01, AS01.02, and AS01.05). The data paths must be defined in sufficient detail to completely specify which information passes through each port and to summarize the processing performed on the information by each module subsection between input and output.

 

• TE02.10.02: The tester shall verify from vendor documentation that all input data, other than control information, enters the module only via the defined data input interface port or ports and then flows only through the defined input data path. The tester shall also verify from vendor documentation that all output data, other than status information, flows only through the defined output data path and then leaves the module only via the defined data output interface port or ports. The tester shall examine both logical information flows, concentrating on the processing performed upon data and the logical relationships between data, and physical data flows, concentrating on the physical location in the module of data paths and data processing. If the tester finds any potential conflicts that could lead to misrouting of sensitive data, clarifying information shall be requested from the vendor if necessary.

AS02.11: 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 could be output. (1, 2, 3, and 4)

Required Vendor Information

• VE02.11.01: If there is any possibility that the module design could allow plaintext cryptographic keys or other critical security parameters to be output on any ports, the design shall require two independent internal actions before output occurs at such ports. In this case, the vendor documentation shall define what these actions are and how they protect against inadvertent release of critical security parameters. This documentation shall include specification of the module functional areas (whether in hardware and/or software) in which the two independent actions are performed.

 

Required Test Procedures

• TE02.11.01: The tester shall determine from vendor documentation whether it is possible to output plaintext keys or other critical security parameters (as defined in section 2.1 of FIPS PUB 140-1). If so, the tester shall verify that the documentation specifies two independent internal actions that must take place before release of any data is allowed on any ports that could release critical security parameters. The independent actions must be logical or physical changes to two areas of the module that are sufficiently independent in function, and separated in location, that a malfunction to one area will not affect the proper functioning of the other area.

 

• TE02.11.02: The tester shall verify that the dual internal actions specified in TE02.11.01 above, and the module areas which are exercised, are consistent with the module description required under assertions AS01.01 and AS01.05. If any software or firmware is executed in the process of outputting data , the tester shall examine the source code listings, if practical, to ensure that the software supports the requirement for two independent actions before data is output from the affected ports.

 

AS02.12: The output data path shall be logically disconnected from the circuitry and processes performing key generation, manual key entry, or key zeroization. (1, 2, 3, and 4)

Required Vendor Information

• VE02.12.01: The vendor documentation shall show that the design of the module ensures logical separation of the output data path from processes performing generation, manual entry, and zeroization of cryptographic keys.

 

Required Test Procedures

• TE02.12.01: The tester shall verify that vendor documentation demonstrates that the output data path, as defined under AS02.10, is logically disconnected from processes performing key generation, manual key entry, and key zeroization. This requirement implies that the specified key processes cannot pass information to the output data path, and that the output data path cannot interfere in any way with the key processes. If the key and data paths are physically shared to any extent (which is allowed for levels 1 and 2), the tester shall verify that the vendor documentation shows how the module design enforces separation of the key and other output data under any reasonable conditions, including any checks, alarms, or shut-offs that enforce this separation. Such protective measures might include separation of key and output data processes in location (separate paths and ports for keys versus other data), or time (so that no output is allowed during key processing, for example), or the use of software isolation (header tags and checking, multilevel security isolation, etc.)

 

• TE02.12.02: If it is practical, and the module design and operating procedures permit it, the tester shall record or observe data on the output data port or ports while performing possible key functions (such as generation, manual entry, and zeroization) and verify that no critical security parameters (as defined in section 2.1 of FIPS PUB 140-1) are released.

 

AS02.13: For security levels 3 and 4, data input and output ports used for plaintext cryptographic keys, plaintext authentication data, and other unprotected critical security parameters shall be physically separated from all other ports of the module. (3 and 4)

(Relevant Guidance:   2.3 , 2.4  )

Required Vendor Information

• VE02.13.01: For security levels 3 and 4, if the module design requires use of unprotected critical security parameters, including plaintext cryptographic keys or plaintext authentication data, data ports for input or output of these parameters shall be physically separated from all other ports. The vendor documentation shall show how this is done.

 

Required Test Procedures

• TE02.13.01: For security levels 3 and 4, the tester shall determine from vendor documentation whether the module requires input or output of unprotected critical security parameters as defined in section 2.1 of FIPS PUB 140-1. If so, the tester shall verify, from vendor documentation and also by physical inspection of the ports on the module, that both the corresponding critical security parameter input and output ports are physically separate from all other ports. The tester shall also verify that only unprotected critical security parameters, including plaintext cryptographic keys or plaintext authentication data, enter or exit the module through these ports. The tester shall verify that any documentation on data paths provided by the vendor in connection with this requirement is consistent with, or contained in, documentation provided in connection with assertion AS02.10. (Note that separate pins within one connector may be considered separate ports.)

 

AS02.14: For security levels 3 and 4, data input and output ports used for plaintext cryptographic keys, plaintext authentication data, and other unprotected critical security parameters shall allow for direct entry of these items. (3 and 4)

Required Vendor Information

• VE02.14.01: For security levels 3 and 4, if the module design requires use of unprotected critical security parameters, including plaintext cryptographic keys or plaintext authentication data, data ports for input or output of these parameters shall be directly connected to the cryptographic boundary without passing through any processors, complex logic blocks, or module areas performing functions unrelated to key handling which are outside the cryptographic boundary. The vendor documentation shall show how this is done.

 

Required Test Procedures

• TE02.14.01: For security levels 3 and 4, the tester shall determine from vendor documentation whether the module requires input or output of unprotected critical security parameters as defined in section 2.1 of FIPS PUB 140-1. If so, the tester shall verify that the vendor documentation defines the path between the input or output ports and the cryptographic boundary. The tester shall then verify that the above security parameters pass directly between the input/output ports and the cryptographic boundary without unnecessarily passing through other module components. In particular, while outside the cryptographic boundary, the security parameters must not pass through any general-purpose processors that have functions other than handling security parameters, nor through any areas handling unrelated input or output functions. (Temporary display of manually entered encrypted keys is allowed as described under AS08.12.)

 

• General: Documentation of input, output, control, or status interfaces must also include identification of any external input/output devices to be used with module, such as keypads, displays, smart cards, etc.

 

3. ROLES AND SERVICES

Roles

(Relevant Guidance:   3.1 , 3.2  )

Required Vendor Information

• VE03.01.01: Vendor documentation shall specify each distinct authorized role, including its name, purpose, and the services that are performed in the role.

 

Required Test Procedures

• TE03.01.01: The tester shall review the vendor documentation and verify that, for each defined role, the name, purpose, and available services for this role are specified. The roles that should be described are as follows:

 

1. Crypto-officer role (one or more)
2. User role (one or more)
3. Maintenance role (only if the module includes a maintenance interface)
4. Other roles
• TE03.01.02: The tester shall assume each of the authorized roles described in the vendor documentation and verify that each of them can be assumed. Verification of the services that are designated for each role will be performed under AS03.07.

 

AS03.02: The cryptographic module shall, at a minimum, support the following authorized roles: (1, 2, 3, and 4)

• User role: The role assumed by an authorized user obtaining security services, performing cryptographic operations, or other authorized functions.
• Crypto-officer role: The role assumed by an authorized crypto officer performing a set of cryptographic initialization or management functions (e.g., cryptographic key and parameter entry, cryptographic key cataloging, audit functions, and alarm resetting).

Required Vendor Information

• VE03.02.01: In the documentation required to satisfy VE03.01.01 above, the vendor shall include at least one user role and one crypto-officer role.

 

Required Test Procedures

• TE03.02.01: The tester shall review the vendor documentation and verify that, in the specification of the authorized roles, at least one user role and at least one crypto-officer role are defined. These roles shall be specified by name, purpose, and allowed services. These roles shall be described as specified in AS03.02.

 

AS03.03: If a cryptographic module includes a maintenance access interface as specified in section 4.2, the module shall also support the maintenance role. (1, 2, 3, and 4)

(Relevant Guidance: 3.6)

• Maintenance role: The role assumed by an authorized maintenance person accessing the maintenance access interface and/or performing specific maintenance tests and obtaining interim results in order to maintain, service or repair the module.

 

Required Vendor Information

• VE03.03.01: If the module has a maintenance interface, the vendor documentation shall explicitly state a maintenance role is supported. The documentation shall completely specify the role by name, purpose, and allowed services. Note that the maintenance role involves accessing and running tests on the module while it is operational; it does not involve any physical maintenance. The maintenance is a role that can be assumed by an operator and recognized by the module.

 

Required Test Procedures

• TE03.03.01: The tester shall check the specifications of the module interfaces to determine whether a maintenance interface is specified (see AS02.03). If so, the tester shall check the vendor documentation pertaining to the authorized roles and verify that the maintenance role is specified by name, purpose, and allowed services.

 

AS03.04: If the maintenance role is supported, a cryptographic module shall clear all plaintext secret and private keys and other critical security parameters when entering the maintenance role. A related assertion is AS02.07. (1, 2, 3, and 4)

(Relevant Guidance: 3.6)

Required Vendor Information

• VE03.04.01: The vendor shall ensure all of the module's plaintext secret and plaintext private keys and critical security parameters, as defined in section 2.1 of FIPS PUB 140-1, are actively zeroized when the maintenance role is entered. Note that the maintenance role is an active role (i.e., the module must still be powered up in order to assume the role). The vendor documentation shall specify how this requirement is met. Methods for zeroization could include, but not be limited to, software or firmware code or the automatic assertion of certain signals within the module.

 

Required Test Procedures

• TE03.04.01: If vendor documentation states that a maintenance role is implemented in the module, the tester shall verify that the vendor documentation specifies the method by which plaintext secret and plaintext private keys and critical security parameters are zeroized when the maintenance role is entered. Critical security parameters are defined in section 2.1 of FIPS PUB 140-1 to consist of cryptographic keys, authentication data such as passwords and personal identification numbers (PINs) and any other security-related information that is in plaintext or otherwise unprotected form and that, if disclosed or modified, could compromise the security of the module or of information handled by the module.

 

• TE03.04.02: If the module implements a maintenance role, the tester shall verify from vendor documentation that zeroization is performed as defined in TE02.07.02.

 

AS03.05: If the maintenance role is supported, a cryptographic module shall clear all maintenance keys and other critical security parameters when exiting the maintenance role. (1, 2, 3, and 4)

Required Vendor Information

• VE03.05.01: The vendor shall ensure all of the module's maintenance keys and other critical security parameters are actively zeroized when the maintenance role is exited. The vendor documentation shall specify how this requirement is met. Methods for zeroization could include, but not be limited to, software or firmware code or the automatic assertion of certain signals within the module.

 

Required Test Procedures

• TE03.05.01: If vendor documentation states that a maintenance role is implemented in the module, the tester shall verify that the vendor documentation specifies the method by which maintenance keys and other critical security parameters are zeroized when the maintenance role is exited. Critical security parameters are defined in section 2.1 of FIPS PUB 140-1 to consist of cryptographic keys, authentication data such as passwords and personal identification numbers (PINs) and any other security-related information that is in plaintext or otherwise unprotected form and that, if disclosed or modified, could compromise the security of the module or of information handled by the module.

 

• TE03.05.02: If the module implements a maintenance role, the tester shall verify from vendor documentation that zeroization is performed as defined in TE02.07.02.

 

AS03.06: If a module can support multiple concurrent operators, then the module shall internally maintain the separation of the authorized roles and services performed by each operator. (1, 2, 3, and 4)

Required Vendor Information

• VE03.06.01: The vendor documentation shall specify whether multiple concurrent operators are allowed. If so, the vendor shall describe the method by which separation of the authorized roles and services performed by each operator is achieved. The vendor documentation shall also describe any restrictions on concurrent operators (e.g., one operator in a maintenance role and another in a user role simultaneously is not allowed).

 

Required Test Procedures

• TE03.06.01: The tester shall review the vendor documentation and verify that the method is described by which the module enforces separation between the roles and services performed by concurrent operators.

 

• TE03.06.02: The tester shall take on the identity of two independent operators: Operator1 and Operator2. The operators shall assume two different roles. The tester shall verify that only the services allocated to the role assumed by each operator can be performed in that role. The tester shall also attempt, for each operator, to access services that are unique to the role assumed by the other operator in order to verify that separation is maintained between the roles and services allowed in concurrent operators.

 

• TE03.06.03: If the vendor documentation specifies any restrictions on concurrent operators, the tester shall attempt to violate the restrictions by attempting to concurrently assume restricted roles as independent operators and verify that the module enforces the restrictions by preventing the second operator from assuming the role.

 

Services

(Relevant Guidance: 3.2 , 3.3  )

Required Vendor Information

• VE03.07.01: The vendor documentation shall fully describe each service including its purpose and function. The possible services may include, but not be limited to, the following:

 

1. Cryptographic operations, such as:

 

• Encryption
• Decryption
• Message integrity
• Digital signature generation
• Digital signature verification
• Other operations that require the use of cryptography
2. Key management operations, such as:

 

• Key and parameter entry
• Key generation
• Key output
• Key archiving
• Key zeroization
• Other key management functions
3. Cryptographic management functions, such as:

 

• Audit parameter entry and setting
• Alarm handling and resetting
• Other cryptographic management functions
4. Performance of operator-selectable self tests, such as:

 

• Cryptographic algorithm tests
• Software/firmware tests
• Critical functions tests
• Statistical random number generator tests
• Any additional tests that can be initiated by an operator
5. "Show Status" that would indicate the following:

 

• Active role(s)
• Cryptographic state of module (zeroized, tampered, loaded, initialized, etc.)
• If module is in error state, error code.
• If bypass capability exists, whether the bypass capability is enabled or disabled.
6. Performance of maintenance tests

 

7. Cryptographic bypass

 

• VE03.07.02: The vendor documentation shall specify, for each service, the service inputs, corresponding service outputs, and the authorized role or roles in which the service can be performed. 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. The vendor may supply a matrix that displays the services that can be performed in each role.

 

Required Test Procedures

• TE03.07.01: The tester shall check the vendor documentation and verify that the purpose and function of each service is described. The tester shall also check that the following information is specified for each service: service inputs, corresponding service outputs, and the authorized role or roles in which the service can be performed.

 

• TE03.07.02: The tester shall check the vendor documentation and verify that, for the indicated roles, the listed services, at a minimum, may be allowed:

 

1. User role, such as:

 

• Cryptographic operations (may be allowed to access a subset of those listed in VE03.07.01)
• Key management functions
• "Show Status"
• Performance of operator selectable self-tests
• Cryptographic bypass
2. Crypto-officer role, such as:

 

• Key management functions
• Cryptographic management functions
• "Show Status"
• Performance of operator selectable tests
• Cryptographic bypass
3. Maintenance role, such as:

 

• Subset of key management functions (for entry of maintenance keys)
• Cryptographic operations (may be allowed to access a subset of those listed in VE03.07.01)
• "Show Status"
• Performance of operator-selectable self-tests
• Performance of maintenance tests
• Cryptographic bypass
• TE03.07.03: The tester shall verify the accuracy of the vendor-supplied documentation. The tester shall perform the following tests for each role:

 

1. Perform each of the specified services for the role to verify that they have been implemented for that role.
2. Enter each of the specified service inputs and observe that they result in the specified service outputs.
3. Attempt to perform services that are not specified for the role to verify that they have not been implemented for that role.

AS03.08: A cryptographic module shall, at a minimum, provide the following services: (1, 2, 3, and 4)

• Show Status: Output the current status of the module
• Self-test: Initiate and run the self-tests as specified in section 4.11.

 

Required Vendor Information

• VE03.08.01: The vendor documentation shall describe the output of the current status of the module and the initiation and running of user callable self-tests, along with other services as specified by VE03.07.01.

 

Required Test Procedures

• TE03.08.01: The tester shall check the vendor documentation to verify that the "Show Status" status service and the user callable self-test initiation service are each allocated to at least one authorized role. The tester shall verify that these services are described as specified in AS.03.07.

 

• TE03.08.02: Verification that the "Show Status" can be initiated for designated roles was performed under TE03.07.03. In addition, the tester shall verify that what the "Show Status" reports matches the vendor documentation.

 

• TE03.08.03: Verification that the module provides for the initiation and running of self-tests as specified in section 4.11 was performed under TE03.07.03. If the module does not provide this service for at least one authorized role, this assertion fails.

 

AS03.09: A cryptographic module may optionally provide the following service: (1, 2, 3, and 4)

• Bypass: Activate or deactivate a bypass capability whereby services are provided without cryptographic processing (e.g., transferring plaintext through the module).

 

Required Vendor Information

• VE03.09.01: If the module implements a bypass capability, the vendor documentation shall describe the bypass service as specified in AS03.09.

 

Required Test Procedures

• TE03.09.01: The tester shall determine whether the bypass capability is implemented by the module. If so, the tester shall check the vendor documentation to verify that the bypass capability is allocated to at least one authorized role. The tester shall verify that this service is described as specified in AS.03.09.

 

• TE03.09.02: Verification that the bypass capability can be performed for designated roles was tested in TE03.07.03. If the bypass capability cannot be initiated by at least one role, this assertion fails.

 

AS03.10: If a cryptographic module implements a bypass capability, then: (1, 2, 3, and 4)

• In order to prevent the inadvertent bypass of data due to a single failure, two independent internal actions shall be implemented to activate the bypass capability.

 

• The current status of the module (e.g., the response to a "Show Status" service request) shall indicate whether or not the bypass capability is activated.

 

Required Vendor Information

• VE03.10.01: The finite state machine diagram and description documentation shall indicate, for all transitions into a bypass state, the two independent internal actions that are required to transition into that bypass state. In the vendor documentation for the "Show Status" service, the ability to output whether the bypass capability is enabled or disabled must be included.

 

Required Test Procedures

• TE03.10.01: The tester shall review the finite state diagram and description to determine whether each transition into a bypass state shows two independent internal actions that must occur in order for the cryptographic module to transition into the bypass state.

 

• TE03.10.02: The tester shall attempt to transition to each bypass state from each state that shows such a transition, and determine that it takes two internal actions to accomplish each such transition.

 

• TE03.10.03: Tester verification of the vendor documentation for the "Show Status" service was performed under TE03.08.01 and TE03.08.02. If the bypass capability exists, then the results of the verification should indicate that a "Show Status" service request shows that the bypass capability is enabled or disabled; otherwise, this assertion fails.

 

AS03.11: Each service input shall result in a service output. (1, 2, 3, and 4)

Required Vendor Information

• VE03.11.01: The vendor documentation shall indicate service outputs for each service input.

 

Required Test Procedures

• TE03.11.01: The validation of the specification of a service output for each service input is covered by TE03.07.01. The testing of the status inputs and outputs is covered by TE03.07.03. The results of the verification should indicate that each service input has a corresponding service output as documented by the vendor; otherwise, this assertion fails.

 

OPERATOR AUTHENTICATION

General

Required Vendor Information

• VE03.12.01: If means are provided to control access to the module before it has been initialized, the vendor shall document them in detail.

 

Required Test Procedures

• TE03.12.01: The tester shall check the vendor documentation to determine what means, if any, are provided for access control prior to initialization of the module. If the module supports these means, the documentation should specifically describe the procedure by which the crypto-officer is authenticated upon accessing the module for the first time. No other role shall be allowed to access the module until the module has been initialized.

 

• TE03.12.02: If access to the module before initialization is controlled, the tester shall make an error (e.g., enter an incorrect password) while assuming the crypto-officer role on an uninitialized module and shall verify that the module denies access to the role. The tester shall then successfully assume the crypto-officer role and verify that the required authentication complies with the documented procedures. The tester shall attempt to assume other roles before the module has been initialized and verify that the module denies access to the roles.

 

AS03.13: When a module is powered up after being powered off (e.g. power failure) or after repair or servicing, the results of previous authentications shall not be retained, i.e., the module shall re-authenticate the authorization of the operator to assume a desired role. (1, 2, 3, and 4)

Required Vendor Information

• VE03.13.01: The vendor documentation shall describe how the results of previous authentications are cleared when the module is powered down.

 

Required Test Procedures

• TE03.13.01: The tester shall review the vendor documentation and verify that the clearing of previous authentications upon power down of the module is described clearly and correctly.

 

• TE03.13.02: The tester shall authenticate himself/herself to the module by assuming one or more roles, power down the module, power up the module, and attempt to perform services in those roles. The module should deny access to the services and require that the tester be re-authenticated.

 

Role-Based Authentication

• Require that the operator explicitly or implicitly select one or more roles
• Authenticate that the operator is authorized to assume the selected roles and corresponding services

Required Vendor Information

• VE03.14.01: The vendor shall document the mechanisms used to perform the implicit or explicit selection of a role or set of roles and the authentication of the authorization of the operator to assume the role(s). Note that role-based authentication is based only on the presentation of information that allows access to a role or set of roles. This information must be different for each role, but it is the same for everyone that wants to access the same role; two operators that want to assume the same role will present the same information to the module.

 

Required Test Procedures

• TE03.14.01: The tester shall review the sections of the vendor documentation that describe how role-based authentication is performed. The tester shall check that the documentation specifies and describes the mechanisms used for the selection of a role or roles and the authentication of the authorization of the operator to assume a role. The documentation may specify and describe the usage of one or more of the following mechanisms:

 

1. Password
2. Personal Identification Number (PIN)
3. Cryptographic key or equivalent
4. Possession of a physical key, token, or equivalent
5. Biometrics (e.g., fingerprint, retina scan, keystroke dynamics)
• TE03.14.02: The tester shall assume the role and shall make some error (e.g., entry of an incorrect password) during the authentication procedure. The tester shall observe that the module denies access to the role.

 

AS03.15: For role-based authentication, a module may permit an operator to change roles, but the module shall authenticate the authorization of the operator to assume any role that was not previously authenticated. (2)

Required Vendor Information

• VE03.15.01: The vendor shall document whether the module allows an operator to change roles. If so, the vendor documentation shall describe the ability of an operator to change roles and shall explicitly state that authentication of the operator for a new role is required.

 

Required Test Procedures

• TE03.15.01: The tester shall check the vendor documentation to verify that the method by which an operator can change roles includes the authentication of the operator for a role not previously authenticated.

 

• TE03.15.02: The tester shall perform the following tests:

 

1. Assume a role, attempt to change to another role that the operator is authorized to assume, and verify that the module requires authentication for the new role.
2. Assume a role, attempt to change to another role that the operator is not authorized to assume, and verify that the module denies access.

Identity-Based Authentication

• Require that the operator be individually identified
• Authenticate the specified identity of the operator
• Require that the operator either implicitly or explicitly select one or more roles
• Based on the authenticated identity, verify that the operator is authorized to perform the selected roles and corresponding services

Required Vendor Information

• VE03.16.01: The vendor shall document the mechanisms used to perform the identification of the operator, the authentication of the operator's identity, the implicit or explicit selection of a role or set of roles, and the verification of the authorization of the operator to assume the role(s). Note that identity-based authentication takes into account the identity of the operator assuming a role. This applies not only between roles but within the same role; two operators that want to assume the same role will present different information to the module because their identities are different. If, for example, operators must enter a PIN when attempting to assume a role, each operator should have a different PIN because the PIN identifies the operator to the module.

Required Test Procedures

• TE03.16.01: The tester shall review the sections of the vendor documentation that describe how identity-based authentication is performed. The tester shall check that the documentation specifies how the operator is uniquely identified, how that identity is authenticated, how the operator chooses a role, and how the authorization of the operator to assume a role is performed based on the authenticated identity. The documentation may specify and describe the usage of one or more of the following mechanisms:

 

1. Password
2. Personal Identification Number (PIN)
3. Cryptographic key or equivalent
4. Possession of a physical key, token, or equivalent
5. Biometrics (e.g., fingerprint, retina scan, keystroke dynamics)
• TE03.16.02: The tester shall make some error (e.g., entry of an incorrect password) during the authentication procedure and shall observe that the module does not allow the tester to proceed beyond the authentication procedure.

 

• TE03.16.03: The tester shall successfully authenticate his/her identity to the module. When required to select one or more roles, the tester shall select roles not compatible with the authenticated identity and shall observe that authorization to assume the roles is denied.

 

AS03.17: For identity-based authentication, a module may permit an operator to change roles without re-authenticating the identity of the operator, but the module shall verify the authorization of the authenticated operator to perform the new role. (3 and 4)

Required Vendor Information

• VE03.17.01: The vendor shall document whether the module allows an operator to change roles without re-authenticating his/her identity. If it does, the vendor documentation shall describe the ability of an operator to change roles and shall explicitly state that verification of the authentication of the operator for a new role is required.

 

Required Test Procedures

• TE03.17.01: The tester shall check the vendor documentation to verify that the method by which an operator can change roles without re-authentication of the operator's identity includes the verification of the authorization of the operator for a role not previously authenticated.

 

• TE03.17.02: The tester shall perform the following tests:

 

1. Assume a role, attempt to change to another role that the tester is authorized to assume, verify that the tester's identity does not have to be re-authenticated, and verify that the tester can access the services associated with the new role. The tester shall perform services in the new role that were not associated with the previous role in order to verify that the tester has assumed a different role.
2. Assume a role, attempt to change to another role that the operator is not authorized to assume, and verify that the module denies access to the role based on the identity of the operator.

Security Level 1

Required Vendor Information

• VE03.18.01: The vendor shall explicitly document what type of authentication will be performed for the module. If the module does not require either role-based or identity-based authentication, the vendor documentation shall explicitly state this requirement. The vendor documentation shall describe the authentication mechanisms used as specified in VE03.14.01 and VE03.16.01.

 

Required Test Procedures

• TE03.18.01: The tester shall review the vendor documentation to determine the following:

 

1. Type of authentication specified for the module (role-based, identity-based, or none)
2. Specification and description of the authentication mechanisms
• TE03.18.02: For each role, the tester shall perform the documentation, verification, and test procedures specified in TE03.14.01-02 and TE03.15.01-02 for role-based authentication and TE03.16.01-03 and TE03.17.01-02 for identity-based authentication.

 

Security Level 2

Required Vendor Information

• VE03.19.01: The vendor shall explicitly document whether either role-based or identity-based authentication is performed for the module. The vendor documentation shall describe the authentication mechanisms used as specified in VE03.14.01 and VE03.16.01.

 

Required Test Procedures

• TE03.19.01: The tester shall review the documentation to determine the following:

 

1. Type of authentication specified for the module (role-based or identity-based)
2. Specification and description of the authentication mechanisms
• TE03.19.02: For each role, the tester shall perform the documentation verification and test procedures specified in TE03.14.01-02 and TE03.15.01-02 for role-based authentication and TE03.16.01-03 and TE03.17.01-02 for identity-based authentication.

 

Security Levels 3 and 4

(Relevant Guidance: 3.5 ,  )

Required Vendor Information

• VE03.20.01: The vendor documentation shall explicitly state that identity-based authentication is performed for the module. The vendor documentation shall also describe the authentication mechanisms used as specified in VE03.16.01.

 

• VE03.20.02: Requirements for vendor documentation addressing the entry of plaintext authentication data via dedicated, directly connected ports are covered under VE02.13.01 and VE02.14.01.

 

Required Test Procedures

• TE03.20.01: For each role, the tester shall perform the documentation verification and test procedures specified in TE03.16.01-03 and TE03.17.01-02 for identity-based authentication.

 

• TE03.20.02: Tester verification of the entry of plaintext authentication data, plaintext cryptographic key components, and other unprotected critical security parameters via dedicated, directly connected ports was performed under TE02.13.01 and TE02.14.01. The results of the verification should indicate that physically separated ports are used for the entry of these items into the module; otherwise, this assertion fails.

 

4. FINITE STATE MACHINE MODEL

(Relevant Implementation Guidance:  4.1 )

Required Test Procedures

• TE04.01.01: This assertion is tested by testing the following assertions.

 

AS04.02: Documentation shall identify and describe all states of the module and shall describe all of the corresponding state transitions. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  4.1 )

Required Vendor Information

• VE04.02.01: The vendor shall provide a description of the finite state machine model. This description shall contain the identification and description of all states of the module, and a description of all corresponding state transitions. The descriptions of the state transitions shall include internal module conditions, data inputs and control inputs that cause transitions from one state to another and internal module conditions, data outputs and status outputs resulting from transitions from one state to another.

 

Required Test Procedures

• TE04.02.01: The tester shall verify that the vendor has provided a description of the finite state machine model. This description shall contain the identification and description of all states of the module, and a description of all corresponding state transitions.

 

AS04.03: The descriptions of the state transitions shall include the internal module conditions, data inputs and control inputs that cause transitions from one state to another, and shall include the internal module conditions, data outputs and status outputs resulting from transitions from one state to another. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  4.1 )

Required Test Procedures

• TE04.03.01: The tester shall verify that the descriptions of the state transitions include the internal module conditions, data inputs and control inputs that cause transitions from one state to another, and the internal module conditions, data outputs and status outputs resulting from transitions from one state to another.

 

AS04.04: Documentation shall also include finite state diagrams in sufficient detail to assure the verification of conformance to FIPS PUB 140-1. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  4.1 )

Required Vendor Information

• VE04.04.01: The vendor shall provide finite state machine diagram(s) in sufficient detail to assure the verification of conformance to FIPS PUB 140-1.

 

Required Test Procedures

• TE04.04.01: The tester shall verify that the vendor has provided finite state machine diagram(s) in sufficient detail to assure the verification of conformance to FIPS PUB 140-1.

 

AS04.05: A cryptographic module shall be designed using the following types of states: (1, 2, 3, and 4)

• Power on/off states. States for primary, secondary, or backup power. These states may distinguish between power applied to different portions of the module.
• Crypto officer states. States in which the crypto officer functions are performed (e.g., cryptographic initialization and key management functions).
• Key entry states. States for entering cryptographic keys and other critical security parameters into the module, and for checking their validity.
• User service states. States in which authorized users obtain security services, perform cryptographic operations, or perform other authorized user functions.
• Self test states. States for performing self-tests on the module (see section 11, "Self Tests").
• Error states. States when the module has encountered an error (e.g., failed a self-test, attempting to encrypt while missing operational keys or other critical security parameters, or cryptographic errors). Error states may include "hard" errors which indicate an equipment malfunction and which may require maintenance, service or repair of the module, or error states may include recoverable "soft" errors which may require initialization or resetting of the module.

 

Required Test Procedures

• TE04.05.01: The tester shall verify that the finite state diagrams and the descriptions are consistent with the vendor documentation that describes the following:

 

1. Data input interface
2. Data output interface
3. Control input interface
4. Status output interface
5. Crypto officer role
6. User role
7. Other roles (if applicable)
8. Key entry services
9. Show status service
10. Self-tests
11. Other authorized services, operations, and functions (if applicable)
12. Error states
• TE04.05.02: The tester shall verify that the operation of the module is consistent with the finite state diagrams and descriptions.

 

AS04.06: A cryptographic module may contain other types of states including the following: (1, 2, 3, and 4)

• Un-initialized states. States in which no operational security parameters are loaded into the module.
• Idle states. States in which the module is potentially operational, but is not currently providing security services or performing cryptographic functions. Cryptographic keys and security parameters are loaded, and the module is waiting for data or control inputs.
• Safety states. States in which the module is not currently operational, but cryptographic keys and parameters are loaded. These states are used to protect the module from unauthorized use during the temporary absence of the operator.
• Bypass states. States for providing services without cryptographic operations (e.g., transferring plaintext through the module).
• Maintenance states. States for maintaining and servicing a module, including maintenance testing.

 

Required Test Procedures

• TE04.06.01: The tester shall verify that the finite state diagrams and the descriptions are consistent with the vendor documentation that describes the following:

 

1. Bypass service (if applicable)
2. Maintenance interface (if applicable)
3. Maintenance role (if a maintenance interface is provided)
4. Key generation services (if applicable)
5. Key output services (if applicable)
• TE04.06.02: The tester shall verify that the operation of the module while in an un-initialized, idle, safety, bypass, or maintenance state is consistent with the finite state diagrams and descriptions.

 

AS04.07: All data output via the data output interface shall be inhibited during all error states. (1, 2, 3, and 4)

 Note: This assertion is similar to assertion AS02.04 under section 2, "Module Interfaces."

Required Test Procedures

• TE04.07.01: This assertion is tested under TE02.04.02.

 

AS04.08: All error states shall be able to be reset to an acceptable operational or initialization state except for those hard errors which require maintenance, service or repair of the module. (1, 2, 3, and 4)

Required Test Procedures

• TE04.08.01: From each error state that does not require maintenance or repair, the tester shall verify that the cryptographic module can be caused to transition to an acceptable operational or initialization state. This effort consists of two parts: first, the tester shall verify that the cryptographic module indicates when it is in such a state, and second, that the cryptographic module operates correctly in this target state. The tester shall report how the requirement was verified (i.e., by code examination or by exercising the module).

 

AS04.09: If safety states are included in the module, then the safety states shall require an explicit authenticated action to return to a user/crypto service state. These states are equivalent to the "standby" mode of former Federal Standard 1027. (1, 2, 3, and 4)

Required Test Procedures

• TE04.09.01: The tester shall attempt to issue all user and crypto-officer commands from each safety state to demonstrate that no operator commands can be issued until the module leaves the safety state.

 

• TE04.09.02: For each defined safety state, the tester shall perform an explicit authentication action to exit the safety state. For each safety state, this explicit authentication action must be described in the vendor's operational documentation.

 

AS04.10: If a cryptographic module includes a maintenance access interface (see Section 2, "Module Interfaces"), then the module shall include maintenance states. (1, 2, 3, and 4)

Required Test Procedures

• TE04.10.01: If the module includes a maintenance interface, then the tester shall make sure that the finite state machine model has at least one maintenance state defined. All such maintenance states must be contained in the finite state diagram(s) and described in the description of the finite state machine model.

 

AS04.11: All states of a cryptographic module shall be explicitly defined in sufficient detail to assure the verification of the conformance of the module to FIPS PUB 140-1. (1, 2, 3, and 4)

 Note: Refer back to the corresponding portions of requirement 1, "Cryptographic Module," and requirement 2, "Module Interface," for completeness.

Required Test Procedures

• TE04.11.01: The tester shall review the descriptions of the states of the cryptographic module to determine if the descriptions clearly define disjoint states.

 

• TE04.11.02: The tester shall exercise the cryptographic module, causing it to enter each of its major states. For each state that has a distinct indicator, the tester shall attempt to observe the indicator while the module is in the state. If the expected indicator is not observed, or two or more such indicators are observed at the same time (indicating that the module is in more than one state at one time), this test fails.

 

• TE04.11.03: The tester shall verify that every state that is identified in the finite state diagram(s) is also identified and described in the description.

 

• TE04.11.04: The tester shall verify that every state that is identified and described in description is also identified in the finite state diagram(s).

 

• TE04.11.05: The tester shall verify that there exists a chain of transitions from an initial power on state to each other state in the model that is not an initial power on state.

 

• TE04.11.06: The tester shall verify that there exists a chain of transitions from each nonpower off state to a power off state of the model.

 

• Note: TE04.11.05 and TE04.11.06 imply that there may be more than one possible initial state and more than one possible final state.

 

• TE04.11.07: The tester shall verify that the action of the finite state machine, as the result of all possible data and control inputs, is defined. An example of an acceptable inclusive statement is:

"The action of the finite state machine as a result of all other combinations of data and control inputs is to place the finite state machine into the ERROR-3 state."

 

• TE04.11.08: The tester shall verify that all possible combinations of data and control nputs can be partitioned into disjoint sets, depending on the transition that would be taken in response to the input. This requirement guarantees that the finite state machine is deterministic; that is, for each possible pair of data and control inputs, the finite state machine must take one and only one transition.

 

Continue to sections 5-7 of the DTR (part 2 of 3)...

Last Update: March 15, 2002
Computer Security Division
National Institute of Standards and Technology