PART 2
(Sections 5-7)

Part 1 (sections 1-4)

Part 3 (sections 8-11)

Appendix A

5. PHYSICAL SECURITY

Required Vendor Information

• VE05.01.01: The vendor documentation shall specify which one of three physical embodiments the module is: single-chip cryptographic module, multiple-chip embedded cryptographic module, or multiple-chip stand-alone cryptographic module, as defined in the initial paragraphs of sections 4.5.1, 4.5.2, or 4.5.3, respectively, of FIPS PUB 140-1. The specified physical embodiment shall be consistent with the actual module physical design. The vendor documentation shall also explicitly state which security level (1 through 4) the module is intended to meet.

 

• VE05.01.02: The vendor documentation shall completely describe the applicable physical security mechanisms that are employed by the module. The entire contents of the module, including all hardware, firmware, software, and data (including plaintext cryptographic keys and unprotected critical security parameters) shall be protected.

 

Required Test Procedures

• TE05.01.01: The tester shall verify that the vendor documentation specifies which physical embodiment the module is. However, the tester shall make an independent determination, by evaluation against the definitions below, of the physical embodiment that the module actually meets. If the tester's determined physical embodiment is different than the vendor's specified physical embodiment, the tester shall contact the vendor and resolve the differences before completing the validation. The tester shall utilize the module definition required under the requirements of section 1, along with any other appropriate vendor documentation, to determine the physical embodiment of the module. The fundamental determining characteristics of the three physical embodiments and some common examples are summarized below.

 

1. Single-chip cryptographic module. Characteristics: A single integrated circuit (IC) chip, used as a stand-alone device or physically embedded within some other module or enclosure that may not be physically protected. The chip normally will consist of one die, or multiple dice connected on a substrate, that is covered with a uniform external material such as plastic or ceramic, and external input/output connectors. Examples: Single IC chips, smart cards with a single IC chip, or other systems with a single IC chip to implement cryptographic functions.
2. Multiple-chip embedded cryptographic module. Characteristics: Two or more IC chips interconnected and physically embedded within some other module or enclosure that may not be physically protected. Examples: Adapters, expansion boards or other modules that are not single chips and are not contained within their own physically protected enclosures.
3. Multiple-chip stand-alone cryptographic module. Characteristics: Two or more IC chips interconnected and physically embedded in an enclosure that is entirely physically protected as defined in the requirements for the applicable security level. Examples: An IC-printed circuit board or chips on a ceramic substrate with a protected enclosure.
• TE05.01.02: The tester shall verify that the vendor documentation states which security level the module is intended to meet. However, the tester shall make an independent determination, via evaluation against the requirements of this section of the validation process, of the security level that the module actually meets. If the tester's determined security level is obviously different than the vendor's intended security level, the tester shall contact the vendor and resolve the differences before completing the validation.

 

• TE05.01.03: The tester shall verify that the vendor documentation completely describes the applicable physical security mechanisms that are employed by the module. The physical security mechanisms may include any of the following list that depend on and determine the physical embodiment and the security level met by the module:

 

1. Passivation
2. Coating or potting that may be opaque, hard, tamper-evident, removal-resistant, or a combination of the above characteristics
3. Enclosure that may be nonremovable or have removable covers or doors
4. Tamper protection (locks, seals, tamper detection, or tamper response)
5. Probe-protected ventilation holes
6. Environmental failure protection or environmental failure testing
The tester shall verify in each case claimed above, and in the analyses that follow from the validation requirements below, that the entire module is physically protected. For example, passivation must apply to all ICs in the module; a coating, enclosure or tamper protection must protect the entire module; etc. This requirement specifically includes all hardware containing firmware, software, and data (including plaintext cryptographic keys and unprotected critical security parameters).

 

AS05.02: For a single-chip cryptographic module at security level 1 or higher, the chip shall be of production quality that shall include standard passivation techniques. Single-chip; 1, 2, 3, and 4)

Required Vendor Information

• VE05.02.01: The module shall be a standard, production-quality IC, designed to meet at least typical commercial-grade specifications for power, temperature, reliability, shock/vibration, etc. In particular, the module shall use standard passivation techniques for the entire chip. The vendor documentation shall describe the IC quality. If an ICs is used which is not a standard device, its passivation design shall also be described.

 

Required Test Procedures

• TE05.02.01: The tester shall verify by inspection that the module is a standard, integrated circuit with a uniform, exterior material and standard connectors. The tester shall verify from vendor documentation that the module is at least typical commercial grade in regard to reliability and shock and vibration. This documentation may consist of data sheets, special documentation submitted for this validation effort, comparisons to other physically similar commercial products, etc. If the tester cannot determine the module's quality from the submitted documentation, the vendor shall be required to provide additional information as needed.

 

• TE05.02.02: The tester shall verify from vendor documentation that the module has a standard passivation applied to it. The passivation must be a sealing coat applied over the chip circuitry to protect it against environmental or other physical damage. It is sufficient for the documentation to show that the IC is an industry-standard part from an established manufacturer. If this is not true, the documentation must specify the exact passivation material and technique used; and if it is not a standard passivation, then must also provide information to indicate why it is at least equivalent to a standard passivation approach.

 

AS05.03: For a single-chip cryptographic module at security level 2 or higher, the chip shall be covered with an opaque, tamper-evident coating. (Single-chip; 2, 3, and 4)

(Relevant Guidance:   5.4 , 5.5  )

Required Vendor Information

• VE05.03.01: The module shall be covered with an opaque tamper-evident coating. The coating may be either the passivation material or a material covering the passivation. The material shall be opaque within the visible spectrum. The vendor documentation shall identify the kind of opaque tamper-evident coating and its characteristics.

 

Required Test Procedures

• TE05.03.01: The tester shall verify by inspection and from vendor documentation that the module is covered with an opaque, tamper-evident coating. The inspection shall verify that the tamper-evident coating completely covers the module; is visibly opaque when inspected with bright white light shining on and (if possible) against it; and deters direct observation, probing, or manipulation of the surface features of the chip. The tester shall verify, by scratching the coating with a sharp object, that it leaves marks that make it obvious the module has been tampered with.

 

AS05.04: For a single-chip cryptographic module at security level 3 or higher, a hard, opaque tamper-evident coating shall be used. (Single-chip; 3 and 4)

Required Vendor Information

• VE05.04.01: The module shall be covered with a hard, opaque tamper-evident coating. The coating may be a hard, opaque epoxy covering the passivation, or another type of coating providing an equivalent level of protection. The material shall be opaque within the visible spectrum. The vendor documentation shall identify the kind of hard, opaque, tamper-evident coating used and its characteristics.

 

Required Test Procedures

• TE05.04.01: The tester shall verify by inspection and from vendor documentation that the module is covered with a hard opaque tamper evident coating. The documentation should specify exactly which coating is used; if it is not hard epoxy, then supporting documentation on its hardness should be provided to show that it is roughly equivalent to epoxy. The tester shall verify, by scratching the coating with a sharp object, that it cannot be easily penetrated to the depth of the underlying circuitry, and that it leaves marks that make it obvious the module has been tampered with. The inspection must verify that the coating completely covers the module, is visibly opaque when inspected with bright, white light shining on and (if possible) against it, and deters direct observation, probing, or manipulation of the surface features of the chip. (Portions of this verification may already have been performed at level 2 in TE05.03.01.)

 

AS05.05: For a single-chip cryptographic module at security level 4, a hard, opaque removal-resistant coating shall be used. (Single-chip; 4)

Required Vendor Information

• VE05.05.01: The module shall be covered with a hard, opaque removal-resistant coating. The hardness and adhesion characteristics of the material shall be such that attempting to peel or pry the material from the module will have a high probability of resulting in serious damage to the module (i.e., the module does not function). The solvency characteristics of the material shall be such that dissolving the material to remove it will have a high probability of dissolving or seriously damaging the module. The material shall be opaque within the visible spectrum. The vendor documentation shall identify the kind of coating used and its characteristics.

 

Required Test Procedures

• TE05.05.01: The tester shall verify by inspection and from vendor documentation that the module is covered with a hard, opaque removal-resistant coating. The documentation should specify exactly which coating is used and provide supporting data on its hardness and removal resistance. The tester shall verify, by scratching the coating with a sharp object, that it cannot be easily penetrated to the depth of the underlying circuitry, and [that it leaves marks that make it obvious the module has been tampered with. The inspection must verify that the coating completely covers the module and is visibly opaque when inspected with bright white light shining on and (if possible) against it. (Portions of this verification may already have been performed at level 2 or 3 in TE05.03.01 or TE05.04.01.)
• TE05.05.02: The tester shall verify the removal-resistant properties of the module coating. The tester can obtain the information to perform this verification in one or both of the following two ways:
1. By supervising tests at a vendor facility
2. By performing tests at the tester's own facility
Whichever approach is chosen, the tester shall verify that all of the following tests were performed or reported, to the extent possible:

 

1. The tester (tester or vendor) setup the module in an operational state and verified that it was performing normally.
2. The tester then attempted to peel or pry the material from the module with a sharp object to expose the underlying circuitry, and verified that this was impossible with a reasonable application of force, or that the module ceased to function (e.g., ceased to provide normal output, entered a non-operational state, or provided other clear evidence of failure as appropriate), or that the module circuitry was obviously physically destroyed.
3. The solvency characteristics were tested similarly, using the application of a strong acid (such as buffered hydrofluoric acid or nitric acid) in place of peeling or prying.

AS05.06: For a single-chip cryptographic module at security level 4, the module shall either include environmental failure protection (EFP) features or undergo environmental failure testing (EFT). (Single-chip; 4)

Required Vendor Information

• VE05.06.01: The vendor shall use either of the following:

 

1. EFP features
2. EFT
as specified in section 4.5.4 of FIPS PUB 140-1, to ensure that the following four unusual environmental conditions or fluctuations (accidental or induced) outside of the module's normal operation range will not compromise the security of the module:

 

1. Low temperature
2. High temperature
3. Large negative voltage
4. Large positive voltage
The vendor must choose to use EFP or EFT for each condition, but each choice is independent of the choices for the other conditions. The vendor shall provide corresponding supporting EFP/EFT documentation for each condition, specifying how the selected approach is used.

 

• VE05.06.02: If EFP is chosen for a particular condition, the module shall monitor and correctly respond to fluctuations in the operating temperature or voltage, as appropriate, outside of the module's specified normal operating range for that condition. The protection features shall involve additional electronic circuitry or devices that shall continuously measure these environmental conditions. If a condition is determined to be outside of the module's normal operating range, the protection circuitry shall either:

 

1. Shut down the module
2. Immediately actively zeroize all plaintext cryptographic keys and other unprotected critical security parameters
Documentation shall state which of these approaches was chosen and provide a complete specification and description of the environmental failure protection features employed within the module.
• VE05.06.03: If EFT is chosen for a particular condition, the manufacturer of the module (or an organization designated by the manufacturer/vendor) shall perform required testing, involving a combination of analysis, simulation, and testing of the module as necessary to give a reasonable guarantee that the condition outside the module's normal operating range will not compromise the security of the module. The tests to be performed shall be as specified in section 4.5.4.2 of FIPS PUB 140-1. The manufacturer shall provide documentation that completely specifies the nature of the environmental failure tests performed and the results of those tests.

 

Required Test Procedures

• TE05.06.01: If EFP is chosen for a particular condition, the tester shall determine by test that the requirements are met. The tester can obtain the information to perform this verification in one or both of the following two ways:

 

1. By supervising tests at a vendor facility
2. By performing tests at the tester's own facility
Whichever approach is chosen, the tester shall verify that all of the following tests were performed or reported, to the extent possible:

 

1. The tester (tester or vendor) setup the module in an operational state, brought the environmental condition (either ambient temperature, using an environmental chamber if necessary, or supply voltage) close to the appropriate extreme of the normal operating range specified for the module, and verified that the module was performing normally.
2. The tester then continuously extended the temperature or voltage outside of the specified range, and determined that the module quickly either shut down (e.g., powered down or ceased to provide any output) or else zeroized the keys and other critical security parameters. (Zeroization is defined in TE02.07.02.)
3. The tester noted if any outputs indicated possible security problems with the module (e.g., sensitive data being outputted inappropriately, a failure to report key zeroization when expected, etc.).
4. If the vendor chose to zeroize the module and it was still operational after returning to the normal environmental range, the tester attempted to perform normal operations that required keys and verified that the module no longer performed these functions.
• TE05.06.02: If EFT is chosen for a particular condition, the tester shall review the test reports provided by the vendor to determine that the requirements are met. The tester shall verify that the vendor test report included approximately the following types of test, to the extent possible:

 

1. The tester set up the module in an operational state, brought the environmental condition (ambient temperature, using an environmental chamber if necessary, or supply voltage) close to the appropriate extreme of the normal operating range specified for the module, and verified that the module was performing normally.
2. The tester then continuously extended the temperature or voltage outside of the specified operating range, ultimately to the limits required in FIPS PUB 140-030-1 (for temperature, - 100° C or + 200° C; for voltage, until the module showed evidence of circuit destruction). Evidence of circuit breakdown could include the failure of output lines to provide expected data, a loss of power on interfaces, etc.
3. The tester noted if any outputs indicated possible security problems with the module, in particular keys or sensitive data being outputted inappropriately, but also inappropriate status reports such as a failure to report key zeroization when expected, etc. If suspicious activity was noted, the tester analyzed the information to determine if, in fact, there was a compromise of security functions. To the extent practical, all critical output lines that might reasonably be expected to malfunction under abnormal conditions were monitored for possible evidence of security compromise.

AS05.07: For a multiple-chip, embedded cryptographic module at security level 1 or higher, the chips in the module shall be of production quality that shall include standard passivation techniques. (Multiple-chip embedded; 1, 2, 3, and 4)

Required Vendor Information

• VE05.07.01: The chips in the multiple-chip embedded module shall be standard production-quality ICs, designed to meet at least typical, commercial-grade specifications for power, temperature, reliability, shock/vibration, etc. In particular, the module shall use standard passivation techniques for the each chip. The vendor documentation shall describe the IC's quality. If any ICs are used which are not standard devices, their passivation design shall also be described.

 

Required Test Procedures

• TE05.07.01: The tester shall verify by inspection, or from vendor documentation, that the module contains standard integrated circuits with a uniform exterior material and standard connectors. The tester shall verify from vendor documentation that the chips in the module are at least typical commercial grade in regards to power and voltage ranges, temperature, reliability, and shock and vibration. This documentation may consist of data sheets, special documentation submitted for this validation effort, comparisons to other physically similar products, etc. If the tester cannot determine the chip's quality from the submitted documentation, the vendor shall be required to provide additional information as needed.

 

• TE05.07.02: The tester shall verify from vendor documentation that the chips in the module have a standard passivation applied to them. The passivation must be a sealing coat applied over the chip circuitry to protect it against environmental or other physical damage. It is sufficient for the documentation to show that chips are industry-standard parts from established manufacturers. If this is not true, the documentation must specify the exact passivation material and technique used; and if it is not a standard passivation, then must also provide information to indicate why it is at least equivalent to a standard passivation approach.

 

AS05.08: For a multiple-chip, embedded cryptographic module at security level 1 or higher, the module shall be implemented as a production-grade multiple-chip embodiment. (Multiple-chip embedded; 1, 2, 3, and 4)

Required Vendor Information

• VE05.08.01: The module shall be implemented as a typical production-grade, multiple-chip device, such as an IC printed circuit board or ICs on a ceramic substrate. The vendor documentation shall describe the production implementation of the module.

 

Required Test Procedures

• TE05.08.01: The tester shall verify by inspection and from vendor documentation that the module has been implemented as a standard multiple-chip design, such as a circuit board, a multi-chip ceramic-substrate module, or a functionally-equivalent multi-chip design. The vendor must either specify a typical industry-standard design approach that was used; or if a unique approach is used, the vendor must provide design-and-test-data that shows that the module is equivalent in quality and function to a more traditional approach.

 

AS05.09: For a multiple-chip, embedded cryptographic module at security level 2 or higher, the module shall be encapsulated with an opaque, tamper-evident material. (Multiple-chip embedded; 2, 3, and 4)

(Relevant Guidance:   5.1 , 5.2 , 5.3 , 5.4, 5.5  )

Required Vendor Information

• VE05.09.01: The module shall be encapsulated with an opaque, tamper-evident coating such as conformal coating or bleeding paint. The material shall be opaque within the visible spectrum. The vendor documentation shall identify the kind of opaque tamper-evident coating and its characteristics.

 

Required Test Procedures

• TE05.09.01: The tester shall verify by inspection and from vendor documentation that the module is encapsulated with an opaque, tamper-evident material. The inspection shall verify that the tamper-evident material completely covers the module and is visibly opaque when inspected with bright white light shining on and (if possible) against it; furthermore, by scratching the tamper-resistant material with a sharp object, thereby producing marks, the tester shall verify that the module provides evidence of attempts to tamper with or remove module components.

 

AS05.10: For a multiple-chip, embedded cryptographic module at security level 3 or higher, one of the following three requirements shall apply to the module: (Multiple-chip embedded; 3 or 4)

• A hard opaque potting material shall be used.
• The module shall be contained within a strong non-removable enclosure.
• The module shall be enclosed within a strong removable cover and shall include tamper response and zeroization circuitry.

Required Vendor Information

• VE05.10.01: The vendor documentation shall state which of the three approaches specified in AS05.10 are used to meet the requirement, and provide supporting detailed design information. Depending on this choice, the corresponding vendor requirement (one of the following, respectively) must be met:

 

1. The multi-chip circuitry of the module shall be completely covered with a hard, opaque potting material. The potting material may be a hard, opaque epoxy, or another type of material providing an equivalent level of protection. The material shall be opaque within the visible spectrum.
2. The module shall be entirely contained within a strong nonremovable enclosure. The enclosure shall be designed such that attempts to remove or penetrate it will have a high probability of causing serious damage to the module (i.e., the module does not function).
3. The module shall be entirely enclosed within a strong removable cover and shall include tamper response and zeroization circuitry. The circuitry shall continuously monitor the cover, and upon the removal of the cover, shall immediately actively zeroize all plaintext cryptographic keys and other unprotected critical security parameters. The circuitry shall be operational whenever plaintext cryptographic keys, or other unprotected critical security parameters, are contained within the module.

Required Test Procedures

• TE05.10.01: The tester shall verify that the vendor documentation specifies which requirements option in VE05.10.01 is to be met, and provides any necessary supporting documentation with details of the design approach. If this is not true, the tester shall obtain the necessary information from the vendor before proceeding with the validation. Depending on the requirement option chosen by the vendor, one of the following three tester requirements (TE05.10.02 through TE05.10.04) shall also be verified.

 

• TE05.10.02: Option 1: Utilize a hard, opaque potting material. The tester shall verify by inspection and from vendor documentation that the module is covered with a hard opaque potting material. The documentation should specify exactly which potting material is used; if it is not hard epoxy, then supporting documentation should be provided to show that its hardness is roughly equivalent to epoxy. The tester shall verify, by scratching the potting material with a sharp object, that it can not be easily penetrated to the depth of the underlying circuitry. The tester must verify that the potting material completely covers the module and is visibly opaque when inspected with bright white light shining on and (if possible) against it. (Portions of this verification may already have been performed at level 2 in TE05.09.01.)

 

• TE05.10.03: Option 2: Utilize a strong, nonremovable enclosure. The tester shall verify the strength and nonremovable properties of the module enclosure by inspection and from vendor documentation. The tester shall also determine by test that this requirement is met. This can be verified in one or both of the following two ways:

 

1. By supervising tests at a vendor facility
2. By performing tests at the tester's own facility
Whichever approach is chosen, the tester shall verify that all of the following tests were performed or reported, to the extent possible: The tester (tester or vendor) set up the module in an operational state, and verified that it is performing normally. The tester then attempted to pry the enclosure from the module with a sharp object and to damage it via the manual application of force with a sharp object, to expose the underlying circuitry. The tester verified that this is impossible with a reasonable application of force, or that the module ceased to function (e.g., ceased to provide normal output, entered a non-operational state, or provided other clear evidence of failure as appropriate), or that the module circuitry was obviously physically destroyed.

 

• TE05.10.04: Option 3: Utilize a strong removable cover with tamper response/zeroization. The tester shall verify from vendor design data that the module includes arrangements to zeroize all critical security parameters described in VE05.10.01 when the cover is removed, for example using tamper switches, motion detectors, etc. (Zeroization is defined in TE02.07.02.) The tester shall determine the strength of the cover by attempting to damage it via the manual application of force with a sharp object and verifying that the cover is not easily breached. The tester shall then set up the module in an operational state that requires intact crypto-variables and verify that it is performing normally. The tester shall remove the cover and verify that the module immediately ceases to function (e.g., ceases to provide normal output, enters a non-operational state, or provides other clear evidence of operational failure as appropriate). The tester shall then replace the cover, obtain a status report if the module has that capability, and determine that the module no longer contains critical security material and does not function until reset or rekeyed.

 If the module can retain critical security parameters while powered down or deactivated, the tester shall verify that a deactivated module is tamper-protected: The tester shall load critical security parameters, deactivate the module, and remove a cover. The tester shall then replace the cover, reactivate the module if possible, and determine that it no longer contains critical security material. The tester shall also verify from vendor documentation that the module would retain power to zeroize after deactivation for the maximum time commensurate with its operational use.

 

AS05.11: For a multiple-chip embedded cryptographic module at security level 3 or higher, if the module has any ventilation openings, they shall be constructed to prevent undetected probing. (Multiple-chip embedded; 3 or 4)

Required Vendor Information

• VE05.11.01: If the module is contained within a cover or enclosure and if the cover or enclosure contains any ventilation holes or slits, then they shall be small and constructed in a manner that prevents undetected physical probing inside the enclosure. The vendor documentation shall describe the ventilation physical design approach.

 

Required Test Procedures

• TE05.11.01: The tester shall verify by inspection and from vendor documentation whether the module has a cover or enclosure with ventilation holes, slits, or other openings, and if so, whether they are constructed to deter undetected probing inside the cover/enclosure. Any openings must be small (normally no more than about 1/16" wide at any point) and designed to make direct linear access to the interior impossible. Suitable mechanical design approaches could include placing at least one 90 degree bend in each ventilation path, placing a substantial blocking material slightly behind the opening, use of a strong mesh or grille behind the opening, or similar blocking techniques. Ventilation openings and any blocking material must either be strong enough to resist attempts to force access to the interior, or be constructed such that forced access would require obvious damage visible from the exterior.

 

AS05.12: For a multiple-chip, embedded cryptographic module at security level 4, the module shall be contained within a tamper detection envelope. (Multiple-chip embedded; 4)

(Relevant Guidance:  5.8  )

Required Vendor Information

• VE05.12.01: The contents of the module shall be completely contained within a tamper detection envelope that will detect tampering attacks against the potting material or cover. The vendor documentation shall describe the tamper detection envelope design.

 

Required Test Procedures

• TE05.12.01: The tester shall verify from vendor design data and by inspection that the module contains a tamper detection envelope that forms a barrier completely surrounding the module components. This barrier must be designed such that any breach of it by means such as drilling, milling, grinding, or dissolving to access the module components inside can be detected by monitoring components in the module. Suitable tamper-detection envelope design techniques could include use of a flexible mylar printed circuit with a serpentine geometric pattern of conductors, a wire-wound package, a nonflexible brittle circuit, or equivalent techniques, any of which would cause a detectable change (e.g., an open circuit) upon breaching. (TE05.13.01 contains related requirements for tamper response.)

 

AS05.13: For a multiple-chip, embedded cryptographic module at security level 4, the module shall contain tamper response and zeroization circuitry. (Multiple-chip embedded; 4)

Required Vendor Information

• VE05.13.01: The module shall contain tamper response and zeroization circuitry that continuously monitors the tamper detection envelope for tampering, and upon the detection of tampering, shall immediately actively zeroize all plaintext cryptographic keys and other unprotected critical security parameters. The circuitry shall be operational whenever plaintext cryptographic keys, or other unprotected critical security parameters, are contained within the module. The vendor documentation shall describe the tamper response and zeroization design.

 

Required Test Procedures

• TE05.13.01: The tester shall verify from vendor design data that the module contains tamper response and zeroization circuitry that must continuously monitor the tamper detection envelope (refer to TE05.12.01); detect any breaches by means such as drilling, milling, grinding or dissolving any portion of the envelope; and then immediately zeroize all critical security parameters described in VE05.13.01. (Zeroization is defined in TE02.07.02.) The tester shall also determine by test that this requirement is met. This can be verified in one or both of the following two ways:
1. By supervising tests at a vendor facility
2. By performing tests at the tester's own facility.
Whichever approach is chosen, the tester shall verify that all of the following tests were performed or reported, to the extent possible:
1. The tester (tester or vendor) set up the module in an operational state that required intact crypto-variables and verified that it was performing normally.
2. The tester then breached the tamper-detection envelope barrier by any convenient means, and verified that the module immediately ceased to function (e.g., ceased to provide normal output, entered a non-operational state, or provided other clear evidence of operational failure as appropriate).
3. The tester also noted if the module reported a key zeroization or other failure at this point (if it has that capability).
4. If the module can retain critical security parameters while deactivated: the tester loaded critical security parameters, deactivated the module, breached the tamper-detection envelope, reactivated the module if possible, and determined that it no longer contained critical security material. The tester also verified from vendor documentation that the module would retain power to zeroize after deactivatation for the maximum time commensurate with its operational use.

AS05.14: For a multiple-chip, embedded cryptographic module at security level 4, the module shall either include environmental failure protection (EFP) features or undergo environmental failure testing (EFT). (Multiple-chip embedded; 4)

Required Vendor Information

• VE05.14.01: (This requirement is identical to VE05.06.01.)

 

• VE05.14.02: (This requirement is identical to VE05.06.02.)

 

• VE05.14.03: (This requirement is identical to VE05.06.03.)

 

Required Test Procedures

• TE05.14.01: (This requirement is identical to TE05.06.01.)

 

• TE05.14.02: (This requirement is identical to TE05.06.02.)

 

AS05.15: For a multiple-chip, stand-alone cryptographic module at security level 1 or higher, the chips in the module shall be of production quality that shall include standard passivation techniques. (Multiple-chip stand-alone; 1, 2, 3, and 4)

Required Vendor Information

• VE05.15.01: The chips in the multiple-chip, stand-alone module shall be standard production quality ICs, designed to meet at least typical commercial-grade specifications for power, temperature, reliability, shock/vibration, etc. In particular, the module shall use standard passivation techniques for the each chip. The vendor documentation shall describe the IC's quality. If any ICs are used which are not standard devices, their passivation design shall also be described.

 

Required Test Procedures

• TE05.15.01: The tester shall verify by inspection or from vendor documentation that the module contains standard integrated circuits with a uniform exterior material and standard connectors. The tester shall verify from vendor documentation that the chips in the module are at least typical commercial grade in regards to power and voltage ranges, temperature, reliability, and shock and vibration. This documentation may consist of data sheets, special documentation submitted for this validation effort, comparisons to other physically similar products, etc. If the tester can not determine the chip's quality from the submitted documentation, the vendor shall be required to provide additional information as needed.

 

• TE05.15.02: The tester shall verify from vendor documentation that the chips in the module have a standard passivation applied to them. The passivation must be a sealing coat applied over the chip circuitry to protect it against environmental or other physical damage. It is sufficient for the documentation to show that chips are industry-standard parts from established manufacturers. If this is not true, the documentation must specify the exact passivation material and technique used; and if it is not a standard passivation, then must also provide information to indicate why it is at least equivalent to a standard passivation approach.

 

AS05.16: For a multiple-chip, standalone cryptographic module at security level 1 or higher, the circuitry within the module shall be implemented as a production-grade, multiple-chip embodiment. (Multiple-chip standalone; 1, 2, 3, and 4)

Required Vendor Information

• VE05.16.01: The circuitry in the module shall be implemented as a typical production-grade, multiple-chip device, such as an IC printed circuit board or ICs on a ceramic substrate. The vendor documentation shall describe the production implementation of the module.

 

Required Test Procedures

• TE05.16.01: The tester shall verify by inspection and from vendor documentation that the module has been implemented as a standard multiple-chip design, such as a circuit board, a multi-chip ceramic-substrate module, or a functionally-equivalent, multi-chip design. The vendor must either specify a typical, industry-standard design approach that was used; or if a unique approach is used, the vendor must provide design-and-test-data that shows that the module is equivalent in quality and function to a more traditional approach.

 

AS05.17: For a multiple-chip, standalone cryptographic module, at security level 1 or higher, the module shall be contained within an enclosure that may include removable covers or doors. (Multiple-chip standalone; 1, 2, 3, and 4)

Required Vendor Information

• VE05.17.01: The module shall be entirely contained within a metal or hard plastic production-grade enclosure that may include removable covers or doors. The vendor documentation shall describe the enclosure and its hardness characteristics.

 

Required Test Procedures

• TE05.17.01: The tester shall verify by observation and from vendor documentation that the module is contained within an enclosure that meets the following requirements:

 

1. The enclosure must completely surround and protect the entire module.
2. The enclosure material must be metal or hard plastic of a composition defined in the vendor documentation.
3. The enclosure must be production grade. The vendor literature must either show that an enclosure of the same material has been used commercially, or provide data to show that it has properties adequate for the application or equivalent to a commercial product.
4. The enclosure may have removable covers or doors. At security level 1, there are no protection requirements for these covers or doors, but the tester shall verify that they are at least firmly attached and closed under normal use.

AS05.18: For a multiple-chip, standalone cryptographic module at security level 2 or higher, the enclosure shall be opaque. (Multiple-chip standalone; 2, 3, and 4)

Required Vendor Information

• VE05.18.01: The enclosure shall be opaque within the visible spectrum. The vendor documentation shall describe the enclosure's opacity characteristics.

 

Required Test Procedures

• TE05.18.01: The tester shall verify by inspection that the enclosure is visibly opaque when inspected with bright white light shining on and (if possible) against it.

 

AS05.19: For a multiple-chip, standalone cryptographic module at security level 2 or higher, if the enclosure includes any removable covers or doors, then either they shall be locked with pick-resistant mechanical locks or they shall be protected via tamper-evident seals. (Multiple-chip standalone; 2, 3, and 4)

(Relevant Guidance:   5.2 , 5.4 , 5.5  )

Required Vendor Information

• VE05.19.01: If the enclosure includes any removable covers or doors, then either they shall be locked with pick-resistant mechanical locks that employ physical or logical keys; or they shall be protected via tamper-evident seals such as evidence tape or holographic seals. The vendor documentation shall describe the chosen tamper-protection approach.

 

Required Test Procedures

• TE05.19.01: The tester shall determine whether the enclosure contains any removable covers or doors. If so, the tester shall verify that each cover and door meets at least one of the two requirements below:

 

1. The cover or door is locked with a pick-resistant lock that requires a physical key or a logical key to unlock it. (For example, a logical key could be a number that must be entered at a keypad.) The tester shall attempt to open the locked cover or door without use of the key (including attempts to physically pry it open with an object such as a screwdriver) and determine that the door will not open without signs of damage being evident.
2. The cover or door is protected with a seal such as evidence tape or a holographic seal. The tester shall verify that the cover or door cannot be opened without breaking or removing the seal, and that the seal cannot be removed and later replaced without leaving detectable signs.

AS05.20: For a multiple-chip, standalone cryptographic module at security level 3 or higher, one of the following two requirements shall apply to the module: (Multiple-chip standalone; 3 or 4)

• The module shall be encapsulated within a hard opaque potting material.
• The module shall be contained within a strong enclosure that either has no removable elements or contains tamper response and zeroization circuitry.

Required Vendor Information

• VE05.20.01: The vendor documentation shall state which of the two approaches specified in AS05.20 are used to meet the requirement, and provide supporting detailed design information. Depending on this choice, the corresponding vendor requirement (one of the following, respectively) must be met:

 

1. The multi-chip embodiment of the circuitry within the module shall be completely encapsulated within a hard, opaque potting material. The potting material may be a hard, opaque epoxy, or another type of material providing an equivalent level of protection. The material shall be opaque within the visible spectrum.
2. The module shall be entirely contained within a strong enclosure. The enclosure shall be designed such that attempts to remove it will have a high probability of causing serious damage to the circuitry within the module (i.e., the module does not function). If the enclosure contains any removable covers or doors, then the module shall contain tamper response and zeroization circuitry. The circuitry shall continuously monitor the covers and doors, and upon the removal of a cover or the opening of a door, shall immediately actively zeroize all plaintext cryptographic keys and other unprotected critical security parameters. The circuitry shall be operational whenever plaintext cryptographic keys, or other unprotected critical security parameters, are contained within the module.

Required Test Procedures

• TE05.20.01: The tester shall verify that the vendor documentation specifies which requirements option in VE05.20.01 is to be met and provides any necessary supporting documentation with details of the design approach. If this is not true, the tester shall obtain the necessary information from the vendor before proceeding with the validation. Depending on the requirement option chosen by the vendor, one or two of the following three tester requirements shall also be verified: TE05.20.02 if option 1 is chosen, or else TE05.20.03 plus possibly TE05.20.04 if option 2 is chosen.

 

• TE05.20.02: Option 1: Utilize a hard, opaque potting material. The tester shall verify from vendor documentation and by inspection if internal access is possible (for example via a removable cover or door), that the circuitry within the module is encapsulated within a hard, opaque potting material. The documentation should specify exactly which potting material is used; if it is not hard epoxy, then supporting documentation should be provided to show that its hardness is roughly equivalent to epoxy. If access is possible, the tester shall verify, by scratching the potting material with a sharp object, that it cannot be easily penetrated to the depth of the underlying circuitry. If access is possible, the tester shall also verify that the potting material completely encapsulates the circuitry within the module and is visibly opaque when inspected with bright white light shining on and (if possible) against it.

 

• TE05.20.03: Option 2: Utilize a strong enclosure. The tester shall determine the strength of the enclosure by attempting to damage it via the manual application of force with a sharp object and verifying that the cover is not easily breached. The tester shall verify by inspection and from vendor documentation that the enclosure cannot be removed (except for removable covers or doors that are covered in TE05.20.04.) The tester shall also determine by test that this requirement is met. This can be verified in one or both of the following two ways:

 

1. By supervising tests at a vendor facility
2. By performing tests at the tester's own facility
Whichever approach is chosen, the tester shall verify that all of the following tests were performed or reported, to the extent possible: The tester (tester or vendor) set up the module in an operational state and verified that it was performing normally. Then the tester attempted to pry the enclosure from the module with a sharp object to expose the underlying circuitry. The tester verified that this was impossible with a reasonable application of force or that the module ceased to function (e.g., ceased to provide normal output, entered a non-operational state, or provided other clear evidence of failure as appropriate), or that the module circuitry was obviously physically destroyed.

 

• TE05.20.04: If a strong enclosure is used (option 2), and it has removable covers or doors: The tester shall verify from vendor design data that the module includes arrangements to zeroize all critical security parameters described in VE05.20.01 when a cover or door is removed (for example using tamper switches, motion detectors, etc.) (Zeroization is defined in TE02.07.02.) The tester shall also set up the module in an operational state that requires intact crypto-variables, and verify that it is performing normally. The tester shall remove a cover or door and verify that the module immediately ceases to function (e.g., ceases to provide normal output, enters a non-operational state, or provides other clear evidence of operational failure as appropriate). The tester shall then replace the cover or door, obtain a status report if the module has that capability, determine that the module no longer contains critical security material, and does not function until reset or rekeyed.

 If the module can retain critical security parameters while powered down or deactivated, the tester shall verify that a deactivated module is tamper-protected: The tester shall load critical security parameters, deactivate the module, and remove a cover. The tester shall then replace the cover, reactivate the module if possible, and determine that it no longer contains critical security material. The tester shall also verify from vendor documentation that the module would retain power to zeroize after deactivation for the maximum time commensurate with its operational use.

 

AS05.21: For a multiple-chip, standalone cryptographic module at security level 3 or higher, if the module has any ventilation openings, they shall be constructed to prevent undetected probing. (Multiple-chip, standalone; 3 or 4)

Required Vendor Information

• VE05.21.01: If the enclosure contains any ventilation holes or slits, they shall be small and constructed in a manner that prevents undetected physical probing inside the enclosure. The vendor documentation shall describe the ventilation physical design approach.

 

Required Test Procedures

• TE05.21.01: The tester shall verify, by inspection and from vendor documentation, whether the module has ventilation holes, slits, or other openings, and if so, whether they are constructed to deter undetected probing inside the cover/enclosure. Any openings must be small (normally no more than about 1/16" wide at any point) and designed to make direct linear access to the interior impossible. Suitable mechanical design approaches could include placing at least one 90 degree bend in each ventilation path, placing a substantial blocking material slightly behind the opening, use of a strong mesh or grille behind the opening, or similar blocking techniques. Ventilation openings and any blocking material must either be strong enough to resist attempts to force access to the interior, or be constructed such that forced access would require obvious damage visible from the exterior.

AS05.22: For a multiple-chip standalone cryptographic module at security level 4, the module shall provide a tamper-detection envelope. (Multiple-chip standalone; 4)

(Relevant Guidance:  5.8  )

Required Vendor Information

• VE05.22.01: The enclosure shall contain tamper detection mechanisms that provide a tamper-detection envelope, such as cover switches, motion detectors, or other tamper detection mechanisms which will detect tampering attacks against the potting material or cover. The vendor documentation shall describe the tamper detection envelope design.

 

Required Test Procedures

• TE05.22.01: The tester shall verify from vendor design data and by inspection that the module enclosure contains tamper detection mechanisms, which must form a tamper-detection envelope completely protecting the module components. The mechanisms must be designed such that any breach of the enclosure, potting material, or cover by means such as drilling, milling, grinding or dissolving to access the module components inside can be detected by monitoring components in the module. Suitable tamper-detection envelope design techniques could include use of cover switches (e.g., micro-switches, magnetic Hall effect switches, permanent magnetic actuators, etc.), motion detectors (e.g., ultrasonic, infrared, or microwave), or other tamper detection mechanisms as described in TE05.12.01 (such as a flexible mylar printed circuit with a serpentine geometric pattern of conductors, a wire-wound package, a non-flexible brittle circuit, or equivalent techniques). Any of these techniques should cause a detectable change (e.g., an open circuit) when the tamper detection envelope is breached. (TE05.23.01 contains related requirements for tamper response.)

AS05.23: For a multiple-chip standalone, cryptographic module at security level 4, the module shall contain tamper response and zeroization circuitry. (Multiple-chip standalone; 4)

Required Vendor Information

• VE05.23.01: The module shall contain tamper response and zeroization circuitry that continuously monitors the tamper detection envelope for tampering; and upon the detection of tampering, shall immediately actively zeroize all plaintext cryptographic keys, and other unprotected critical security parameters. The circuitry shall be operational whenever plaintext cryptographic keys, or other unprotected critical security parameters are contained within the module. The vendor documention shall describe the tamper response and zeroization design.

 

Required Test Procedures

• TE05.23.01: The tester shall verify from vendor design data that the module contains tamper response and zeroization circuitry that must continuously monitor the tamper detection mechanisms (refer to TE05.22.01); detect any breaches by means such as drilling, milling, grinding or dissolving any portion of the enclosure potting material or cover; and then immediately zeroize all critical security parameters described in VE05.23.01. (Zeroization is defined in TE02.07.02.) The tester shall also determine by test that this requirement is met. This can be verified in one or both of the following two ways:

 

1. By supervising tests at a vendor facility
2. By performing tests at the tester's own facility.
Whichever approach is chosen, the tester shall verify that all of the following tests were performed or reported, to the extent possible:

 

1. The tester (tester or vendor) set up the module in an operational state that required intact crypto-variables and verified that it was performing normally.
2. The tester then breached the enclosure by any convenient means and verified that the module immediately ceased to function (e.g., ceased to provide normal output, entered a non-operational state, or provided other clear evidence of operational failure as appropriate).
3. The tester also noted if the module reported a key zeroization or other failure at this point (if it has that capability).
4. If the module can retain critical security parameters while deactivated: the tester loaded critical security parameters, deactivated the module, breached the tamper-detection envelope, reactivated the module if possible, and determined that it no longer contained critical security material. The tester also verified from vendor documentation that the module would retain power to zeroize after deactivatation for the maximum time commensurate with its operational use.

AS05.24: For a multiple-chip standalone cryptographic module at security level 4, the module shall either include environmental failure protection (EFP) features or undergo environmental failure testing (EFT) as specified in section 4.5.4 of FIPS PUB 140-1. (Multiple-chip standalone; 4)

Required Vendor Information

• VE05.24.01: (This requirement is identical to VE05.06.01.)

 

• VE05.24.02: (This requirement is identical to VE05.06.02.)

 

• VE05.24.03: (This requirement is identical to VE05.06.03.)

 

Required Test Procedures

• TE05.24.01: (This requirement is identical to TE05.06.01.)

 

• TE05.24.02: (This requirement is identical to TE05.06.02.)

 

6. SOFTWARE SECURITY

 These requirements do not apply to microcode or system software whose source code is not available to the module manufacturer. These requirements do not apply to any software or firmware that can be shown not to affect the security of the module.

AS06.01: Documentation shall identify any software or firmware that is excluded from the software security requirements and explain the rationale for the exclusion. (1, 2, 3, and 4)

(Relevant Implementation Guidance:  1.4 , )

Required Vendor Information

• VE06.01.01: The vendor documentation requirement to satisfy this assertion is the same as VE01.06.01 and VE01.06.02 of this document.

 

Required Test Procedures

• TE06.01.01: This requirement is tested under TE01.06.01 and TE01.06.02 of this document.

 

AS06.02: Documentation shall include a detailed description of the design of the software within the module (e.g., the finite state machine specification required in Section 4.4 of FIPS PUB 140-1). (1, 2, 3, and 4)

Required Vendor Information

• VE06.02.01: The vendor shall provide detailed software design documentation. This documentation shall include, but in no way be limited to, the finite state machine model diagram(s) and description referred to in Section 4.4 of FIPS PUB 140-1. If the relationship between the finite state machine specification and the source code is not clear, the vendor shall provide additional documentation that describes the relationship between the finite state machine specification and the source code.

 

Required Test Procedures

• TE06.02.01: The tester shall compare the software design documentation against the list of names of all the software and firmware modules, functions, and procedures (as documented in VE06.04.01) to verify that the relationship between the finite state machine specification and the source code can be determined.

 

AS06.03: Documentation shall include a detailed explanation of the correspondence between the design of the software and the cryptographic module security policy (i.e., the rules of operation as documented per the requirements of Section 4.1 of FIPS PUB 140-1. (1, 2, and 3)

(Relevant Implementation Guidance:  1.5 , )
 

Required Vendor Information

• VE06.03.01: The vendor documentation shall contain a separate section or chapter describing, explicitly, how the software/firmware design corresponds to the security policy (rules of operation) of the cryptographic module.

 

Required Test Procedures

• TE06.03.01: The tester shall review the vendor documentation for completeness and correctness in representing the security policy (rules of operation) of the cryptographic module. He or she must determine that each security rule is reflected in the design, and that the design faithfully implements the semantics of the rule. That is to say, the design shows that the rule will be invoked under those conditions, and only those conditions, expressed in the rule; and that once invoked, the system will correctly execute the rule (e.g., perform the proper check on the correct security attributes of the correct entities).

 

AS06.04: Documentation shall include a complete source code listing for all software contained within the module. (1, 2, 3, and 4)

Required Vendor Information

• VE06.04.01: The vendor shall supply a list of the names of all the software and firmware modules, functions, and procedures contained in the cryptographic module. This list may be a list of entities used in the linking process to create executable program images.

 

• VE06.04.02: The vendor shall supply an annotated source listing of each of the software and firmware modules, functions, and procedures contained in the cryptographic module as indicated in the software/firmware list supplied by the vendor.

 

Required Test Procedures

• TE06.04.01: The tester shall use the list supplied by the vendor to make sure that he or she has a source listing for each software or firmware module, function, and procedure contained in the module. The source listings must contain listings of data structures (e.g., header or include files) as well as source code.

 

AS06.05: For each software module, software function and software procedure, the source code listing shall be annotated with comments that clearly depict the relationship of these software entities to the design of the software. (1, 2, 3, and 4)

Required Vendor Information

• VE06.05.01: The vendor documentation requirement to satisfy this assertion is the same as VE06.04.02 for assertion AS06.04.

 

Required Test Procedures

• TE06.05.01: The tester shall determine that each module, function, or procedure of software and firmware contains comments and that the relationship between the software entities and the design (as documented in VE06.02.01) is clear.

 

• TE06.05.02: The tester shall read the comments of each module, function, and procedure to determine, in the tester's judgment, that they explain the structure and function of the module, function, or procedure. This shall include expected inputs, algorithms used in the module, control flow, and expected outputs from the module, function, or procedure.

 

AS06.06: All software within a cryptographic module shall be implemented using a high-level language, except that the limited use of low-level languages (e.g., assembly languages) is allowed when it is essential to the performance of the module or when a high-level language is not available. (3 and 4)

Required Vendor Information

• VE06.06.01: The vendor shall identify each of the software modules that is not written in a high-level language and provide a rationale or justification for why the module is written in a low-level language. The rationale shall cite either the unavailability of a high-level language or the need for enhanced performance for the software. In the case of a performance rationale, the rationale shall give the technical explanation of why the high-level language does not provide sufficient performance.

 

Required Test Procedures

• TE06.06.01: The tester shall examine the source code for each of the software modules to determine which ones are written in assembler language. He or she must verify that there are no software modules written in assembler language that were not identified by the vendor in VE06.06.01.

 

• TE06.06.02: The tester shall review the vendor-supplied rationale for each software module written in assembler language and make a judgment as to whether the rationale is convincing. If the rationale is not convincing, he or she shall ask the vendor for a more convincing rationale. If the vendor cannot provide a convincing rationale, the vendor must write the subject module in a high-level language.

 

AS06.07: Documentation shall include a specification of a formal model (i.e., a precise mathematical statement) of the cryptographic module security policy (i.e., the security rules under which the module must operate) as documented per the requirements of Section 4.1 of FIPS PUB 140-1. The formal model shall be specified using a formal specification language that is a rigorous notation based on established mathematics, such as first order logic or set theory. (4)

 Note: Examples include, but are not limited to, INAJO, GYPSY, VDM, Z, LOTOS, EHDM, and ESTELLE.

(Relevant Implementation Guidance:  1.5 , )
 

Required Vendor Information

• VE06.07.01: The vendor shall provide documentation of a formal model, specified in a formal specification language, of the security policy of the cryptographic module, as documented in AS01.07. The formal model shall include, at least, a list of elements of the model, the operations performed on these elements, and the security rules these operations must obey.

 

Required Test Procedures

• TE06.07.01: The tester shall analyze the formal model to establish that it has the following properties:

 

1. That the statements of the formal model are written correctly (syntactically correct) in the vendor's chosen formal specification language.
2. That the formal model contains:
1. a definition of a "secure" state (i.e., the security policy),
2. a representation of the initial state of the module,
3. a model of the way in which the module progresses from one state to another (i.e., state transitions), and
4. a formal proof that if the initial state of the module satisfies the definition of a "secure" state and if all assumptions required by the model hold, then all future states of the module will be secure.¹
The definition of the cryptographic module security policy must cover all security-policy requirements given in FIPS PUB 140-1. Validation that the formal model corresponds to the cryptographic module's security policy is covered in assertion AS06.08.

 The state transitions must be compatible with (and could, under some circumstances, coincide with), the finite state machine model required by Section 4.4 of FIPS PUB 140-1.

 If the cryptographic module is sufficiently simple, it may be feasible for the state transitions constraints to coincide with the pre- and post-conditions required as part of the annotated source code. In this case, the required proof of correspondence between the software design and the formal model is directly included in the model itself.

 Validation that the module's software design corresponds to the rules of operation in the formal model is covered in assertion AS06.10.

 In the likely event that a state-machine model is used, the formal proof should establish that the system will (a) always be in a secure state, and (b) that state transitions obey appropriate policy requirements. Item (a) would ordinarily be proved by state induction, by showing that the initial state is secure and that each operation induces a new secure state, if applied in a secure state. Item (b) is proved by case analysis, by showing that each operation satisfies each state-transition constraint given in the policy.

 The primary criteria for judging acceptability of a rigorous proof is its ability to inform and convince its reviewers. Proof modularity is essential both to successful review and to product maintenance. The proof should be constructed hierarchically in terms of lemmas that rest, ultimately, on axioms and commonly accepted facts of mathematics. Additional guidelines on clarity of presentation for security models may be found in Section 2.4 of [NCSC-TG-10].²

 

AS06.08: Documentation shall include a detailed explanation (informal proof) of the correspondence between the formal model and the cryptographic module security policy. (4)

(Relevant Implementation Guidance:  1.5 , )
 

Required Vendor Information

• VE06.08.01: The vendor documentation shall contain a separate section or chapter describing, explicitly, how the formal model corresponds to the security policy (rules of operation) of the cryptographic module.

 

Required Test Procedures

• TE06.08.01: The tester shall review the vendor-supplied documentation (security policy, formal model, and the security-policy-to-formal-model correspondence documentation) for completeness and correctness in representing the security policy of the cryptographic module. He or she must determine that each rule contained in the security policy is reflected in the formal model, and that the formal model faithfully implements the semantics of the rule. That is to say, the formal model shows that the rule will be invoked under those conditions, and only those conditions, under which it is applied in the security policy; and that, once invoked, the formal model shows that it will correctly execute the rule.

 

• Note: The tester must review all three documents identified in TE06.08.01. The security policy and formal model may, in fact, correspond, while the correspondence document is wrong, or either the security policy or formal model may contain more, or less, or something different than the other document.

 

AS06.09: For each software module, software function and software procedure, the source code listing shall be annotated with comments that clearly specify (1) the pre-conditions required upon entry into the module, function or procedure in order for it to execute correctly, and (2) the post-conditions expected to be true when execution of the module, function or procedure is complete. (4)

 Note: These conditions may be specified using any notation that is sufficiently detailed to completely and unambiguously explain the behavior of the module, function or procedure.

 Note: While a mechanically checked proof is not required, it shall be possible to prove from the pre- and post-conditions that a module, function or procedure is consistent with the formal model.

Required Vendor Information

• VE06.09.01: For level 4, the source code listings of all the software modules, functions, or procedures provided by the vendor in AS06.04 shall include, as comments, pre- and post-conditions as required in this assertion (AS06.09).

 

Required Test Procedures

• TE06.09.01: The tester shall verify, by inspection, that each module, function, or procedure contained in the cryptographic module software contains pre- and post-conditions as specified in this assertion (AS06.09).

 

• TE06.09.02: The tester shall examine the source code for each software module, function, and/or procedure contained within the cryptographic module. He or she shall determine, by analyzing the unit's internal logic, that the unit will produce the specified post-condition upon completion of its execution, if the specified pre-condition exists immediately prior to the unit's start of execution. The term "unit" here refers to a software module, function, or procedure.

 

AS06.10: Documentation shall include a detailed explanation (informal proof) of the correspondence between the software design (as reflected by the pre- and post-condition annotations) and the formal model. (4)

Required Vendor Information

• VE06.10.01: The vendor documentation shall contain a separate section or chapter describing, explicitly, how the software design corresponds to the formal model of the cryptographic module. The correspondence shall be a mapping or equivalent from the operations and elements of the model to the software design.

 

Required Test Procedures

• TE06.10.01: The tester shall review the vendor-supplied documentation (formal model, software design, and the formal-model-to-software-design documentation) for completeness and correctness. He or she must determine that each action or transition contained in the formal model is reflected in the design, and that the design faithfully implements the semantics of the action or rule. That is to say that the design shows that the action or transition will be invoked under those conditions, and only those conditions, under which it is invoked in the formal model, and that, once invoked, the system will correctly execute the action or transition, as expressed in the formal model.

 

• Note: The tester must review all three documents identified in TE06.10.01. The formal model and the software design may, in fact, correspond, while the correspondence document is wrong; or either the formal model or the software design may contain more, or less, or something different than the other document.

 

7. OPERATING SYSTEM SECURITY

 An example of a cryptographic module for which the operating system requirements apply is a cryptographic module which is a general purpose computer running cryptographic software as well as untrusted user-supplied software (e.g., a spreadsheet or word processing program). In this case, the hardware, operating system and cryptographic software are considered part of the cryptographic module, and hence, the operating system requirements apply.

AS07.01: All cryptographic software shall be installed only as executable code in order to discourage scrutiny and modification by users. (1, 2, 3, and 4)

Required Test Procedures

• TE07.01.01: The tester shall check all the files stored on secondary storage and determine that there are no source code files for software modules, functions, or procedures contained on the secondary storage. This review shall involve some scrutiny of the contents of each file, since a source file could have any name.

 

AS07.02: A cryptographic mechanism using a FIPS approved authentication technique (e.g., the computation and verification of a data authentication code or NIST digital signature algorithm) shall be applied to the cryptographic software within the cryptographic module. This cryptographic mechanism requirement may be incorporated as part of Software/Firmware test if a FIPS approved authentication technique is employed for that test. (1, 2, 3, and 4)

(Relevant Guidance:  7.1 , )

Required Vendor Information

• VE07.02.01: The vendor shall provide documentation that identifies the technique used to maintain the integrity of the cryptographic software and describe how the software integrity is verified.

 

Required Test Procedures

• TE07.02.01: The tester shall review the documentation to determine that it is complete, correct, and of sufficient detail to allow the tester to understand the cryptographic mechanism.

 

• TE07.02.02: The tester shall attempt to corrupt the cryptographic executable code in various ways in order to test the effectiveness of the implementation of the integrity-maintaining mechanism.

 

AS07.03: Use of the cryptographic module shall be limited to a single user at a time. (1)

 Note: This requirement cannot be enforced by administrative documentation and procedures, but must be enforced by the cryptographic module itself.

Required Vendor Information

• VE07.03.01: The vendor shall provide a description of the mechanism used to ensure that only one user at a time can use the module. Mechanisms to provide this enforcement include, but are not limited to, having only one terminal hooked up to the cryptographic module and only one user logged on at a time.

 

Required Test Procedures

• TE07.03.01: The tester shall operate the cryptographic module in the manner described by the vendor in the operation's manual. While the module is in correct operation, the same or another tester shall attempt to use the module, circumventing the single-user enforcement mechanism.

 

AS07.04: Use of the cryptographic module shall be dedicated to the cryptographic process during the time the cryptographic process is in use. (1)

 Note: This requirement cannot be enforced by administrative documentation and procedures, but must be enforced by the cryptographic module itself.

Required Vendor Information

• VE07.04.01: The vendor shall provide a description of the mechanism used to ensure that no other process can be executed in the cryptographic module while the cryptographic process is in use.

 

Required Test Procedures

• TE07.04.01: The tester shall perform cryptographic functions in the manner described by the vendor in the operation's manual. While the cryptographic functions are operating correctly, the same or another tester shall attempt to execute another process while the cryptographic process is in use. Examples of how the other executable software is made unrunnable during the performance of cryptographic functions are as follows:

 

1. That the cryptographic module can only execute one program at a time and, therefore, cannot execute other software while the cryptographic software is running. (It should not be possible to interrupt the cryptographic process, run it in the background, and start another process before the cryptographic process is complete.)
2. That the cryptographic software is invoked through a menu interface that prevents the operator from invoking other software while the cryptographic software is running.

AS07.05: All cryptographic software, cryptographic keys and other critical security parameters, and control and status information shall be under the control of an operating system that provides controlled access protection (i.e., C2 protection in accordance with the Trusted Computer System Evaluation Criteria (TCSEC) or FIPS approved equivalent). Only operating systems that have been evaluated by a NIST accredited evaluation authority and against a FIPS approved criteria shall be used. (2)

 Note: The discretionary access control mechanisms provided by a C2 or equivalent operating system shall be employed to protect all plaintext data, cryptographic software, cryptographic keys, authentication data, and other critical security parameters from unauthorized access, per the following requirements:

(Relevant Guidance:  7.2 , )

Required Vendor Information

• VE07.05.01: The vendor shall provide proof that the operating system controlling the cryptographic module has successfully passed evaluation for "controlled access protection" (C2 in the TCSEC or FIPS-approved equivalent) by a NIST-accredited evaluation authority and against a FIPS-approved criteria. Two ways a vendor may provide this proof are 1) to present the tester with a certificate from a NIST-accredited evaluation authority certifying that the operating system successfully passed an evaluation, or 2) to show that the operating system is listed on a FIPS-approved evaluated products list or equivalent as having passed an evaluation.

 

Required Test Procedures

• TE07.05.01: The tester shall check that the evaluation authority identified in the proof evidence is a NIST-accredited evaluation authority. This may be accomplished by referring to NIST-supplied list of accredited evaluation authorities to see if the evaluation authority identified in the proof evidence is on that list.

 

• TE07.05.02: The tester shall check that this operating system was, in fact, evaluated by this evaluation authority and that the evaluation authority used a FIPS-approved criteria in performing the evaluation.

 

AS07.06: The operating system shall provide the capability to specify a set of operators who can execute cryptographic program images contained on the cryptographic module's secondary storage. (2, 3, and 4)

Required Vendor Information

• VE07.06.01: The vendor shall include in the installation procedures specific instructions on how, by employing the protection mechanisms provided by a controlled access operating system, one can configure the cryptographic module to protect it from unauthorized execution of cryptographic program images contained on the module's secondary storage.

 

Required Test Procedures

• TE07.06.01: The tester shall review the installation procedures provided by the vendor, and examine the actual configuration of the cryptographic module, to verify that the cryptographic module is indeed configured in accordance with these vendor's instructions to protect the cryptographic program images contained on the module's secondary storage from unauthorized execution.

 

• TE07.06.02: The tester shall become an operator in the set who can execute the various types of cryptographic program images. He or she must verify that he or she can, in fact, execute them.

 

• TE07.06.03: The tester shall become an operator who is not in the set who can execute the various types of cryptographic program images. He or she must verify that he or she can not, in fact, execute them.

 

AS07.07: The operating system shall provide the capability to specify a separate set of operators for each of the following cryptographic module software components, such that only elements within that component's set can modify (i.e., write, replace, delete) entities within that component: (2, 3, and 4)

• cryptographic program images on secondary storage
• cryptographic data (e.g. cryptographic keys, audit data) stored on secondary storage
• cryptographic data (e.g. cryptographic keys, audit data) stored in computer memory
• other critical security parameters stored on secondary storage
• other critical security parameters contained in computer memory.

Required Vendor Information

• VE07.07.01: The vendor shall include in the installation procedures specific instructions on how, by employing the protection mechanisms provided by a controlled access operating system, one can configure the cryptographic module software components to protect them from unauthorized modification.

 

Required Test Procedures

• TE07.07.01: The tester shall review the installation procedures provided by the vendor, and examine the actual configuration of the cryptographic module, to verify that the cryptographic module is indeed configured in accordance with the vendor's instructions to protect the cryptographic module software components from unauthorized modification.

 

• TE07.07.02: The tester shall verify that it is possible to specify a distinct set of operators for each of the following components:

 

1. cryptographic program images on secondary storage
2. cryptographic data (e.g., cryptographic keys, audit data) stored on secondary storage
3. cryptographic data (e.g., cryptographic keys, audit data) stored in computer memory
4. other critical security parameters stored on secondary storage
5. other critical security parameters contained in computer memory
• TE07.07.03: The tester shall become an operator in the set who can modify each of the types of cryptographic module software components. He or she must verify that he or she can, in fact, modify them.

 

• TE07.07.04: The tester shall become an operator who is not in the set who can modify each of the types of cryptographic module software components. He or she must verify that he or she can not, in fact, modify them.

 

AS07.08: The operating system shall provide the capability to prevent all operators and executing processes from modifying executing cryptographic processes (i.e., loaded and executing cryptographic program images). Executing processes, in this case, means all non-operating system (i.e., all operator initiated) processes, cryptographic or not. (2, 3, and 4)

Required Vendor Information

• VE07.08.01: The vendor shall include in the installation procedures specific instructions on how, by employing the protection mechanisms provided by a controlled access operating system, one can configure the system to protect executing cryptographic processes from unauthorized modification.

 

Required Test Procedures

• TE07.08.01: The tester shall review the installation procedures provided by the vendor in VE07.08.01, and examine the actual configuration of the cryptographic module, to verify that the cryptographic module is indeed configured in accordance with the vendor's instructions to protect executing cryptographic processes from unauthorized modification.

 

• TE07.08.02: The tester shall try to modify executing cryptographic processes. The tester shall construct a test process that attempts to modify cryptographic processes both within and outside its address space. He or she must verify that no operator or executing process can modify an executing cryptographic process.

 

AS07.09: The operating system shall provide the capability to specify a separate set of operators and cryptographic processes for each of the following cryptographic module software components, such that only elements within a given component's set can read entities within that component: (2, 3, and 4)

• cryptographic data (e.g. cryptographic keys, audit data) stored on secondary storage
• cryptographic data (e.g. cryptographic keys, audit data) stored computer memory
• other critical security parameters stored on secondary storage
• other critical security parameters contained in computer memory
• plaintext data stored either within the module's memory or on secondary storage

Required Vendor Information

• VE07.09.01: The vendor shall include in the installation procedures specific instructions on how, by employing the protection mechanisms provided by a controlled access operating system, one can configure the cryptographic module software components to protect the them from being read by unauthorized operators or processes.

 

Required Test Procedures

• TE07.09.01: The tester shall review the installation procedures provided by the vendor, and examine the actual configuration of the cryptographic module, to verify that the cryptographic module is indeed configured in accordance with the vendor's instructions to protect the cryptographic module software components from unauthorized reading.

 

• TE07.09.02: The tester shall verify that it is possible to specify a distinct set of operators for each of the following components:

 

1. cryptographic program images on secondary storage
2. cryptographic data (e.g., cryptographic keys, audit data) stored on secondary storage
3. cryptographic data (e.g., cryptographic keys, audit data) stored in computer memory
4. other critical security parameters stored on secondary storage
5. other critical security parameters contained in computer memory
• TE07.09.03: The tester shall become an operator in the set who can read each of the types of cryptographic module software components. He or she must verify that he or she can, in fact, read them. If the set consists only of cryptographic processes, the tester may use an operational cryptographic process to attempt to read the software components, or may construct a test process that has the same authorization as the operational processes within the set (e.g., be in the same group as the operational processes).

 

• TE07.09.04: The tester shall become an operator who is not in the set who can read each of the types of cryptographic module software components. He or she must verify that he or she can not, in fact, modify them. The tester may also modify the authorizations of an operational cryptographic process and attempt to read the software components, or may construct a test process that does not have read authorization (e.g., is not in the same group as the operational processes).

 

AS07.10: The operating system shall provide the capability to prevent all operators and processes from reading the following cryptographic module software components: (2, 3, and 4)

• cryptographic program images contained on secondary storage
• executing cryptographic program images

Required Vendor Information

• VE07.10.01: The vendor shall include in the installation procedures specific instructions on how, by employing the protection mechanisms provided by a controlled access operating system, one can configure the system to prevent all operators and processes from reading the software components identified in AS07.10.

 

Required Test Procedures

• TE07.10.01: The tester shall review the installation procedures provided by the vendor in VE07.10.01, and examine the actual configuration of the cryptographic module, to verify that the cryptographic module is indeed configured in accordance with the vendor's instructions to prevent all operators and processes from reading the software components identified in AS07.10.

 

• TE07.10.02: The tester shall try to read cryptographic program images contained on secondary storage and executing cryptographic program images. The tester shall construct a test process that attempts to read the cryptographic program images both within and outside its address space and on secondary storage. He or she must verify that no operator or executing process can read a cryptographic program image.

 

AS07.11: The operating system shall provide the capability to specify a set of operators who are authorized to enter cryptographic keys and other critical security parameters. (2, 3, and 4)

Required Vendor Information

• VE07.11.01: The vendor shall include in the installation procedures specific instructions on how, by employing the protection mechanisms provided by a controlled access operating system, one can configure the cryptographic module to protect cryptographic keys and other critical security parameters from being entered by unauthorized operators.

 

Required Test Procedures

• TE07.11.01: The tester shall review the installation procedures provided by the vendor, and examine the actual configuration of the cryptographic module, to verify that the cryptographic module is, indeed, configured in accordance with the vendor's instructions to protect cryptographic keys and other critical security parameters from being entered by unauthorized operators.

 

• TE07.11.02: The tester shall become an operator in the set who can enter cryptographic keys and other critical security parameters. He or she must verify that he or she can, in fact, enter them.

 

• TE07.11.03: The tester shall become an operator who is not in the set who can enter cryptographic keys and other critical security parameters. He or she must verify that he or she can not, in fact, enter them.

 

AS07.12: All cryptographic software, cryptographic keys and other critical security parameters, control and status information shall be labelled and under the control of an operating system that provides labelled protection (i.e., B1 protection in accordance with the Trusted Computer System Evaluation Criteria (TCSEC) or FIPS approved equivalent). Only operating systems that have been evaluated by a NIST accredited evaluation authority and against a FIPS approved criteria shall be used. (3)

Required Vendor Information

• VE07.12.01: The vendor shall provide documentation that describes how the cryptographic software, cryptographic keys, other critical security parameters, and control and status information are labelled and how these labels prevent unauthorized disclosure and modification.

 Note: Operating systems that allow subjects to write to objects whose label strictly dominates the subject's label (i.e., write up) might not be able to prevent unauthorized modification.

 

• VE07.12.02: The vendor shall provide proof that the operating system that controls the cryptographic module has successfully passed evaluation for "labeled protection" (B1 in the TCSEC or FIPS-approved equivalent) by a NIST-accredited evaluation authority and against a FIPS-approved criteria. Two of the ways that a vendor may provide this proof are 1) to present the tester with a certificate from a NIST-accredited evaluation authority certifying that the operating system successfully passed an evaluation, or 2) to show that the operating system is listed on a FIPS-approved evaluated products list or equivalent as having passed an evaluation.

 

Required Test Procedures

• TE07.12.01: The tester shall check that the operating system enforces labelling of cryptographic software, cryptographic keys, other critical security parameters, and control and status information in such a way that unauthorized disclosure and modification is prevented.

 Note: Operating systems that allow subjects to write to objects whose label strictly dominates the subject's label (i.e., write up) might not be able to prevent unauthorized modification.

 

• TE07.12.02: The tester shall check that the evaluation authority identified in the proof evidence is a NIST-accredited evaluation authority. This may be accomplished by referring to a NIST-supplied list accredited evaluation authorities to see if the evaluation authority identified in the proof evidence is on that list.

 

• TE07.12.03: The tester shall check that this operating system was, in fact, evaluated by this evaluation authority; and that the evaluation authority used a FIPS-approved criteria in performing the evaluation.

 

AS07.13: All cryptographic keys, authentication data, other critical security parameters, control inputs and status outputs shall be communicated only via a trusted mechanism (e.g., a dedicated I/O port or a trusted path). (3 and 4)

Required Vendor Information

• VE07.13.01: The vendor shall identify and describe the trusted path mechanism used by the cryptographic module to communicate cryptographic keys, authentication data, other critical security parameters, control inputs, and status outputs.

 

Required Test Procedures

• TE07.13.01: For each input and output that AS07.13 requires to be communicated via the trusted mechanism, the tester shall demonstrate, by actual use, that the trusted mechanism can, in fact, be used to communicate such data.

 Note: If the trusted mechanism is a trusted path, and the trusted path was an evaluated feature of the operating system, the tester need not independently test the trusted path. If, on the other hand, the trusted mechanism is not a trusted path, or if a trusted path is not an evaluated feature of the operating system, then the tester must test for correct operation and non-circumventability of the trusted mechanism.

 

• TE07.13.02: Through his or her knowledge of the design and implementation of the module, as well as knowledge of the operator documentation, the tester shall attempt, for each input or output identified in AS07.13, to enter or output the information via an untrusted mechanism (untrusted path or I/O port).

 

AS07.14: When a trusted path is used, the trusted computing base (TCB) of the operating system shall support the trusted path between itself and the operators for use when a positive TCB-to-operator connection is required. (3 and 4)

Required Test Procedures

• TE07.14.01: By reviewing and analyzing the cryptographic module software design, any operating system design and documentation available, and vendor arguments, the tester shall determine that it is the TCB of the operating system that supports (provides and protects) the trusted path capability.

 

AS07.15: When a trusted path is used, communications via this trusted path shall be activated exclusively by an operator or the TCB and shall be logically isolated and unmistakably distinguishable from other paths. (3 and 4)

Required Test Procedures

• TE07.15.01: Through his or her knowledge of the cryptographic module user documentation, the tester shall invoke the trusted path in accordance with the documentation guidance. Also, if the capability exists during the operation (normal or abnormal) of the cryptographic module, for the TCB to invoke the trusted path, the tester shall exercise (operate) the module in such a way as to cause the TCB to invoke the trusted path.

 

• TE07.15.02: Through his or her knowledge of the cryptographic module design and documentation, the tester shall attempt to cause the trusted path to be invoked by non-TCB software (e.g., a user process or a cryptographic module software module that is not part of the operating system TCB).

 

• TE07.15.03: The tester shall perform independent invocations of the trusted path to determine that it is unmistakably distinguishable from all other paths. He or she must invoke the trusted path as an operator, and also cause the TCB to invoke the trusted path, if possible. These tests are to be separate from the other trusted mechanism tests to force the tester to focus on the "unmistakably distinguishable" aspect of the trusted path feature. This test may require the tester to invoke (utilize) other paths (I/O ports) to perform various functions to convince him or herself that the trusted path is, indeed, unmistakably distinguishable from all other paths.

 

• TE07.15.04: By reviewing and analyzing the cryptographic module software design, any operating system design and documentation available, and vendor arguments, the tester shall determine that the trusted path is logically isolated from all other paths.

 

AS07.16: The operating system shall provide the capability to audit the entry of cryptographic keys, other critical security parameters and control inputs and status outputs. (3 and 4)

 Note: An assumption of this assertion is that the cryptographic module must use the audit mechanism provided by the operating system to audit the identified events. It is not sufficient for the cryptographic module software to use another file, no matter how well protected, as its audit log.

 Note: It is also assumed that the assertion requires that each of the events identified in the assertion be auditable by the cryptographic module software. The cryptographic module software may have the capability for turning off auditing of one or all of the identified events, but they must all be potentially auditable. This assertion sets no requirement on which events must be audited by a given site.

 Note: The operating system must have the capability to allow non-TCB processes to use (write to) the system audit log. This capability is not inherent (guaranteed) in a B1 system, or in a system evaluated at any class.

Required Vendor Information

• VE07.16.01: The vendor shall identify the mechanism whereby a non-TCB process can write records to the system's audit log.

 

• VE07.16.02: The vendor shall identify all the events that are auditable by the cryptographic module software.

 

• VE07.16.03: For each of the auditable events so identified, the vendor shall provide the types of information and its format for all information contained in the audit record for the event.

 Note: Both the format and type of information must be provided because the tester must have the capability to read and interpret the audit records for all cryptographic events audited in order to check it against the information that is claimed to be in the record.

 

• Note: The tester DOES NOT have to test or in anyway validate the audit mechanism provided by the operating system and identified by the vendor.

 

Required Test Procedures

• TE07.16.01: The tester shall review all of the actions that can be taken by users and the cryptographic officer and identify all of those that produce the events identified in AS07.16, namely the entry of cryptographic keys, other critical security parameters, and control inputs, or the output of status information.

 

• TE07.16.02: The tester shall then compare the event list provided by the vendor in VE07.16.02 with the events he or she identified through independent analysis of the actions of the cryptographic module. If the vendor's event list does not contain all the events identified by the tester, the vendor and tester must discuss and come to agreement concerning all the events that meet the criteria of AS07.16.

 

• TE07.16.03: The tester shall review the types of information contained in the audit records for each distinct event in the event list, to determine if all the necessary information is there. This information is provided by the vendor in VE07.16.03.

 

• TE07.16.04: The tester shall exercise the cryptographic module, with the auditing capability turned on, performing all the actions that generate events that must be auditable. He or she will then review the system's audit log to determine first if all the events were, indeed, audited, and second that all the required information was contained in the resulting audit record.

 Note: TE07.16.04 may be satisfied in whole or in part by examining the audit log produced during other testing of the cryptographic module. It is only required that audit records be examined for all actions of the cryptographic module that produce events that must be audited, no matter when these actions were performed.

 

AS07.17: All cryptographic software, cryptographic keys and other critical security parameters, control and status information shall be labelled and under the control of an operating system that provides structured protection (i.e., B2 protection in accordance with the Trusted Computer System Evaluation Criteria (TCSEC), or FIPS approved equivalent). Only operating systems that have been evaluated by a NIST accredited evaluation authority and against a FIPS approved criteria shall be used. (4)

Required Vendor Information

• VE07.17.01: The vendor shall provide proof that the operating system controlling the cryptographic module has successfully passed evaluation for "structured protection" (B2 in the TCSEC or FIPS-approved equivalent) by a NIST-accredited evaluation authority and against a FIPS-approved criteria. Two of the ways that a vendor may provide this proof are 1) to present the tester with a certificate from a NIST-accredited evaluation authority certifying that the operating system successfully passed an evaluation, or 2) to demonstrate that the operating system is listed on a FIPS-approved, evaluated products list, or equivalent, as having passed such an evaluation.

 

Required Test Procedures

• TE07.17.01: The tester shall check that the evaluation authority identified in the proof evidence is a NIST-accredited evaluation authority. This may be accomplished by referring to a NIST-supplied list of accredited evaluation authorities to see if the evaluation authority identified in the proof evidence is on that list.

 

• TE07.17.02: The tester shall check that this operating system was, in fact, evaluated by this evaluation authority; and that the evaluation authority used a FIPS-approved criteria in performing the evaluation.

 

¹ This definition has been derived from the definition of "Formal Security Policy Model," Department of Defense Trusted Computer System Evaluation Criteria, National Computer Security Center, DOD 5200.28-STD, December 1985.

 ² [NCSC-TG-10]: A Guide to Understanding Security Modeling in Trusted Systems, National Computer Security Center, October 1992.

Continue to sections 8-11 of the DTR (part 3 of 3)...

Last Update: January 10, 2002
Computer Security Division
National Institute of Standards and Technology