VE 01: Difference between revisions

Line 1:

~~<html><head>~~

~~<meta http-equiv="CONTENT-TYPE" content="text/html; charset=windows-1252"><title></title>~~

~~<meta name="GENERATOR" content="StarOffice 7 (Win32)">~~

~~<meta name="CREATED" content="20050722;15152389">~~

~~<meta name="CHANGEDBY" content="Glen Beasley">~~

~~<meta name="CHANGED" content="20050722;16143066">~~

~~<style>~~

~~<!--~~

~~@page { size: 8.5in 11in; margin-left: 0.79in; margin-right: 1in; margin-top: 0.5in; margin-bottom: 0.5in }~~

~~P { margin-bottom: 0.08in }~~

~~-->~~

~~</style></head>~~

~~<body dir="ltr" lang="en-US">~~

~~SECTION~~

~~1: CRYPTOGRAPHIC MODULE SPECIFICATION~~

~~AS.01.01The~~

~~cryptographic module shall be a set of hardware, software, ~~

~~~~

~~firmware,~~

~~or some combination thereof that implements cryptographic ~~

~~~~

~~functions~~

~~or processes, including cryptographic algorithms and, ~~

~~~~

~~optionally,~~

~~key generation, and is contained within a defined ~~

~~~~

~~cryptographic~~

~~boundary.~~

Assessment:

~~AS.01.02The~~

~~cryptographic module shall implement at least one Approved ~~

~~~~

~~security~~

~~function used in an Approved mode of operation.~~

~~Note:~~

~~This assertion is tested as part of AS01.12.~~

~~ ~~

~~~~

Assessment:

~~AS.01.03The~~

~~operator shall be able to determine when an Approved mode of ~~

~~~~

~~operation~~

~~is selected.~~

~~ ~~

~~~~

~~Assessment:~~

<a href="#VE.01.03.01">VE.01.03.01</a>The

~~vendor provided nonproprietary security policy shall provide a ~~

~~~~

~~description~~

~~of the Approved mode of operation.~~

~~ ~~

~~~~

~~Assessment:~~

<a href="#VE.01.03.02">VE.01.03.02</a>The

~~vendor provided non-proprietary security policy shall provide ~~

~~~~

~~instructions~~

~~for invoking the Approved mode of operation.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.01.05The~~

~~cryptographic boundary shall consist of an explicitly defined ~~

~~~~

~~perimeter~~

~~that establishes the physical bounds of the cryptographic ~~

~~~~

~~module.~~

~~ ~~

~~~~

Assessment:

~~AS.01.06If~~

~~the cryptographic module consists of software or firmware ~~

~~~~

~~components,~~

~~the cryptographic boundary shall contain the processor(s) ~~

~~~~

~~and~~

~~other hardware components that store and protect the software and~~

~~firmware~~

~~components.~~

Assessment:

~~VE.01.06.01For~~

~~each processor in the module, the vendor shall identify, by major ~~

~~~~

~~services,~~

~~the software or firmware that are executed by the processor, ~~

~~~~

~~and~~

~~the memory devices that contain the executable code and data.~~

~~ ~~

~~~~

Assessment:

~~VE.01.06.02For~~

~~each processor, the vendor shall identify any hardware with which ~~

~~~~

~~the~~

~~processor interfaces.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.01.07The~~

~~following documentation requirements shall apply to all ~~

~~~~

~~security-specific~~

~~hardware, software, and firmware contained within the~~

~~cryptographic~~

~~module.~~

~~Note:~~

~~This assertion is not separately tested.~~

Assessment:

AS.01.08Documentation

~~shall specify the hardware, software, and firmware ~~

~~~~

~~components~~

~~of the cryptographic module, specify the cryptographic ~~

~~~~

~~boundary~~

~~surrounding these components, and describe the physical ~~

~~~~

~~configuration~~

~~of the module.~~

Assessment:

~~VE.01.08.01All~~

~~hardware, software, and firmware components of the cryptographic ~~

~~~~

~~module~~

~~shall be identified in the vendor documentation. Components ~~

~~~~

~~to~~

~~be listed shall include, as applicable, all of the following:~~

~~1.~~

~~Integrated circuits, including processors, memory, and (semi-) ~~

~~~~

~~custom~~

~~integrated circuits~~

~~2.~~

~~Other active electronic circuit elements~~

~~3.~~

~~Power inputs and outputs, and internal power supplies or ~~

~~~~

~~converters~~

~~4.~~

~~Physical structures, including circuit boards or other mounting ~~

~~~~

~~surfaces,~~

~~enclosures, and connectors~~

~~5.~~

~~Software and firmware modules~~

~~6.~~

~~Other component types not listed above~~

Assessment:

~~VE.01.08.02The~~

~~above list of components shall be consistent with the information ~~

~~~~

~~provided~~

~~for all other assertions of this section.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.01.08.03The~~

~~vendor documentation shall specify the module's cryptographic ~~

~~~~

~~boundary.~~

~~The cryptographic boundary shall be an explicitly defined, ~~

~~~~

~~contiguous~~

~~perimeter that establishes the physical bounds of the ~~

~~~~

~~cryptographic~~

~~module. The boundary definition shall specify module ~~

~~~~

~~components~~

~~and connections (ports), and also module information ~~

~~~~

~~flows,~~

~~processing, and input/output data.~~

Assessment:

~~VE.01.08.04The~~

~~cryptographic boundary shall include any hardware or software ~~

~~~~

~~that~~

~~inputs, processes, or outputs important security parameters that ~~

~~~~

~~could~~

~~lead to the compromise of sensitive information if not properly ~~

~~~~

~~ ~~

~~~~

Assessment:

~~VE.01.08.05The~~

~~vendor documentation shall specify the physical embodiments of ~~

~~~~

~~the~~

~~module ( single-chip cryptographic module, multiple-chip embedded~~

~~cryptographic~~

~~module, or multiple-chip standalone cryptographic ~~

~~~~

~~module,~~

~~as defined in Section 4.5 of FIPS PUB 140-2.~~

Assessment:

~~VE.01.08.06The~~

~~vendor's documentation shall indicate the internal layout and ~~

~~~~

~~assembly~~

~~methods (e.g., fasteners and fittings) of the module, including ~~

~~~~

~~drawings~~

~~that are at least approximately to scale. The interior of ~~

~~~~

~~integrated~~

~~circuits need not be shown.~~

Assessment:

~~VE.01.08.07The~~

~~vendor's documentation shall describe the primary physical ~~

~~~~

~~parameters~~

~~of the module, including descriptions of the enclosure, ~~

~~~~

~~access~~

~~points, circuit boards, location of power supply, interconnection ~~

~~~~

~~wiring~~

~~runs, cooling arrangements, and any other significant parameters.~~

Assessment:

AS.01.09Documentation

~~shall specify any hardware, software, or firmware ~~

~~~~

~~components~~

~~of the cryptographic module that are excluded from the ~~

~~~~

~~security~~

~~requirements of this standard and explain the rationale for the ~~

~~~~

~~exclusion.~~

Assessment:

~~VE.01.09.01All~~

~~components that are to be excluded from the security requirements ~~

~~~~

~~shall~~

~~be explicitly listed in the vendor documentation.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~VE.01.09.02The~~

~~rationale for excluding each of the components listed in response to~~

~~requirement~~

~~VE01.09.01 shall be provided in the vendor ~~

~~~~

~~documentation.~~

~~The vendor shall show that each component, even if ~~

~~~~

~~malfunctioning~~

~~or misused, cannot cause a compromise under any ~~

~~~~

Assessment:

AS.01.10Documentation

~~shall specify the physical ports and logical interfaces ~~

~~~~

~~and~~

~~all defined input and output paths of the cryptographic module.~~

~~Note:~~

~~This assertion is tested as part of AS02.01.~~

~~ ~~

~~~~

Assessment:

AS.01.11Documentation

~~shall specify the manual or logical controls of the ~~

~~~~

~~cryptographic~~

~~module, physical or logical status indicators, and their ~~

~~~~

~~physical,~~

~~logical, and electrical characteristics. ~~

~~~~

~~Note:~~

~~This assertion is tested as part of AS02.01.~~

Assessment:

AS.01.12Documentation

~~shall list all security functions, both Approved and ~~

~~~~

~~non-Approved,~~

~~that are employed by the cryptographic module and ~~

~~~~

~~shall~~

~~specify all modes of operation, both Approved and non-Approved.~~

~~ ~~

~~~~

Assessment:

~~VE.01.12.01The~~

~~vendor shall provide a validation certificate for all Approved ~~

~~~~

~~cryptographic~~

~~algorithms.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.01.12.02The~~

~~vendor shall provide a list of all non-Approved security functions.~~

~~ ~~

~~~~

~~Assessment:~~

AS.01.13Documentation

~~shall specify a block diagram depicting all of the major ~~

~~~~

~~hardware~~

~~components of the cryptographic module and their ~~

~~~~

~~interconnections,~~

~~including any microprocessors, input/output buffers, ~~

~~~~

~~plaintext/ciphertext~~

~~buffers, control buffers, key storage, working ~~

~~~~

~~memory,~~

~~and program memory.~~

Assessment:

~~VE.01.13.01The~~

~~vendor documentation shall include a block diagram showing the ~~

~~~~

~~hardware~~

~~components and their interconnections. Components to be ~~

~~~~

~~included~~

~~in the block diagram shall include, as applicable:~~

~~1.~~

~~Microprocessors~~

~~2.~~

~~Input/output buffers~~

~~3.~~

~~Plaintext/ciphertext buffers~~

~~4.~~

~~Control buffers~~

~~5.~~

~~Key storage~~

~~6.~~

~~Working memory~~

~~7.~~

~~Program memory~~

~~8.~~

~~Other components types not listed above~~

Assessment:

~~VE.01.13.02The~~

~~block diagram shall also include any (semi-) custom integrated ~~

~~~~

~~circuits~~

~~(e.g., gate arrays, field programmable gate arrays, or other ~~

~~~~

~~programmable~~

~~logic).~~

~~ ~~

~~~~

Assessment:

~~VE.01.13.03The~~

~~block diagram shall show interconnections among major ~~

~~~~

~~components~~

~~of the module and between the module and equipment or ~~

~~~~

~~components~~

~~outside of the cryptographic boundary.~~

~~ ~~

~~~~

Assessment:

~~VE.01.13.04The~~

~~block diagram shall show the cryptographic boundary of the ~~

~~~~

~~module.~~

~~ ~~

~~~~

~~Assessment:~~

AS.01.14Documentation

~~shall specify the design of the hardware, software, and ~~

~~~~

~~firmware~~

~~components of the cryptographic module. High-level ~~

~~~~

~~specification~~

~~languages for software/firmware or schematics for ~~

~~~~

~~hardware~~

~~shall be used to document the design.~~

Assessment:

~~VE.01.14.01The~~

~~vendor shall provide a detailed specification of the design of the ~~

~~~~

~~hardware,~~

~~software, and/or firmware contained in the module. This ~~

~~~~

~~documentation~~

~~shall include, the finite state model and description ~~

~~~~

~~referred~~

~~to in Section 4.4 of FIPS PUB 140-2. If the relationship ~~

~~~~

~~between~~

~~the finite state model and the design specification is not clear, ~~

~~~~

~~the~~

~~vendor shall provide additional documentation that describes this ~~

~~~~

Assessment:

AS.01.15Documentation

~~shall specify all security-related information, including ~~

~~~~

~~secret~~

~~and private cryptographic keys (both plaintext and encrypted), ~~

~~~~

~~authentication~~

~~data (e.g., passwords, PINs), CSPs, and other protected ~~

~~~~

~~information~~

~~(e.g., audited events, audit data) whose disclosure or ~~

~~~~

~~modification~~

~~can compromise the security of the cryptographic module.~~

Assessment:

~~VE.01.15.01The~~

~~vendor shall provide documentation specifying all security-related ~~

~~~~

~~information,~~

~~including secret and private cryptographic keys (both ~~

~~~~

~~plaintext~~

~~and encrypted), authentication data (e.g., passwords, PINs), ~~

~~~~

~~CSPs,~~

~~and other protected information (e.g., audited events, audit data)~~

~~whose~~

~~disclosure or modification can compromise the security of the ~~

~~~~

~~cryptographic~~

~~module.~~

Assessment:

AS.01.16Documentation

~~shall specify the cryptographic module security policy. ~~

~~~~

~~The~~

~~security policy shall include the rules derived from the ~~

~~~~

~~requirements~~

~~of this standard and the rules derived from any additional ~~

~~~~

~~requirements~~

~~imposed by the vendor.~~

Assessment:

~~VE.01.16.01The~~

~~vendor shall provide a separate nonproprietary security policy. ~~

~~~~

~~The~~

~~security policy is defined in Appendix C of FIPS PUB 140-2.~~

~~ ~~

~~~~

~~Assessment:~~

~~~~

~~ ~~

~~~~

~~SECTION~~

~~2: MODULE PORTS AND INTERFACES~~

~~AS.02.01The~~

~~cryptographic module shall restrict all information flow and ~~

~~~~

~~physical~~

~~access points to physical ports and logical interfaces that define~~

~~all~~

~~entry and exit points to and from the module.~~

~~ ~~

~~~~

Assessment:

~~VE.02.01.01Vendor~~

~~documentation shall specify each of the physical ports and ~~

~~~~

~~logical~~

~~interfaces of the cryptographic module, including the:~~

~~1.~~

~~Physical ports and their pin assignments ~~

~~~~

~~2.~~

~~Physical covers, doors or openings~~

~~3.~~

~~Logical interfaces (e.g., APIs and all other data/control/status ~~

~~~~

~~signals)~~

~~and the signal names and functions~~

~~4.~~

~~Manual controls (e.g., buttons or switches) for applicable physical ~~

~~~~

~~control~~

~~inputs~~

~~5.~~

~~Physical status indicators (e.g., lights or displays) for applicable ~~

~~~~

~~physical~~

~~status outputs~~

~~6.~~

~~Mapping of the logical interfaces to the physical ports, manual ~~

~~~~

~~controls,~~

~~and physical status indicators of the cryptographic module~~

~~7.~~

~~Physical, logical, and electrical characteristics, as applicable, of~~

~~the ~~

~~~~

~~above~~

~~ports and interfaces~~

Assessment:

~~VE.02.01.02Vendor~~

~~documentation shall specify the information flows and physical ~~

~~~~

~~access~~

~~points of the cryptographic module by highlighting or annotating ~~

~~~~

~~copies~~

~~of the block diagrams, design specifications and/or source code ~~

~~~~

~~and~~

~~schematics provided in Sections 1 and 10. The vendor shall also ~~

~~~~

~~provide~~

~~any other documentation necessary to clearly specify the ~~

~~~~

~~relationship~~

~~of the information flows and physical access points to the ~~

~~~~

~~physical~~

~~ports and logical interfaces.~~

Assessment:

~~VE.02.01.03For~~

~~each physical or logical input to the cryptographic module, or ~~

~~~~

~~physical~~

~~and logical output from the module, vendor documentation ~~

~~~~

~~shall~~

~~specify the logical interface to which the physical input or output ~~

~~~~

~~belongs,~~

~~and the physical entry/exit port. The specifications provided ~~

~~~~

~~shall~~

~~be consistent with the specifications of the cryptographic module ~~

~~~~

~~components~~

~~provided under sections 1 and 10, and the specifications of~~

~~the~~

~~logical interfaces provided in assertions AS02.03 to AS02.09 of this~~

~~section.~~

Assessment:

~~~~

~~~~

~~AS.02.02The~~

~~cryptographic module interfaces shall be logically distinct from ~~

~~~~

~~each~~

~~other although they may share one physical port (e.g., input data ~~

~~~~

~~may~~

~~enter and output data may exit via the same port) or may be ~~

~~~~

~~distributed~~

~~over one or more physical ports (e.g., input data may enter ~~

~~~~

~~via~~

~~both a serial and a parallel port).~~

Assessment:

~~VE.02.02.01The~~

~~vendor's design shall separate the cryptographic module interfaces ~~

~~~~

~~into~~

~~logically distinct and isolated categories, using the categories~~

~~listed ~~

~~~~

~~in~~

~~assertion AS02.03, and, if applicable, AS02.09 in this section. This ~~

~~~~

~~information~~

~~shall be consistent with the specification of the logical ~~

~~~~

~~interfaces~~

~~and physical ports provided in AS02.01 in this section.~~

Assessment:

~~VE.02.02.02Vendor~~

~~documentation shall provide a mapping of each category of ~~

~~~~

~~logical~~

~~interface to a physical port of the cryptographic module. A ~~

~~~~

~~logical~~

~~interface may be physically distributed across more than one ~~

~~~~

~~physical~~

~~port, or two or more logical interfaces may share one physical ~~

~~~~

~~port~~

~~as long as the information flows are kept logically separate. If two ~~

~~~~

~~or~~

~~more logical interfaces share the same physical port, vendor ~~

~~~~

~~documentation~~

~~shall specify how the information from the different ~~

~~~~

~~interface~~

~~categories is kept logically separate.~~

Assessment:

~~AS.02.03The~~

~~cryptographic module shall have the following four logical ~~

~~~~

~~interfaces~~

~~("input" and "output" are indicated from the~~

~~perspective of ~~

~~~~

~~the~~

~~module):~~

*

~~Data input interface~~

*

~~Data output interface~~

*

~~Control input interface~~

Assessment:

~~VE.02.03.01Vendor~~

~~documentation shall specify that the following four logical ~~

~~~~

~~interfaces~~

~~have been designed within the cryptographic module ("input"~~

~~~~

~~~~

~~and~~

~~"output" are indicated from the perspective of the module):~~

*

~~data input interface (for the entry of data as specified in AS02.04),~~

*

~~data output interface (for the output of data as specified in ~~

~~~~

~~AS02.05),~~

*

~~control input interface (for the entry of commands as specified in ~~

~~~~

~~AS02.07),~~

~~and ~~

~~~~

*

~~status output interface (for the output of status information as ~~

~~~~

Assessment:

~~AS.02.04All~~

~~data (except control data entered via the control input interface)~~

~~that~~

~~is~~

~~input to and processed by the cryptographic module (including ~~

~~~~

~~plaintext~~

~~data, ciphertext data, cryptographic keys and CSPs, ~~

~~~~

~~authentication~~

~~data, and status information from another module) shall enter via the~~

~~"data input" interface.~~

Assessment:

~~VE.02.04.01The~~

~~cryptographic module shall have a data input interface. All data ~~

~~~~

~~(except~~

~~control data entered via the control input interface) that is to be ~~

~~~~

~~input~~

~~to and processed by the cryptographic module shall enter via the ~~

~~~~

~~data~~

~~input interface, including:~~

~~1.~~

~~Plaintext data~~

~~2.~~

~~Ciphertext or signed data~~

~~3.~~

~~Cryptographic keys and other key management data (plaintext or ~~

~~~~

~~encrypted)~~

~~4.~~

~~Authentication data (plaintext or encrypted)~~

~~5.~~

~~Status information from external sources~~

~~6.~~

~~Any other input data~~

Assessment:

~~VE.02.04.02If~~

~~applicable, vendor documentation shall specify any external input ~~

~~~~

~~devices~~

~~to be used with the cryptographic module for the entry of data ~~

~~~~

~~into~~

~~the data input interface, such as smart cards, tokens, keypads, key ~~

~~~~

~~loaders,~~

~~and/or biometric devices.~~

Assessment:

~~AS.02.05All~~

~~data (except status data output via the status output interface) that~~

~~is~~

~~output~~

~~from the cryptographic module (including plaintext data, ~~

~~~~

~~ciphertext~~

~~data, cryptographic keys and CSPs, authentication data, and ~~

~~~~

~~control~~

~~information for another module) shall exit via the "data output"~~

~~~~

~~~~

Assessment:

~~VE.02.05.01The~~

~~cryptographic module shall have a data output interface. All data ~~

~~~~

~~(except~~

~~status data output via the status output interface) that has been ~~

~~~~

~~processed~~

~~and is to be output by the cryptographic module shall exit via~~

~~the~~

~~data output interface, including:~~

~~1.~~

~~Plaintext data~~

~~2.~~

~~Ciphertext data and digital signatures~~

~~3.~~

~~Cryptographic keys and other key management data (plaintext or ~~

~~~~

~~encrypted)~~

~~4.~~

~~Control information to external targets~~

~~5.~~

~~Any other output data~~

Assessment:

~~VE.02.05.02If~~

~~applicable, vendor documentation shall specify any external output ~~

~~~~

~~devices~~

~~to be used with the cryptographic module for the output of data~~

~~from~~

~~the data output interface, such as smart cards, tokens, displays, ~~

~~~~

~~and/or~~

~~other storage devices.~~

Assessment:

~~AS.02.06All~~

~~data output via the data output interface shall be inhibited when an ~~

~~~~

~~error~~

~~state exists and during self-tests.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.02.06.01Vendor~~

~~documentation shall specify how the cryptographic module ~~

~~~~

~~ensures~~

~~that all data output via the data output interface is inhibited ~~

~~~~

~~whenever~~

~~the module is in an error state (error states are covered in ~~

~~~~

~~Section~~

~~4). Status information may be allowed from the status output ~~

~~~~

~~interface~~

~~to identify the type of error, as long as no CSPs, plaintext ~~

~~~~

~~data,~~

~~or other information that if misused could lead to a compromised.~~

Assessment:

~~VE.02.06.02Vendor~~

~~documentation shall specify how the design of the ~~

~~~~

~~cryptographic~~

~~module ensures that all data output via the data output ~~

~~~~

~~interface~~

~~is inhibited whenever the module is in a self-test condition ~~

~~~~

~~(self-tests~~

~~are covered in Section 9). Status information to display the ~~

~~~~

~~results~~

~~of the self-tests may be allowed from the status output interface,~~

~~as~~

~~long as no CSPs, plaintext data, or other information that if misused~~

~~~~

~~~~

Assessment:

~~AS.02.07All~~

~~input commands, signals, and control data (including calls and ~~

~~~~

~~manual~~

~~controls such as switches, buttons, and keyboards) used to ~~

~~~~

~~control~~

~~the operation of the cryptographic module shall enter via the ~~

~~~~

~~"control~~

~~input" interface.~~

Assessment:

~~VE.02.07.01The~~

~~cryptographic module shall have a control input interface. All ~~

~~~~

~~commands,~~

~~signals, and control data (except data entered via the data ~~

~~~~

~~input~~

~~interface) used to control the operation of the cryptographic ~~

~~~~

~~module~~

~~shall enter via the control input interface, including:~~

~~1.~~

~~Commands input logically via an API (e.g., for the software and ~~

~~~~

~~firmware~~

~~components of the cryptographic module)~~

~~2.~~

~~Signals input logically or physically via one or more physical ports ~~

~~~~

~~(e.g.,~~

~~for the hardware components of the cryptographic module)~~

~~3.~~

~~Manual control inputs (e.g., using switches, buttons, or a keyboard)~~

~~ ~~

~~~~

~~4.~~

~~Any other input control data~~

Assessment:

~~VE.02.07.02If~~

~~applicable, vendor documentation shall specify any external input ~~

~~~~

~~devices~~

~~to be used with the cryptographic module for the entry of ~~

~~~~

~~commands,~~

~~signals, and control data into the control input interface, ~~

~~~~

~~such~~

~~as smart cards, tokens, or keypads.~~

Assessment:

~~AS.02.08All~~

~~output signals, indicators, and status data (including return codes ~~

~~~~

~~and~~

~~physical indicators such as Light Emitting Diodes and displays) ~~

~~~~

~~used~~

~~to indicate the status of the cryptographic module shall exit via the~~

~~~~

~~~~

~~"status~~

~~output" interface.~~

Assessment:

~~VE.02.08.01The~~

~~cryptographic module shall have a status output interface. All ~~

~~~~

~~status~~

~~information, signals, logical indicators, and physical indicators ~~

~~~~

~~used~~

~~to indicate or display the status of the module shall exit via the ~~

~~~~

~~status~~

~~output interface, including: ~~

~~~~

~~1.~~

~~Status information output logically via an API ~~

~~~~

~~2.~~

~~Signals output logically or physically via one or more physical ~~

~~~~

~~3.~~

~~Manual status outputs (e.g., using LEDs, buzzers, or a display)~~

~~4.~~

~~Any other output status information~~

Assessment:

~~VE.02.08.02If~~

~~applicable, vendor documentation shall specify any external output ~~

~~~~

~~devices~~

~~to be used with the cryptographic module for the output of ~~

~~~~

~~status~~

~~information, signals, logical indicators, and physical indicators via~~

~~the~~

~~status output interface, such as smart cards, tokens, displays, ~~

~~~~

~~and/or~~

~~other storage devices.~~

Assessment:

~~AS.02.09All~~

~~external electrical power that is input to the cryptographic module ~~

~~~~

~~(including~~

~~power from an external power source or batteries) shall enter~~

~~via~~

~~a power port.~~

~~ ~~

~~~~

Assessment:

~~VE.02.09.01If~~

~~the cryptographic module requires or provides power to/from other ~~

~~~~

~~devices~~

~~external to the boundary (e.g., a power supply or a external ~~

~~~~

~~battery),~~

~~vendor documentation shall specify a power interface and a ~~

~~~~

~~corresponding~~

~~physical port. All power entering or exiting the ~~

~~~~

~~cryptographic~~

~~module to/from other devices external to the ~~

~~~~

~~cryptographic~~

~~boundary shall pass through the specified power ~~

~~~~

Assessment:

~~ ~~

~~~~

~~AS.02.10The~~

~~cryptographic module shall distinguish between data and control ~~

~~~~

~~for~~

~~input and data and status for output.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.02.10.01Vendor~~

~~documentation shall specify how the cryptographic module ~~

~~~~

~~distinguishes~~

~~between data and control for input and data and status for ~~

~~~~

~~output,~~

~~and how the physical and logical paths followed by the input ~~

~~~~

~~data~~

~~and control information entering the module via the applicable ~~

~~~~

~~input~~

~~interfaces are logically or physically disconnected from the ~~

~~~~

~~physical~~

~~and logical paths followed by the output data and status ~~

~~~~

~~information~~

~~exiting the module via the applicable output interfaces.~~

Assessment:

~~AS.02.11All~~

~~input data entering the cryptographic module via the "data~~

~~input" ~~

~~~~

~~interface~~

~~shall only pass through the input data path.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.02.11.01Vendor~~

~~documentation shall specify the physical and logical paths used ~~

~~~~

~~by~~

~~all major categories of input data entering the cryptographic module ~~

~~~~

~~via~~

~~the data input interface and the applicable physical ports. The ~~

~~~~

~~documentation~~

~~shall include a specification of the applicable paths (e.g.,~~

~~by~~

~~highlighted or annotated copies of the schematics, block diagrams, ~~

~~~~

~~or~~

~~other information provided under AS01.08, AS01.09, and AS01.13).~~

~~All~~

~~input data entering the cryptographic module via the data input ~~

~~~~

~~interface~~

~~shall only use the specified paths while being processed or ~~

~~~~

~~stored~~

~~by each physical or logical sub-section of the module.~~

Assessment:

~~AS.02.12All~~

~~output data exiting the cryptographic module via the "data~~

~~output" ~~

~~~~

~~interface~~

~~shall only pass through the output data path.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.02.12.01Vendor~~

~~documentation shall specify the physical and logical paths used ~~

~~~~

~~by~~

~~all major categories of output data exiting the cryptographic module ~~

~~~~

~~via~~

~~the data output interface and the applicable physical ports. The ~~

~~~~

~~documentation~~

~~shall include a specification of the applicable paths (e.g.,~~

~~by~~

~~highlighted or annotated copies of the schematics, block diagrams, ~~

~~~~

~~or~~

~~other information provided under AS01.08, AS01.09, and AS01.13).~~

~~All~~

~~output data exiting the cryptographic module via the data output ~~

~~~~

~~interface~~

~~shall only use the specified paths.~~

Assessment:

~~ ~~

~~~~

~~AS.02.13The~~

~~output data path shall be logically disconnected from the circuitry ~~

~~~~

~~and~~

~~processes while performing key generation, manual key entry, or ~~

~~~~

~~key~~

~~zeroization.~~

~~ ~~

~~~~

Assessment:

~~VE.02.13.01Vendor~~

~~documentation shall specify how the physical and logical paths ~~

~~~~

~~used~~

~~by all major categories of output data exiting the cryptographic ~~

~~~~

~~module~~

~~are logically or physically disconnected from the processes ~~

~~~~

~~performing~~

~~key generation, manual key entry, and zeroization of ~~

~~~~

~~cryptographic~~

~~keys and CSPs. The cryptographic module shall not ~~

~~~~

~~allow~~

~~the specified key processes to pass key/CSP information to the ~~

~~~~

~~output~~

~~data path, and shall not allow output data exiting the module to ~~

~~~~

~~interfere~~

~~with the key processes.~~

Assessment:

~~AS.02.14To~~

~~prevent the inadvertent output of sensitive information, two ~~

~~~~

~~independent~~

~~internal actions shall be required to output data via any ~~

~~~~

~~output~~

~~interface through which plaintext cryptographic keys or CSPs or ~~

~~~~

~~sensitive~~

~~data are output (e.g., two different software flags are set, one ~~

~~~~

~~of~~

~~which may be user initiated; or two hardware gates are set serially ~~

~~~~

Assessment:

~~VE.02.14.01If~~

~~the cryptographic module allows plaintext cryptographic key ~~

~~~~

~~components~~

~~or other unprotected CSPs to be output on one or more ~~

~~~~

~~physical~~

~~ports, two independent internal actions shall be performed by ~~

~~~~

~~the~~

~~module before the plaintext cryptographic key components or other ~~

~~~~

~~unprotected~~

~~CSPs may be output. Vendor documentation shall specify ~~

~~~~

~~the~~

~~two independent internal actions performed and how the two ~~

~~~~

~~independent~~

~~internal actions protect against the inadvertent release of ~~

~~~~

~~the~~

~~plaintext cryptographic key components or other unprotected CSPs.~~

Assessment:

AS.02.15Documentation

~~shall specify the physical ports and logical interfaces ~~

~~~~

~~and~~

~~all defined input and output data paths.Note: This assertion is not ~~

~~~~

~~separately~~

~~tested. Verification of vendor documentation is performed ~~

~~~~

~~under~~

~~assertions AS02.01 to AS02.14 and AS02.16 to AS02.18.~~

Assessment:

~~ ~~

~~~~

~~~~

~~ ~~

~~~~

~~SECTION~~

~~3: ROLES, SERVICES, AND AUTHENTICATION~~

~~AS.03.01The~~

~~cryptographic module shall support authorized roles for operators ~~

~~~~

~~and~~

~~corresponding services within each role.~~

~~Note:~~

~~This assertion is not separately tested.~~

~~ ~~

~~~~

Assessment:

~~AS.03.02If~~

~~the cryptographic module supports concurrent operators, then the ~~

~~~~

~~module~~

~~shall internally maintain the separation of the roles assumed by ~~

~~~~

~~each~~

~~operator and the corresponding services.~~

~~ ~~

~~~~

Assessment:

~~VE.03.02.01The~~

~~vendor documentation shall specify whether multiple concurrent ~~

~~~~

~~operators~~

~~are allowed. The vendor shall describe the method by which ~~

~~~~

~~separation~~

~~of the authorized roles and services performed by each ~~

~~~~

~~operator~~

~~is achieved. The vendor documentation shall also describe ~~

~~~~

~~any~~

~~restrictions on concurrent operators (e.g., one operator in a ~~

~~~~

~~maintenance~~

~~role and another in a user role simultaneously is not ~~

~~~~

Assessment:

~~AS.03.03The~~

~~cryptographic module shall support the following authorized roles ~~

~~~~

~~for~~

~~operators:~~

~~User~~

~~Role. The role assumed to perform general security services, ~~

~~~~

~~including~~

~~cryptographic operations and other Approved security ~~

~~~~

~~functions.~~

~~Crypto~~

~~Officer Role: The role assumed to perform a set of ~~

~~~~

~~cryptographic~~

~~initialization or management functions (e.g., module ~~

~~~~

Assessment:

~~VE.03.03.01In~~

~~the documentation required to satisfy VE03.06.01, the vendor shall ~~

~~~~

~~include~~

~~at least one user role and one crypto-officer role.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.03.04If~~

~~the cryptographic module allows operators to perform maintenance ~~

~~~~

~~services,~~

~~then the module shall support the following authorized role:~~

*

~~Maintenance Role: The role assumed to perform physical maintenance~~

~~and/or logical maintenance services (e.g., hardware/software~~

~~diagnostics).~~

Assessment:

~~VE.03.04.01If~~

~~the module has a maintenance interface, the vendor documentation ~~

~~~~

~~shall~~

~~explicitly state a maintenance role is supported. The ~~

~~~~

~~documentation~~

~~shall completely specify the role by name and allowed ~~

~~~~

~~ ~~

~~~~

Assessment:

~~AS.03.05All~~

~~plaintext secret and private keys and unprotected CSPs shall be ~~

~~~~

~~zeroized~~

~~when entering or exiting the maintenance role.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.03.05.01The~~

~~vendor documentation shall specify how the module's plaintext ~~

~~~~

~~secret~~

~~and private keys and other unprotected critical security ~~

~~~~

~~parameters,~~

~~as defined in Section 2.1 of FIPS PUB 140-2, are actively ~~

~~~~

~~zeroized~~

~~when the maintenance role is entered or exited.~~

Assessment:

AS.03.06Documentation

~~shall specify all authorized roles supported by the ~~

~~~~

~~cryptographic~~

~~module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.03.06.01Vendor~~

~~documentation shall specify each distinct authorized role, ~~

~~~~

~~including~~

~~its name and the services that are performed in the role.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.03.07Services~~

~~shall refer to all of the services, operations, or functions that ~~

~~~~

~~can~~

~~be performed by the cryptographic module.~~

~~Note:~~

~~This assertion is not separately tested.~~

~~ ~~

~~~~

Assessment:

~~AS.03.08Service~~

~~inputs shall consist of all data or control inputs to the ~~

~~~~

~~cryptographic~~

~~module that initiate or obtain specific services, ~~

~~~~

~~operations,~~

~~or functions. ~~

~~~~

~~ ~~

~~~~

Assessment:

~~AS.03.09Service~~

~~outputs shall consist of all data and status outputs that result ~~

~~~~

~~from~~

~~services, operations, or functions initiated or obtained by service ~~

~~~~

~~inputs.~~

~~~~

~~~~

~~ ~~

~~~~

Assessment:

~~AS.03.10Each~~

~~service input shall result in a service output.~~

~~Note:~~

~~This assertion is not separately tested.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.03.11The~~

~~cryptographic module shall provide the following services to ~~

~~~~

~~operators:~~

~~Show~~

~~Status. Output the current status of the cryptographic module.~~

~~ ~~

~~~~

~~Perform~~

~~Self-Tests. Initiate and run the self-tests as specified in ~~

~~~~

~~Section~~

~~4.9.~~

~~Perform~~

~~Approved Security Function. Perform at least one Approved~~

Assessment:

~~VE.03.11.01The~~

~~vendor documentation shall describe the output of the current ~~

~~~~

~~status~~

~~of the module and the initiation and running of user callable ~~

~~~~

~~self-tests,~~

~~along with other services as specified by VE03.14.01 and ~~

~~~~

~~ ~~

~~~~

Assessment:

~~AS.03.12If~~

~~a cryptographic module implements a bypass capability, where ~~

~~~~

~~services~~

~~are provided without cryptographic processing (e.g., ~~

~~~~

~~transferring~~

~~plaintext through the module without encryption), then two ~~

~~~~

~~independent~~

~~internal actions shall be required to activate the capability ~~

~~~~

~~to~~

~~prevent the inadvertent bypass of plaintext data due to a single~~

~~error ~~

~~~~

~~(e.g.,~~

~~two different software or hardware flags are set, one of which ~~

~~~~

Assessment:

~~VE.03.12.01If~~

~~the module implements a bypass capability, the vendor ~~

~~~~

~~documentation~~

~~shall describe the bypass service as specified in ~~

~~~~

~~AS03.12.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.03.12.02The~~

~~finite state model and other vendor documentation shall indicate, ~~

~~~~

~~for~~

~~all transitions into an exclusive or alternating bypass state, two ~~

~~~~

~~independent~~

~~internal actions that are required to transition into each ~~

~~~~

~~ ~~

~~~~

Assessment:

~~AS.03.13If~~

~~the cryptographic module implements a bypass capability, where ~~

~~~~

~~services~~

~~are provided without cryptographic processing (e.g., ~~

~~~~

~~transferring~~

~~plaintext through the module without encryption), then the ~~

~~~~

~~module~~

~~shall show status to indicate whether ~~

~~~~

~~1)~~

~~the bypass capability is not activated, and the module is exclusively~~

~~~~

~~~~

~~providing~~

~~services with cryptographic processing (e.g., the plaintext is ~~

~~~~

~~encrypted),~~

~~2)~~

~~the bypass capability is activated and the module is exclusively~~

~~providing services without cryptographic processing (e.g., plaintext~~

~~data is not encrypted), or~~

~~3)~~

~~the bypass capability is alternately activated and deactivated and~~

~~the~~

~~module~~

~~is providing some services with cryptographic processing and ~~

~~~~

~~some~~

~~services without cryptographic processing (e.g., for modules with ~~

~~~~

~~multiple~~

~~communication channels, plaintext data is or is not encrypted ~~

~~~~

~~depending~~

~~on each channel configuration).~~

Assessment:

~~VE.03.13.01The~~

~~vendor documentation for the "Show Status" service shall~~

~~indicate ~~

~~~~

~~bypass~~

~~status.~~

~~ ~~

~~~~

~~Assessment:~~

AS.03.14Documentation

~~shall specify:~~

*

~~the services, operations, or functions provided by the cryptographic ~~

~~~~

~~module,~~

~~both Approved and non-Approved, and~~

*

~~for each service provided by the module, the service inputs, ~~

~~~~

~~corresponding~~

~~service outputs, and the authorized role(s) in which the ~~

~~~~

~~service~~

~~can be performed.~~

Assessment:

~~VE.03.14.01The~~

~~vendor documentation shall describe each service including ~~

~~~~

~~purpose~~

~~and function.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.03.14.02The~~

~~vendor documentation shall specify for each service, the service ~~

~~~~

~~inputs,~~

~~corresponding service outputs, and the authorized role or roles ~~

~~~~

~~in~~

~~which the service can be performed. Service inputs shall consist of ~~

~~~~

~~all~~

~~data or control inputs to the module that initiate or obtain specific~~

~~~~

~~~~

~~services,~~

~~operations, or functions. Service outputs shall consist of all ~~

~~~~

~~data~~

~~and status outputs that result from services, operations or functions~~

~~initiated~~

~~or obtained by service inputs.~~

Assessment:

AS.03.15Documentation

~~shall specify any services provided by the cryptographic~~

~~module~~

~~for which the operator is not required to assume an authorized ~~

~~~~

~~role,~~

~~and how these services do not modify, disclose, or substitute ~~

~~~~

~~cryptographic~~

~~keys and CSPs, or otherwise affect the security of the ~~

~~~~

Assessment:

~~VE.03.15.01The~~

~~vendor documentation shall describe each service, including its ~~

~~~~

~~purpose~~

~~and function.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.03.15.02The~~

~~vendor documentation shall specify, for each service, the service ~~

~~~~

~~inputs~~

~~and corresponding service outputs. Service inputs shall consist ~~

~~~~

~~of~~

~~all data or control inputs to the module that initiate or obtain~~

~~specific ~~

~~~~

~~services,~~

~~operations, or functions. Service outputs shall consist of all ~~

~~~~

~~data~~

~~and status outputs that result from the services, operations, or ~~

~~~~

~~functions~~

~~initiated or obtained by service inputs.~~

Assessment:

~~AS.03.21When~~

~~the cryptographic module is powered off and subsequently ~~

~~~~

~~powered~~

~~on, the results of previous authentications shall not be retained~~

~~and~~

~~the module shall require the operator to be re-authenticated.~~

~~ ~~

~~~~

Assessment:

~~VE.03.21.01The~~

~~vendor documentation shall describe how the results of previous ~~

~~~~

~~authentications~~

~~are cleared when the module is powered off.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.03.23If~~

~~the cryptographic module does not contain the authentication data ~~

~~~~

~~required~~

~~to authenticate the operator for the first time the module is ~~

~~~~

~~accessed,~~

~~then other authorized methods (e.g., procedural controls or ~~

~~~~

~~use~~

~~of factory-set or default authentication data) shall be used to~~

~~control~~

~~access~~

~~to the module and initialize the authentication mechanisms.~~

Assessment:

~~VE.03.23.01The~~

~~vendor documentation shall specify means to control access to the ~~

~~~~

~~module~~

~~before it is initialized.~~

~~ ~~

~~~~

~~Assessment:~~

AS.03.29Documentation

~~shall specify:~~

*

~~the authentication mechanisms supported by the cryptographic ~~

~~~~

~~module,~~

*

~~the types of authentication data required by the module to ~~

~~~~

~~implement~~

~~the supported authentication mechanisms,~~

*

~~the authorized methods used to control access to the module for the ~~

~~~~

~~first~~

~~time and initialize the authentication mechanisms, and~~

*

~~the strength of the authentication mechanisms supported by the ~~

~~~~

~~module.~~

Assessment:

~~AS.03.30If~~

~~authentication mechanisms are not supported by the cryptographic ~~

~~~~

~~module,~~

~~the module shall require that one or more roles either be ~~

~~~~

~~implicitly~~

~~or explicitly selected by the operator.~~

~~ ~~

~~~~

Assessment:

~~VE.03.30.01The~~

~~vendor shall document the type of authentication performed for the~~

~~module.~~

~~The vendor shall document the mechanisms used to perform ~~

~~~~

~~the~~

~~implicit or explicit selection of a role or set of roles and the ~~

~~~~

~~authentication~~

~~of the operator to assume the role(s).~~

Assessment:

~~VE.03.30.02The~~

~~vendor provided nonproprietary security policy shall provide a ~~

~~~~

~~description~~

~~of the roles, either implicit or explicit, that the operator can ~~

~~~~

~~assume.~~

~~ ~~

~~~~

Assessment:

~~VE.03.30.03The~~

~~vendor provided non-proprietary security policy shall provide ~~

~~~~

~~instructions~~

~~for the operator to assume either the implicit or explicit ~~

~~~~

~~roles.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~SECTION~~

~~4: FINITE STATE MODEL~~

~~AS.04.01The~~

~~operation of the cryptographic module shall be specified using a ~~

~~~~

~~finite~~

~~state (or equivalent) represented by a state transition diagram ~~

~~~~

~~and/or~~

~~a state transition table. (The state transition diagram and/or state ~~

~~~~

~~transition~~

~~table includes all operational and error states of the ~~

~~~~

~~cryptographic~~

~~module, the corresponding transitions from one state to ~~

~~~~

~~another,~~

~~the input events that cause transitions from one state to ~~

~~~~

~~another,~~

~~and the output events resulting from transitions from one state ~~

~~~~

~~to~~

~~another.)~~

Assessment:

~~AS.04.02The~~

~~cryptographic module shall include the following operational and ~~

~~~~

~~error~~

~~states:~~

~~Power~~

~~on/off states. States for primary, secondary, or backup power.~~

~~These~~

~~states may distinguish between power sources being applied to ~~

~~~~

~~the~~

~~cryptographic module.~~

~~Crypto~~

~~officer states. States in which the crypto officer services are ~~

~~~~

~~performed~~

~~(e.g., cryptographic initialization and key management).~~

~~Key/CSP~~

~~entry states. States for entering cryptographic keys and ~~

~~~~

~~CSPs~~

~~into the cryptographic module.~~

~~User~~

~~states. States in which authorized users obtain security services, ~~

~~~~

~~perform~~

~~cryptographic operations, or perform other Approved or ~~

~~~~

~~non-Approved~~

~~functions.~~

~~Self-test~~

~~states. States in which the cryptographic module is ~~

~~~~

~~performing~~

~~self-tests.~~

~~Error~~

~~states. States when the cryptographic module has encountered ~~

~~~~

~~an~~

~~error (e.g., failed a self-test or attempted to encrypt when missing ~~

~~~~

~~operational~~

~~keys or CSPs). Error states may include "hard" errors that ~~

~~~~

~~indicate~~

~~an equipment malfunction and that may require maintenance, ~~

~~~~

~~service~~

~~or repair of the cryptographic module, or recoverable "soft"~~

~~~~

~~~~

~~errors~~

~~that may require initialization or resetting of the module.~~

~~ ~~

~~~~

~~Note:~~

~~This assertion is tested as part of AS04.05.~~

Assessment:

~~AS.04.03Recovery~~

~~from error states shall be possible except for those caused by ~~

~~~~

~~hard~~

~~errors that require maintenance, service, or repair of the ~~

~~~~

~~cryptographic~~

~~module.~~

~~ ~~

~~~~

Assessment:

~~AS.04.04If~~

~~the cryptographic module contains a maintenance role, then a ~~

~~~~

~~maintenance~~

~~state shall be included.~~

~~Note:~~

~~This assertion is tested as part of AS04.05.~~

~~ ~~

~~~~

Assessment:

AS.04.05Documentation

~~shall include a representation of the finite state (or ~~

~~~~

~~equivalent)~~

~~using a state transition diagram and/or state transition table ~~

~~~~

~~that~~

~~shall specify:~~

*

~~all operational and error states of the cryptographic module,~~

*

~~the corresponding transitions from one state to another,~~

*

~~the input events, including data inputs and control inputs, that~~

~~cause ~~

~~~~

~~transitions~~

~~from one state to another, and~~

*

~~the output events, including internal module conditions, data ~~

~~~~

~~outputs,~~

~~and status outputs resulting from transitions from one state to ~~

~~~~

Assessment:

~~VE.04.05.01The~~

~~vendor shall provide a description of the finite state model. This ~~

~~~~

~~description~~

~~shall contain the identification and description of all states of~~

~~the~~

~~module, and a description of all corresponding state transitions. ~~

~~~~

~~The~~

~~descriptions of the state transitions shall include internal module ~~

~~~~

~~conditions,~~

~~data inputs and control inputs that cause transitions from ~~

~~~~

~~one~~

~~state to another, data outputs and status outputs resulting from ~~

~~~~

~~transitions~~

~~from one state to another.~~

Assessment:

~~ ~~

~~~~

~~SECTION~~

~~5: PHYSICAL SECURITY~~

~~ ~~

~~~~

~~N/A~~

~~~~

~~ ~~

~~~~

~~SECTION~~

~~6: OPERATIONAL ENVIRONMENT~~

~~AS.06.01If~~

~~the operational environment is a modifiable operational environment, ~~

~~~~

~~the~~

~~operating system requirements in Section 4.6.1 shall apply.~~

~~Note:~~

~~This assertion is not separately tested.~~

~~Passed~~

Assessment:

~~AS.06.03The~~

~~following requirements shall apply to operating systems for ~~

~~~~

~~Security~~

~~Level 1.~~

~~Note:~~

~~This assertion is tested as part of AS06.04 through AS06.08.~~

~~ ~~

~~~~

Assessment:

~~AS.06.04The~~

~~operating system shall be restricted to a single operator mode of ~~

~~~~

~~operation~~

~~(i.e., concurrent operators are explicitly excluded).~~

~~Note:~~

~~This requirement cannot be enforced by administrative documentation~~

~~and procedures, but must be enforced by the cryptographic module~~

~~itself.~~

Assessment:

~~VE.06.04.01The~~

~~vendor shall provide a description of the mechanism used to ensure~~

~~that~~

~~only one user at a time can use the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.06.05The~~

~~cryptographic module shall prevent access by other processes to ~~

~~~~

~~plaintext~~

~~private and secret keys, CSPs, and intermediate key ~~

~~~~

~~generation~~

~~values during the time the cryptographic module is ~~

~~~~

~~executing/operational.Note:~~

~~This requirement cannot be enforced by administrative documentation~~

~~and procedures, but must be enforced by ~~

~~~~

~~the~~

~~cryptographic module itself. Processes that are spawned by the ~~

~~~~

~~cryptographic~~

~~module are owned by the module and are not owned by ~~

~~~~

~~external~~

~~processes/operators.~~

Assessment:

~~VE.06.05.01The~~

~~vendor shall provide a description of the mechanism used to ensure~~

~~that~~

~~no other process can access private and secret keys, intermediate ~~

~~~~

~~key~~

~~generation values, and other CSPs, while the cryptographic process~~

~~is~~

~~in use.~~

Assessment:

AS.06.06Non-cryptographic

~~processes shall not interrupt the cryptographic ~~

~~~~

~~module~~

~~during execution.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.06.06.01The~~

~~vendor shall provide a description of the mechanism used to ensure~~

~~that~~

~~no other process can interrupt the cryptographic module during ~~

~~~~

~~execution.~~

~~ ~~

~~~~

Assessment:

~~AS.06.07All~~

~~cryptographic software and firmware shall be installed in a form that~~

~~protects~~

~~the software and firmware source and executable code from ~~

~~~~

~~unauthorized~~

~~disclosure and modification.~~

~~ ~~

~~~~

Assessment:

~~VE.06.07.01The~~

~~vendor shall provide a list of the cryptographic software and ~~

~~~~

~~firmware~~

~~that are stored on the cryptographic module and shall provide ~~

~~~~

~~a~~

~~description of the protection mechanisms used to prevent ~~

~~~~

~~unauthorized~~

~~disclosure and modification.~~

Assessment:

~~AS.06.08A~~

~~cryptographic mechanism using an Approved integrity technique ~~

~~~~

~~(e.g.,~~

~~an Approved message authentication code or digital signature ~~

~~~~

~~algorithm)~~

~~shall be applied to all cryptographic software and firmware ~~

~~~~

~~components~~

~~within the cryptographic module.~~

Assessment:

~~VE.06.08.01The~~

~~vendor shall provide documentation that identifies the technique ~~

~~~~

~~used~~

~~to maintain the integrity of the cryptographic software and ~~

~~~~

~~firmware~~

~~components.~~

Assessment:

~~ ~~

~~~~

~~SECTION~~

~~7: CRYPTOGRAPHIC KEY MANAGEMENT~~

~~AS.07.01Secret~~

~~keys, private keys, and CSPs shall be protected within the ~~

~~~~

~~cryptographic~~

~~module from unauthorized disclosure, modification, and ~~

~~~~

~~substitution.~~

~~ ~~

~~~~

Assessment:

~~VE.07.01.01The~~

~~vendor documentation shall describe the protection of all secret ~~

~~~~

~~keys,~~

~~private keys, and CSPs internal to the module. Protection shall ~~

~~~~

~~include~~

~~the implementation of mechanisms that protect against ~~

~~~~

~~unauthorized~~

~~disclosure, unauthorized modification, and unauthorized ~~

~~~~

Assessment:

~~AS.07.02Public~~

~~keys shall be protected within the cryptographic module against ~~

~~~~

~~unauthorized~~

~~modification and substitution.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.02.01The~~

~~vendor documentation shall describe the protection of all public ~~

~~~~

~~keys~~

~~against unauthorized modification and substitution.~~

~~ ~~

~~~~

~~Assessment:~~

AS.07.03Documentation

~~shall specify all cryptographic keys, cryptographic key ~~

~~~~

~~components,~~

~~and CSPs employed by the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.03.01The~~

~~vendor documentation shall provide a list all cryptographic keys, ~~

~~~~

~~cryptographic~~

~~key components, and CSPs used by the module.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.07.04If~~

~~a cryptographic module employs Approved or non-Approved RNGs ~~

~~~~

~~in~~

~~an Approved mode of operation, the data output from the RNG shall ~~

~~~~

~~pass~~

~~the continuous random number generator test as specified in ~~

~~~~

~~Section~~

~~4.9.2.~~

Assessment:

~~AS.07.05There~~

~~are no requirements for this assertion number.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.07.06Approved~~

~~deterministic RNGs shall be subject to the cryptographic ~~

~~~~

~~algorithm~~

~~test in Section 4.9.1.~~

~~Note:~~

~~This assertion is tested in AS09.13~~

~~ ~~

~~~~

Assessment:

AS.07.07Nondeterministic

~~RNGs shall comply with all applicable RNG ~~

~~~~

~~requirements~~

~~of this standard.~~

~~Note:~~

~~This assertion is not separately tested.~~

~~ ~~

~~~~

Assessment:

~~AS.07.08An~~

~~Approved RNG shall be used for the generation of cryptographic ~~

~~~~

~~keys~~

~~used by an Approved security function.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.08.01The~~

~~vendor shall provide documentation stating that an Approved RNG~~

~~is~~

~~used to generate keys. Approved RNGs can be found in Annex C to~~

~~FIPS~~

~~PUB 140-2.~~

~~ ~~

~~~~

Assessment:

~~AS.07.09The~~

~~seed and seed key shall not have the same value.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.09.01The~~

~~vendor shall provide documentation describing the method that ~~

~~~~

~~ensures~~

~~that the seed and seed key input to the Approved RNG do not ~~

~~~~

~~have~~

~~the same value.~~

~~ ~~

~~~~

Assessment:

AS.07.10Documentation

~~shall specify each RNG (Approved and non-Approved) ~~

~~~~

~~employed~~

~~by a cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.10.01The~~

~~vendor documentation shall specify all RNGs (Approved and ~~

~~~~

~~non-Approved)~~

~~used in the cryptographic module, their type (Approved~~

~~or~~

~~non-Approved) and how each RNG (Approved and non-Approved) ~~

~~~~

~~is~~

~~used within the cryptographic module.~~

Assessment:

AS.07.11Cryptographic

~~keys generated by the cryptographic module for use by ~~

~~~~

~~an~~

~~Approved algorithm or security function shall be generated using an ~~

~~~~

~~Approved~~

~~key generation method.~~

~~ ~~

~~~~

Assessment:

~~VE.07.11.01The~~

~~vendor shall provide documentation stating that an Approved key ~~

~~~~

~~generation~~

~~method is used to generate keys.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.07.12If~~

~~an Approved key generation method requires input from a RNG, ~~

~~~~

~~then~~

~~an Approved RNG that meets the requirements specified in ~~

~~~~

~~Section~~

~~4.7.1 shall be used.~~

~~Note:~~

~~This assertion is tested as part of AS07.04-AS07.08 and ~~

~~~~

Assessment:

AS.07.13Compromising

~~the security of the key generation method (e.g., guessing~~

~~the~~

~~seed value to initialize the deterministic RNG) shall require as~~

~~least ~~

~~~~

~~as~~

~~many operations as determining the value of the generated key.~~

~~ ~~

~~~~

Assessment:

~~VE.07.13.01The~~

~~vendor shall provide documentation that provides rationale stating ~~

~~~~

~~how~~

~~compromising the security of the key generation method (e.g., ~~

~~~~

~~guessing~~

~~the seed value to initialize the deterministic RNG) shall require ~~

~~~~

~~as~~

~~least as many operations as determining the value of the generated ~~

~~~~

Assessment:

~~AS.07.14If~~

~~a seed key is entered during the key generation process, entry of the~~

~~~~

~~~~

~~key~~

~~shall meet the key entry requirements specified in Section 4.7.4.~~

~~Note:~~

~~This assertion is tested as part of AS07.23.~~

~~ ~~

~~~~

Assessment:

~~AS.07.15If~~

~~intermediate key generation values are output from the cryptographic ~~

~~~~

~~module~~

~~upon completion of the key generation process, the values shall ~~

~~~~

~~be~~

~~output either 1) in encrypted form or 2) under split knowledge ~~

~~~~

~~ ~~

~~~~

Assessment:

~~VE.07.15.01Vendor~~

~~documentation shall indicate whether any intermediate key ~~

~~~~

~~generation~~

~~values are output from the module upon completion of the ~~

~~~~

~~key~~

~~generation process.~~

~~ ~~

~~~~

Assessment:

~~VE.07.15.02If~~

~~intermediate key generation values are output from the cryptographic ~~

~~~~

~~module~~

~~upon the completion of the key generation process, then the ~~

~~~~

~~documentation~~

~~shall specify that the values are output either 1) in ~~

~~~~

~~encrypted~~

~~form or 2) under split knowledge procedures.~~

Assessment:

AS.07.16Documentation

~~shall specify each of the key generation methods ~~

~~~~

~~(Approved~~

~~and non-Approved) employed by the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.16.01The~~

~~vendor shall provide documentation stating the key generation ~~

~~~~

~~methods~~

~~(Approved and non-Approved) employed by the cryptographic~~

~~module.~~

~~ ~~

~~~~

Assessment:

~~AS.07.17If~~

~~key establishment methods are employed by the cryptographic ~~

~~~~

~~module,~~

~~only Approved key establishment techniques shall be used.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.17.01The~~

~~vendor shall provide documentation stating that an Approved key ~~

~~~~

~~establishment~~

~~technique is used. Approved key establishment ~~

~~~~

~~techniques~~

~~can be found in Annex D to FIPS PUB 140-2.~~

~~ ~~

~~~~

Assessment:

~~AS.07.18If,~~

~~in lieu of an Approved key establishment technique, a radio ~~

~~~~

~~communications~~

~~cryptographic module implements ~~

~~~~

~~Over-The-Air-Rekeying~~

~~(OTAR), it shall be implemented as specified ~~

~~~~

~~in~~

~~the TIA/EIA Telecommunications Systems Bulletin, APCO Project ~~

~~~~

~~25,~~

~~Over-The-Air-Rekeying (OTAR) Protocol, New Technology ~~

~~~~

~~Standards~~

~~Project, Digital Radio Technical Standards, TSB102.AACA, ~~

~~~~

~~January,~~

~~1996, Telecommunications Industry Association.~~

Assessment:

~~VE.07.18.01Vendor~~

~~documentation shall indicate whether the cryptographic module ~~

~~~~

~~is~~

~~used for radio communications. If so, and the module implements ~~

~~~~

~~the~~

~~OTAR Protocol, the vendor shall provide documentation stating ~~

~~~~

~~that~~

~~the OTAR implementation complies with APCO Project 25, ~~

~~~~

Assessment:

~~SECTION~~

~~7: CRYPTOGRAPHIC KEY MANAGEMENT~~

~~Page~~

~~32 of 59~~

~~~~

~~ ~~

~~~~

AS.07.19Compromising

~~the security of the key establishment method (e.g., ~~

~~~~

~~compromising~~

~~the security of the algorithm used for key establishment) ~~

~~~~

~~shall~~

~~require as many operations as determining the value of the ~~

~~~~

~~cryptographic~~

~~key being transported or agreed upon.~~

Assessment:

~~VE.07.19.01The~~

~~vendor shall provide documentation that provides rationale stating ~~

~~~~

~~how~~

~~compromising the security of the key establishment method (e.g., ~~

~~~~

~~compromising~~

~~the security of the algorithm used for key establishment) ~~

~~~~

~~shall~~

~~require as many operations as determining the value of the ~~

~~~~

~~cryptographic~~

~~key being transported or agreed upon.~~

Assessment:

~~AS.07.20If~~

~~a key transport method is used, the cryptographic key being ~~

~~~~

~~transported~~

~~shall meet the key entry/output requirements of Section ~~

~~~~

~~4.7.4.~~

~~ ~~

~~~~

Assessment:

AS.07.21Documentation

~~shall specify the key establishment methods employed ~~

~~~~

~~by~~

~~the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.21.01The~~

~~vendor shall provide documentation stating the key establishment ~~

~~~~

~~methods~~

~~employed by the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.07.22If~~

~~cryptographic keys are entered into or output from the cryptographic ~~

~~~~

~~module,~~

~~the entry or output of keys shall be performed using either ~~

~~~~

~~manual~~

~~(e.g., via a keyboard) or electronic methods (e.g., smart ~~

~~~~

~~cards/tokens,~~

~~PC cards, or other electronic key loading devices).~~

~~Note:~~

~~This assertion is tested in AS07.28.~~

Assessment:

~~AS.07.23A~~

~~seed key, if entered during key generation, shall be entered in the ~~

~~~~

~~same~~

~~manner as cryptographic keys.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.23.01The~~

~~key management documentation shall describe the entry of the ~~

~~~~

~~seed~~

~~key.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.07.24All~~

~~encrypted secret and private keys, entered into or output from the ~~

~~~~

~~cryptographic~~

~~module and used in an Approved mode of operation, ~~

~~~~

~~shall~~

~~be encrypted using an Approved algorithm.~~

~~ ~~

~~~~

Assessment:

~~VE.07.24.01The~~

~~vendor shall supply documentation specifying the Approved ~~

~~~~

~~algorithms~~

~~used to encrypt secret and private keys entered into or ~~

~~~~

~~output~~

~~from the cryptographic module.~~

~~ ~~

~~~~

Assessment:

~~AS.07.25The~~

~~cryptographic module shall associate a key (secret, private, or ~~

~~~~

~~public)~~

~~entered into or output from the module with the correct entity ~~

~~~~

~~(i.e.,~~

~~person, group, or process) to which the key is assigned.~~

~~ ~~

~~~~

Assessment:

~~VE.07.25.01The~~

~~documented key entry/output procedures shall describe the ~~

~~~~

~~mechanisms~~

~~or procedures used to ensure that each key is associated ~~

~~~~

~~with~~

~~the correct entity.~~

~~ ~~

~~~~

Assessment:

AS.07.26Manually-entered

~~cryptographic keys (keys entered using manual ~~

~~~~

~~methods)~~

~~shall be verified during entry into the cryptographic module ~~

~~~~

~~for~~

~~accuracy using the manual key entry test specified in Section 4.9.2.~~

~~ ~~

~~~~

Assessment:

~~AS.07.27If~~

~~encrypted cryptographic keys or key components are manually ~~

~~~~

~~entered~~

~~into the cryptographic module, then the plaintext values of the ~~

~~~~

~~cryptographic~~

~~keys or key components shall not be displayed.~~

~~ ~~

~~~~

Assessment:

~~VE.07.27.01The~~

~~documented key entry procedures shall preclude the display of ~~

~~~~

~~plaintext~~

~~secret or private keys that result from the entry of encrypted ~~

~~~~

~~keys~~

~~or key components.~~

~~ ~~

~~~~

Assessment:

AS.07.28Documentation

~~shall specify the key entry and output methods ~~

~~~~

~~employed~~

~~by the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.28.01The~~

~~vendor documentation shall specify the key entry and output ~~

~~~~

~~methods~~

~~employed by the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.07.29For~~

~~Security Levels 1 and 2, secret and private keys established using ~~

~~~~

~~automated~~

~~methods shall be entered into and output from a ~~

~~~~

~~cryptographic~~

~~module in encrypted form.~~

~~ ~~

~~~~

Assessment:

~~VE.07.29.01The~~

~~vendor documentation shall specify keys that are established using ~~

~~~~

~~automated~~

~~methods. The vendor documentation shall state whether ~~

~~~~

~~these~~

~~keys are entered into and output in encrypted form.~~

~~ ~~

~~~~

Assessment:

AS.07.37Cryptographic

~~keys stored within the cryptographic module shall be ~~

~~~~

~~stored~~

~~either in plaintext form or encrypted form.~~

~~Note:~~

~~This assertion is tested under AS07.40.~~

~~ ~~

~~~~

Assessment:

~~AS.07.38Plaintext~~

~~secret and private keys shall not be accessible from outside the~~

~~cryptographic~~

~~module to unauthorized operators.~~

~~Note:~~

~~This assertion is tested under AS07.01.~~

~~ ~~

~~~~

Assessment:

~~AS.07.39The~~

~~cryptographic module shall associate the cryptographic key (secret,~~

~~private,~~

~~or public) stored within the module with the correct entity ~~

~~~~

~~(e.g.,~~

~~person, group, or process) to which the key is assigned.~~

~~ ~~

~~~~

Assessment:

~~VE.07.39.01Vendor~~

~~documentation on key storage shall describe the mechanisms or~~

~~procedures~~

~~used to ensure that each key is associated with the correct ~~

~~~~

~~entity.~~

~~ ~~

~~~~

~~Assessment:~~

AS.07.40Documentation

~~shall specify the key storage methods employed by the ~~

~~~~

~~cryptographic~~

~~module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.40.01The~~

~~vendor documentation shall specify the following information for ~~

~~~~

~~each~~

~~stored key:~~

~~a.~~

~~Type and identifier~~

~~b.~~

~~Storage location ~~

~~~~

~~c.~~

~~The form in which the key is stored (plaintext, encrypted form, under~~

~~split knowledge procedures). If the keys are stored in encrypted~~

~~form, specify the Approved algorithm used to encrypt the keys.~~

Assessment:

~~AS.07.41The~~

~~cryptographic module shall provide methods to zeroize all plaintext ~~

~~~~

~~secret~~

~~and private cryptographic keys and CSPs within the module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.07.41.01The~~

~~vendor documentation shall specify the following plaintext secret ~~

~~~~

~~and~~

~~private cryptographic keys and CSPs zeroization information:~~

~~a.~~

~~Zeroization techniques ~~

~~~~

~~b.~~

~~Restrictions when plaintext secret and private cryptographic keys ~~

~~~~

~~and~~

~~CSPs can be zeroized~~

~~c.~~

~~Plaintext secret and private cryptographic keys and CSPs that are ~~

~~~~

~~zeroized~~

~~~~

~~~~

~~d.~~

~~Plaintext secret and private cryptographic keys and CSPs that are ~~

~~~~

~~not~~

~~zeroized and rationale~~

~~e.~~

~~Rationale explaining how the zeroization technique is performed in a~~

~~time~~

~~that is not sufficient to compromise plaintext secret and private ~~

~~~~

~~keys~~

~~and CSPs~~

Assessment:

AS.07.42Documentation

~~shall specify the key zeroization methods employed by ~~

~~~~

~~a~~

~~cryptographic module.~~

~~Note:~~

~~This assertion is tested under AS07.41.~~

~~ ~~

~~~~

Assessment:

~~ ~~

~~~~

~~~~

~~SECTION~~

~~8: EMI/EMC~~

AS.08.01Cryptographic

~~modules shall meet the following requirements for ~~

~~~~

~~EMI/EMC.~~

~~Note:~~

~~This assertion is not separately tested.~~

~~ ~~

~~~~

Assessment:

~~AS.08.02Radios~~

~~are explicitly excluded from these requirements but shall meet all~~

~~applicable~~

~~FCC requirements. ~~

~~~~

~~Note:~~

~~The phrase "these requirements" refers to the requirements~~

~~in ~~

~~~~

~~FIPS~~

~~PUB 140-2.~~

Assessment:

~~VE.08.02.01The~~

~~vendor shall provide the name of the FCC Accredited Laboratory.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.08.02.02The~~

~~vendor shall provide the FCC ID number for the cryptographic ~~

~~~~

~~module.~~

~~ ~~

~~~~

~~Assessment:~~

AS.08.03Documentation

~~shall include proof of conformance to EMI/EMC ~~

~~~~

~~requirements.~~

~~Note:~~

~~This assertion is tested as part of AS08.04 and AS08.05.~~

~~ ~~

~~~~

Assessment:

~~AS.08.04The~~

~~cryptographic module shall (at a minimum) conform to the ~~

~~~~

~~EMI/EMC~~

~~requirements specified by 47 Code of Federal Regulations, ~~

~~~~

~~Part~~

~~15, Subpart B, Unintentional Radiators, Digital Devices, Class A ~~

~~~~

~~ ~~

~~~~

Assessment:

~~VE.08.04.01The~~

~~vendor shall provide evidence and documentation that indicates the~~

~~cryptographic~~

~~module conforms to the EMI/EMC requirements ~~

~~~~

~~specified~~

~~by 47 Code of Federal Regulations, Part 15, Subpart B, ~~

~~~~

~~Unintentional~~

~~Radiators, Digital Devices, Class A (i.e., for business ~~

~~~~

~~use):~~

Assessment:

~~~~

~~ ~~

~~~~

~~SECTION~~

~~9: SELF-TESTS~~

~~AS.09.01The~~

~~cryptographic module shall perform power-up self-tests and ~~

~~~~

~~conditional~~

~~self-tests to ensure that the module is functioning properly.~~

~~ ~~

~~~~

~~ ~~

~~~~

Assessment:

~~AS.09.02Power-up~~

~~self-tests shall be performed when the cryptographic module ~~

~~~~

~~is~~

~~powered up.~~

~~Note:~~

~~This assertion is tested as part of AS09.07.~~

~~ ~~

~~~~

Assessment:

AS.09.03Conditional

~~self-tests shall be performed when an applicable security ~~

~~~~

~~function~~

~~or operation is invoked (i.e., security functions for which ~~

~~~~

~~self-tests~~

~~are required).~~

~~Note:~~

~~This assertion is tested as part of AS09.07.~~

Assessment:

~~AS.09.04If~~

~~the cryptographic module fails a self-test, the module shall enter an~~

~~~~

~~~~

~~error~~

~~state and output an error indicator via the status output interface.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.04.01The~~

~~vendor shall document all error states associated with each self-test~~

~~and~~

~~shall indicate for each error state the expected error indicator.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.05The~~

~~cryptographic module shall not perform any cryptographic ~~

~~~~

~~operations~~

~~while in an error state.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.05.01See~~

~~VE02.06.01 for the vendor design requirement. The vendor design~~

~~shall~~

~~ensure that cryptographic operations cannot be performed while ~~

~~~~

~~the~~

~~module is in the error state.~~

~~ ~~

~~~~

Assessment:

~~AS.09.06All~~

~~data output via the data output interface shall be inhibited when an ~~

~~~~

~~error~~

~~state exists.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.06.01See~~

~~VE02.06.01 for the vendor design requirement. The vendor design~~

~~shall~~

~~ensure that cryptographic operations cannot be performed while ~~

~~~~

~~the~~

~~module is in an error state.~~

~~ ~~

~~~~

Assessment:

AS.09.07Documentation

~~shall specify:~~

*

~~the self-tests performed by the cryptographic module, including ~~

~~~~

~~power-up~~

~~and conditional tests,~~

*

~~the error states that the cryptographic module can enter when a ~~

~~~~

~~self-test~~

~~fails, and~~

*

~~the conditions and actions necessary to exit the error states and ~~

~~~~

~~resume~~

~~normal operation of the cryptographic module (i.e., this may ~~

~~~~

~~include~~

~~maintenance of the module, or returning the module to the ~~

~~~~

~~vendor~~

~~for servicing.)~~

Assessment:

~~VE.09.07.01The~~

~~vendor shall provide a list of all self-tests that the module can ~~

~~~~

~~perform.~~

~~This list shall include both power-up tests and conditional ~~

~~~~

~~tests.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.07.02For~~

~~each error condition, the vendor documentation shall provide the ~~

~~~~

~~condition~~

~~name, the events that can produce the condition, and the ~~

~~~~

~~actions~~

~~necessary to clear the condition and resume normal operation.~~

~~ ~~

~~~~

Assessment:

~~AS.09.08Power-up~~

~~tests shall be performed by the cryptographic module when ~~

~~~~

~~the~~

~~module is powered up (after being powered off, reset, rebooted, ~~

~~~~

~~etc.).~~

~~ ~~

~~~~

Assessment:

~~AS.09.09The~~

~~power-up tests shall be initiated automatically and shall not require~~

~~~~

~~~~

~~operator~~

~~intervention.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~VE.09.09.01The~~

~~vendor documentation shall require that the running of power-up ~~

~~~~

~~self-tests~~

~~not involve any inputs from or actions by the operator.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.10When~~

~~the power-up tests are completed, the results (i.e., indications of ~~

~~~~

~~success~~

~~or failure) shall be output via the "status output"~~

~~interface.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.10.01The~~

~~vendor shall document the indicator that the module outputs upon ~~

~~~~

~~successful~~

~~completion of the power-up self-tests.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.11All~~

~~data output via the output interface shall be inhibited when the~~

~~tests ~~

~~~~

~~are~~

~~performed.~~

~~Note:~~

~~This assertion is tested as part of AS02.06.~~

~~ ~~

~~~~

Assessment:

~~AS.09.12In~~

~~addition to performing the power-up tests when powered up, the ~~

~~~~

~~cryptographic~~

~~module shall permit operators to initiate the tests on ~~

~~~~

~~demand~~

~~for periodic testing of the module.~~

~~ ~~

~~~~

Assessment:

~~VE.09.12.01The~~

~~vendor shall describe the procedure by which an operator can ~~

~~~~

~~initiate~~

~~the power-up self-tests on demand. All of the power-up ~~

~~~~

~~self-tests~~

~~must be included.~~

~~ ~~

~~~~

Assessment:

~~AS.09.13The~~

~~cryptographic module shall perform the following power-up tests: ~~

~~~~

~~cryptographic~~

~~algorithm test, software/firmware integrity test, and ~~

~~~~

~~critical~~

~~functions test.~~

~~ ~~

~~~~

Assessment:

~~VE.09.13.01See~~

~~VE09.07.01 for the vendor requirement.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.16A~~

~~cryptographic algorithm test using a known answer shall be ~~

~~~~

~~conducted~~

~~for all cryptographic functions (e.g., encryption, decryption, ~~

~~~~

~~authentication~~

~~and random number generation) of each Approved ~~

~~~~

~~cryptographic~~

~~algorithm implemented by the cryptographic module.~~

Assessment:

~~VE.09.16.01See~~

~~VE09.07.01 for the vendor requirement.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.17If~~

~~the calculated output does not equal the known answer, the~~

~~known-answer test shall fail.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.17.01The~~

~~vendor documentation shall specify the method used to compare ~~

~~~~

~~the~~

~~calculated output with the known answer.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.17.02The~~

~~documentation shall show the transition into an error state and ~~

~~~~

~~output~~

~~of an error indicator when the two outputs are not equal.~~

~~ ~~

~~~~

~~Assessment:~~

AS.09.18Cryptographic

~~algorithms whose outputs vary for a given set of inputs ~~

~~~~

~~(e.g.,~~

~~the Digital Signature Algorithm) shall be tested using a ~~

~~~~

~~known-answer~~

~~test or shall be tested using a pair-wise consistency test.~~

~~ ~~

~~~~

Assessment:

~~VE.09.18.01See~~

~~VE09.07.01 for the vendor requirement.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.18.02The~~

~~vendor documentation shall specify and describe the test(s) which ~~

~~~~

~~is~~

~~implemented.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.19Message~~

~~digest algorithms shall have an independent known-answer test~~

~~or~~

~~the known-answer test shall be included with the associated ~~

~~~~

~~cryptographic~~

~~algorithm test (e.g., the Digital Signature Standard).~~

~~ ~~

~~~~

Assessment:

~~VE.09.19.01See~~

~~VE09.07.01 for the vendor requirement.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.19.02The~~

~~vendor documentation shall specify and describe the test(s) which ~~

~~~~

~~is~~

~~implemented.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.20If~~

~~the cryptographic module includes two independent implementations ~~

~~~~

~~of~~

~~the same cryptographic algorithm, then the outputs of two ~~

~~~~

~~implementations~~

~~shall be continuously compared.~~

~~ ~~

~~~~

Assessment:

~~VE.09.20.01See~~

~~VE09.07.01 for the vendor requirement.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.20.02The~~

~~vendor shall specify whether a known answer test or the ~~

~~~~

~~comparison~~

~~of the output of two independent cryptographic algorithm ~~

~~~~

~~implementations~~

~~(compared answer test) is used to test the module's ~~

~~~~

~~cryptographic~~

~~algorithm. If the compared answer test is used, the ~~

~~~~

~~vendor~~

~~shall document this fact.~~

Assessment:

~~AS.09.21If~~

~~the cryptographic module includes two independent implementations ~~

~~~~

~~of~~

~~the same cryptographic algorithm then, if the outputs of two ~~

~~~~

~~implementations~~

~~are not equal, the cryptographic algorithm test shall ~~

~~~~

~~fail.~~

Assessment:

~~AS.09.22A~~

~~software/firmware integrity test using an error detection code (EDC) ~~

~~~~

~~or~~

~~Approved authentication technique (e.g., an Approved message ~~

~~~~

~~authentication~~

~~code or digital signature algorithm) shall be applied to all ~~

~~~~

~~validated~~

~~software and firmware components within the cryptographic ~~

~~~~

~~module~~

~~when the module is powered up.~~

Assessment:

~~VE.09.22.01The~~

~~vendor documentation shall specify whether an error detection ~~

~~~~

~~code~~

~~(EDC) or a Approved authentication technique (e.g., an Approved~~

~~message~~

~~authentication code or digital signature algorithm) is implemented as~~

~~an integrity test for all software and firmware components.~~

Assessment

~~ ~~

~~~~

~~VE.09.22.02The~~

~~documentation shall describe the implemented integrity ~~

~~~~

~~mechanism.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.22.03If~~

~~the module implements an Approved authentication technique:~~

~~(1)~~

~~The vendor shall provide a validation certificate as specified in ~~

~~~~

~~VE01.12.01.~~

~~~~

~~~~

~~ ~~

~~~~

~~or~~

~~(2)~~

~~In the absence of a CMVP algorithm validation certificate issuing ~~

~~~~

~~process,~~

~~the vendor organization shall provide a written affirmation ~~

~~~~

~~asserting~~

~~that the authentication technique implemented in the module is~~

~~Approved.~~

Assessment:

~~AS.09.23If~~

~~the calculated result does not equal the previously generated result,~~

~~~~

~~~~

~~the~~

~~software/firmware test shall fail.~~

~~Note:~~

~~This assertion is tested as part of AS09.22.~~

~~ ~~

~~~~

Assessment:

~~AS.09.24If~~

~~an EDC is used, the EDC shall be at least 16 bits in length.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.24.01If~~

~~the module implements EDCs for software/firmware integrity, the ~~

~~~~

~~vendor~~

~~documentation shall indicate that the EDC is at least 16 bits in ~~

~~~~

~~length.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.25Other~~

~~security functions critical to the secure operation of the ~~

~~~~

~~cryptographic~~

~~module shall be tested when the module is powered up as~~

~~part~~

~~of the power-up tests.~~

~~Note:~~

~~This assertion is tested as part of AS09.27.~~

Assessment:

~~AS.09.26Other~~

~~critical security functions performed under specific conditions ~~

~~~~

~~shall~~

~~be tested as conditional tests.~~

~~Note:~~

~~This assertion is tested as part of AS09.27.~~

~~ ~~

~~~~

Assessment:

AS.09.27Documentation

~~shall specify all security functions critical to the secure ~~

~~~~

~~operation~~

~~of the cryptographic module and shall identify the applicable ~~

~~~~

~~power-up~~

~~tests and conditional tests performed by the module.~~

~~Note:~~

~~Critical functions are defined as those functions that, upon failure,~~

~~could~~

~~lead to the disclosure of CSPs. Examples of critical functions ~~

~~~~

~~include~~

~~but not limited to random number generation, operation of the ~~

~~~~

~~cryptographic~~

~~algorithm, and cryptographic bypass.~~

Assessment:

~~VE.09.27.01The~~

~~vendor shall provide documentation of all critical functions. For ~~

~~~~

~~each~~

~~critical function, the vendor shall indicate:~~

~~1.~~

~~The purpose of the critical function~~

~~2.~~

~~Which critical functions are tested by which power-up tests~~

~~3.~~

~~Which critical functions are tested by which conditional tests~~

Assessment:

~~AS.09.28Note:~~

~~There are no requirements for this assertion number.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.28.01Note:~~

~~There are no requirements for this assertion number.~~

~~ ~~

~~~~

~~Assessment:~~

AS.09.29Conditional

~~tests shall be performed by the cryptographic module when ~~

~~~~

~~the~~

~~conditions specified for the following tests occur: pair-wise ~~

~~~~

~~consistency~~

~~test, software/firmware load test, manual key entry test, ~~

~~~~

~~continuous~~

~~random number generator test, and bypass test.Note: This ~~

~~~~

~~assertion~~

~~is not separately tested.~~

Assessment:

~~AS.09.30If~~

~~the cryptographic module generates public or private keys, then the ~~

~~~~

~~following~~

~~pair-wise consistency tests for public and private keys shall be~~

~~performed.~~

~~Note:~~

~~This assertion is tested as part of AS09.31, and AS09.33.~~

Assessment:

~~AS.09.31If~~

~~the keys are used to perform an approved key transport method, then~~

~~the~~

~~public key shall encrypt a plaintext value. The resulting ciphertext ~~

~~~~

~~value~~

~~shall be compared to the original plaintext value. If the two ~~

~~~~

~~values~~

~~are equal, then the test shall fail. If the two values differ, then ~~

~~~~

~~the~~

~~private key shall be used to decrypt the ciphertext and the resulting~~

~~~~

~~~~

~~value~~

~~shall be compared to the original plaintext value. If the two values~~

~~are not equal, the test shall fail.~~

Assessment:

~~VE.09.31.01If~~

~~the keys are used to perform an approved key transport method, the ~~

~~~~

~~cryptographic~~

~~module shall test for pairwise consistency by applying the~~

~~public~~

~~key to a plaintext value. The resulting ciphertext shall be ~~

~~~~

~~compared~~

~~to the original plaintext to verify that they differ.~~

*

~~If the two values are equal, then the cryptographic module shall ~~

~~~~

~~enter~~

~~an error state and output an error indicator via the status~~

~~interface.~~

~~ ~~

~~~~

*

~~If the two values differ, then the private key shall be applied to~~

~~the ~~

~~~~

~~ciphertext~~

~~and the result shall be compared to the original plaintext.~~

Assessment:

~~AS.09.32Note:~~

~~There are no requirements for this assertion number.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.32.01Note:~~

~~There are no requirements for this assertion number.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.33If~~

~~the keys are used to perform the calculation and verification of~~

~~digital~~

~~signatures,~~

~~then the consistency of the keys shall be tested by the ~~

~~~~

~~calculation~~

~~and verification of a digital signature. If the digital signature ~~

~~~~

~~cannot~~

~~be verified, the test shall fail.~~

Assessment:

~~VE.09.33.01If~~

~~the public and private keys are to be used only for the calculation ~~

~~~~

~~and/or~~

~~verification of digital signatures, then the cryptographic module ~~

~~~~

~~shall~~

~~test for pairwise consistency by calculation and verification of a ~~

~~~~

~~signature.~~

~~If the signature cannot be verified, the test shall fail.~~

Assessment:

~~AS.09.34If~~

~~software or firmware components can be externally loaded into the ~~

~~~~

~~cryptographic~~

~~module, then the following software/firmware load tests ~~

~~~~

~~shall~~

~~be performed.~~

~~Note:~~

~~This assertion is tested as part of AS09.34, AS09.35, and ~~

~~~~

Assessment:

~~AS.09.35An~~

~~Approved authentication technique (e.g., an Approved message ~~

~~~~

~~authentication~~

~~code, digital signature algorithm, or HMAC) shall be ~~

~~~~

~~applied~~

~~to all validated software and firmware components when the ~~

~~~~

~~components~~

~~are externally loaded into the cryptographic module.~~

Assessment:

~~VE.09.35.01The~~

~~vendor documentation shall describe the Approved authentication ~~

~~~~

~~technique~~

~~used to protect the integrity of all externally loaded software ~~

~~~~

~~and~~

~~firmware components.~~

~~ ~~

~~~~

Assessment:

~~VE.09.35.02If~~

~~the module implements an Approved authentication technique:~~

~~(1)~~

~~The vendor shall provide a validation certificate as specified in ~~

~~~~

~~VE01.12.01.~~

~~~~

~~~~

~~ ~~

~~~~

~~or~~

~~(2)~~

~~In the absence of a CMVP algorithm validation certificate issuing ~~

~~~~

~~process,~~

~~the vendor organization shall provide a written affirmation ~~

~~~~

~~asserting~~

~~that the authentication technique implemented in the module is~~

~~Approved.~~

Assessment:

~~AS.09.36The~~

~~calculated result shall be compared with a previously generated ~~

~~~~

~~result.~~

~~If the calculated result does not equal the previously generated ~~

~~~~

~~result,~~

~~the software/firmware integrity test shall fail.~~

~~Note:~~

~~This assertion is tested as part of AS09.35.~~

Assessment:

~~AS.09.37If~~

~~cryptographic keys or key components are manually entered into the ~~

~~~~

~~cryptographic~~

~~module, then the following manual key entry tests shall ~~

~~~~

~~be~~

~~performed.~~

~~Note:~~

~~This assertion is not separately tested.~~

Assessment:

~~AS.09.38The~~

~~cryptographic key or key components shall have an EDC applied, ~~

~~~~

~~or~~

~~shall be entered using duplicate entries.~~

~~Note:~~

~~This assertion is tested as part of AS09.40.~~

~~ ~~

~~~~

Assessment:

~~AS.09.39If~~

~~an EDC is used, the EDC shall be at least 16 bits in length.~~

~~Note:~~

~~This assertion is tested as part of AS09.40.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.40If~~

~~the EDC cannot be verified, or the duplicate entries do not match, ~~

~~~~

~~the~~

~~test shall fail.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.09.40.01The~~

~~vendor shall document the manual key entry test. Depending on ~~

~~~~

~~whether~~

~~error detection codes or duplicate key entries are used, the ~~

~~~~

~~manual~~

~~key entry test shall include the following:~~

~~1.~~

~~Error detection codes (EDCs):~~

*

~~Description of EDC calculation algorithm~~

*

~~Description of verification process~~

*

~~Expected outputs for success or failure of test~~

~~2.~~

~~Duplicate key entries:~~

*

~~Description of verification process~~

*

~~Expected outputs for success or failure of test~~

Assessment:

~~VE.09.40.02If~~

~~EDCs are associated with keys, then the vendor documentation that ~~

~~~~

~~describes~~

~~the format of the cryptographic keys (see AS07.03) shall ~~

~~~~

~~include~~

~~fields for the error detection codes.~~

~~ ~~

~~~~

Assessment:

~~AS.09.41If~~

~~a cryptographic module employs Approved or non-Approved RNGs ~~

~~~~

~~in~~

~~an Approved mode of operation, the module shall perform the ~~

~~~~

~~following~~

~~continuous random number generator test on each RNG that ~~

~~~~

~~tests~~

~~for failure to a constant value.~~

~~Note:~~

~~This assertion is tested as part of AS09.42 and AS09.43.~~

Assessment:

~~AS.09.42If~~

~~each call to a RNG produces blocks of n bits (where n > 15), the~~

~~first~~

~~n-bit~~

~~block generated after power-up, initialization, or reset shall not be~~

~~used,~~

~~but shall be saved for comparison with the next n-bit block to be ~~

~~~~

~~generated.~~

~~Each subsequent generation of an n-bit block shall be ~~

~~~~

~~compared~~

~~with the previously generated block. The test shall fail if any~~

~~two~~

~~compared n-bit blocks are equal.~~

Assessment:

~~VE.09.42.01If~~

~~the module implements a random number generator, the vendor shall ~~

~~~~

~~document~~

~~the continuous random number generator test.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~AS.09.43If~~

~~each call to a RNG produces fewer than 16 bits, the first n bits ~~

~~~~

~~generated~~

~~after power-up, initialization, or reset (for some n > 15) shall ~~

~~~~

~~not~~

~~be used, but shall be saved for comparison with the next n ~~

~~~~

~~generated~~

~~bits. Each subsequent generation of n bits shall be compared ~~

~~~~

~~with~~

~~the previously generated n bits. The test fails if any two compared~~

~~n-bit~~

~~sequences are equal.~~

Assessment:

~~VE.09.43.01If~~

~~the module implements a random number generator, the vendor shall ~~

~~~~

~~document~~

~~the continuous random number generator test.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.09.44If~~

~~the cryptographic module implements a bypass capability where the ~~

~~~~

~~services~~

~~may be provided without cryptographic processing (e.g., ~~

~~~~

~~transferring~~

~~plaintext through the module), then the following bypass ~~

~~~~

~~tests~~

~~shall be performed to ensure that a single point of failure of ~~

~~~~

~~module~~

~~components will not result in the unintentional output of ~~

~~~~

~~plaintext.~~

Assessment:

~~AS.09.45The~~

~~cryptographic module shall test for the correct operation of the ~~

~~~~

~~services~~

~~providing cryptographic processing when a switch takes place ~~

~~~~

~~between~~

~~an exclusive bypass service and an exclusive cryptographic ~~

~~~~

~~ ~~

~~~~

Assessment:

~~VE.09.45.01If~~

~~the cryptographic module implements a bypass service, then the ~~

~~~~

~~vendor~~

~~shall implement a bypass test to verify the correct operation of ~~

~~~~

~~the~~

~~cryptographic service when a switch takes place between an ~~

~~~~

~~exclusive~~

~~bypass and an exclusive cryptographic service.~~

Assessment:

~~VE.09.45.02The~~

~~vendor shall provide a description of the test as defined in ~~

~~~~

~~AS09.48.~~

~~The bypass test shall demonstrate that, when switched to an ~~

~~~~

~~exclusive~~

~~cryptographic service, the module does not output plaintext ~~

~~~~

~~information~~

~~as defined in AS09.47. The test fails if the cryptographic ~~

~~~~

~~module~~

~~outputs plaintext information.~~

Assessment:

~~AS.09.46If~~

~~the cryptographic module can automatically alternate between a ~~

~~~~

~~bypass~~

~~service and a cryptographic service, providing some services ~~

~~~~

~~with~~

~~cryptographic processing and some services without cryptographic ~~

~~~~

~~processing,~~

~~then the module shall test for the correct operation of the ~~

~~~~

~~services~~

~~providing cryptographic processing when the mechanism ~~

~~~~

~~governing~~

~~the switching procedure is modified (e.g., an IP address~~

~~source/destination table).~~

Assessment:

~~VE.09.46.01If~~

~~the cryptographic module is designed to automatically alternate ~~

~~~~

~~between~~

~~a bypass service and a cryptographic service, then the vendor ~~

~~~~

~~shall~~

~~implement a bypass test to verify the correct operation of the ~~

~~~~

~~cryptographic~~

~~service when the mechanism governing the switching ~~

~~~~

~~procedure~~

~~is modified.~~

Assessment:

~~VE.09.46.02The~~

~~vendor shall provide a description of the test as defined in ~~

~~~~

~~AS09.48.~~

~~The bypass test shall demonstrate that when the mechanism ~~

~~~~

~~governing~~

~~the switching procedure is modified:~~

~~1.~~

~~The mechanism is verified not to have been altered since the last ~~

~~~~

~~modification.~~

~~If the mechanism has been altered, the cryptographic ~~

~~~~

~~module~~

~~shall enter an error state and output an error indicator to the ~~

~~~~

~~status~~

~~interface.~~

~~2.~~

~~The correct operation of the cryptographic service is verified by ~~

~~~~

~~demonstrating~~

~~that the module does not output plaintext information as ~~

~~~~

~~defined~~

~~in AS09.47. The test fails if the module outputs plaintext ~~

~~~~

~~information.~~

Assessment:

~~AS.09.47No~~

~~single point of failure shall result in the unintentional output of ~~

~~~~

~~plaintext.~~

~~Note:~~

~~This assertion is tested as part of AS09.45 and AS09.46.~~

~~ ~~

~~~~

Assessment:

AS.09.48Documentation

~~shall specify the mechanism or logic governing the ~~

~~~~

~~switching~~

~~procedure.~~

~~Note:~~

~~This assertion is tested as part of AS09.45 and AS09.46.~~

~~ ~~

~~~~

Assessment:

~~~~

~~ ~~

~~~~

~~SECTION~~

~~10: DESIGN ASSURANCE~~

~~AS.10.01A~~

~~configuration management system shall be implemented for the ~~

~~~~

~~cryptographic~~

~~module and module components within the cryptographic~~

~~boundary,~~

~~and for associated module documentation.~~

~~ ~~

~~~~

Assessment:

~~VE.10.01.01The~~

~~vendor documentation shall describe the configuration management~~

~~(CM)~~

~~system for the cryptographic module, module components, and ~~

~~~~

~~associated~~

~~module documentation.~~

~~ ~~

~~~~

Assessment:

~~AS.10.02Each~~

~~version of each configuration item (e.g., cryptographic module, ~~

~~~~

~~module~~

~~components, user guidance, security policy, and operating ~~

~~~~

~~system)~~

~~that comprises the module and associated documentation shall ~~

~~~~

~~be~~

~~assigned and labeled with a unique identification number.~~

Assessment:

~~VE.10.02.01The~~

~~vendor CM documentation shall include a configuration list of all ~~

~~~~

~~configuration~~

~~items. The CM documentation shall describe the method ~~

~~~~

~~used~~

~~to uniquely identify the configuration items.~~

~~ ~~

~~~~

Assessment:

~~VE.10.02.02The~~

~~vendor documentation shall describe the method used to uniquely ~~

~~~~

~~identify~~

~~the version of each configuration item being validated.~~

~~ ~~

~~~~

~~Assessment:~~

AS.10.03Documentation

~~shall specify the procedures for secure installation, ~~

~~~~

~~initialization,~~

~~and startup of the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.10.03.01The~~

~~vendor documentation shall describe the steps necessary for the ~~

~~~~

~~secure~~

~~installation, initialization, and start-up of the cryptographic ~~

~~~~

~~module.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.10.05The~~

~~following requirements shall apply to cryptographic modules for ~~

~~~~

~~Security~~

~~Level 1.~~

~~Note:~~

~~This assertion is tested as part of AS10.06 and AS10.07.~~

~~ ~~

~~~~

Assessment:

AS.10.06Documentation

~~shall specify the correspondence between the design of ~~

~~~~

~~the~~

~~hardware, software, and firmware components of the cryptographic~~

~~module~~

~~and the cryptographic module security policy.~~

~~ ~~

~~~~

Assessment:

~~VE.10.06.01The~~

~~vendor documentation shall describe how the hardware, software, ~~

~~~~

~~and~~

~~firmware design(s) corresponds to the security policy (rules of ~~

~~~~

~~operation)~~

~~of the cryptographic module.~~

~~ ~~

~~~~

Assessment:

~~AS.10.07If~~

~~the cryptographic module contains software or firmware components,~~

~~documentation~~

~~shall specify the source code for the software and ~~

~~~~

~~firmware~~

~~components, annotated with comments that clearly depict the ~~

~~~~

~~correspondence~~

~~of the components to the design of the module.~~

Assessment:

~~VE.10.07.01The~~

~~vendor shall supply a list of the names of all the software and ~~

~~~~

~~firmware~~

~~components contained in the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.10.07.02The~~

~~vendor shall supply an annotated source listing of each software ~~

~~~~

~~and~~

~~firmware component contained in the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.10.08If~~

~~the cryptographic module contains hardware components, ~~

~~~~

~~documentation~~

~~shall specify the schematics and/or Hardware ~~

~~~~

~~Description~~

~~Language (HDL) listings for the hardware components.~~

~~ ~~

~~~~

Assessment:

~~VE.10.08.01The~~

~~vendor shall supply a list of the hardware components contained in~~

~~the~~

~~cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~AS.10.21Crypto~~

~~officer guidance shall specify the administrative functions, ~~

~~~~

~~security~~

~~events, security parameters (and parameter values, as ~~

~~~~

~~appropriate),~~

~~physical ports, and logical interfaces of the cryptographic ~~

~~~~

~~module~~

~~available to the crypto officer.~~

~~Note:~~

~~This assertion is tested as part of AS10.23.~~

Assessment:

~~AS.10.22Crypto~~

~~officer guidance shall specify procedures on how to administer ~~

~~~~

~~the~~

~~cryptographic module in a secure manner.~~

~~Note:~~

~~This assertion is tested as part of AS10.23.~~

~~ ~~

~~~~

Assessment:

~~AS.10.23Crypto~~

~~officer guidance shall specify assumptions regarding user ~~

~~~~

~~behavior~~

~~that is relevant to the secure operation of the cryptographic ~~

~~~~

~~module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.10.23.01The~~

~~vendor documentation shall include the information listed in ~~

~~~~

~~AS10.21,~~

~~AS10.22 and AS10.23.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.10.23.02The~~

~~crypto officer nonproprietary guidance shall be available to the ~~

~~~~

~~crypto~~

~~officer.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.10.24User~~

~~guidance shall specify the Approved security functions, physical ~~

~~~~

~~ports,~~

~~and logical interfaces available to the users of the cryptographic ~~

~~~~

~~module~~

~~Note:~~

~~This assertion is tested as part of AS10.25.~~

Assessment:

~~AS.10.25User~~

~~guidance shall specify all user responsibilities necessary for the ~~

~~~~

~~secure~~

~~operation of the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.10.25.01The~~

~~vendor documentation shall include the information listed in ~~

~~~~

~~AS10.24~~

~~and AS10.25.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.10.25.02The~~

~~user nonproprietary guidance shall be available to the user.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~ ~~

~~~~

~~SECTION~~

~~11: MITIGATION OF OTHER ATTACKS~~

~~AS.11.01If~~

~~the cryptographic module is designed to mitigate one or more specific~~

~~attacks,~~

~~then the module's security policy shall specify the security ~~

~~~~

~~mechanisms~~

~~employed by the module to mitigate the attack(s).~~

~~Not~~

~~Applicable~~

Assessment:

~~VE.11.01.01The~~

~~vendor provided nonproprietary security policy shall specify ~~

~~~~

~~whether~~

~~the cryptographic module is designed to mitigate specific ~~

~~~~

~~attacks.~~

~~The vendor shall specify in the nonproprietary security policy ~~

~~~~

~~Not~~

~~Applicablethe security mechanism(s) implemented by the~~

~~cryptographic module to~~

~~mitigate~~

~~the attack(s).~~

Assessment:

~~VE.11.01.02The~~

~~vendor provided nonproprietary security policy shall indicate how ~~

~~~~

~~the~~

~~implemented mechanism(s) were shown to mitigate the attack(s).~~

~~Not~~

~~Applicable~~

~~Assessment:~~

~~ ~~

~~~~

~~~~

~~ ~~

~~~~

~~C:~~

~~CRYPTOGRAPHIC MODULE SECURITY POLICY~~

~~AS.14.01The~~

~~cryptographic module security policy shall be included in the ~~

~~~~

~~documentation~~

~~provided by the vendor.~~

~~ ~~

~~~~

~~Assessment:~~

~~VE.14.01A~~

~~diagram or image of the physical cryptographic module (if ~~

~~~~

~~appropriate)~~

~~shall be included in the security policy. The image may be~~

~~used~~

~~to indicate the security relevant features of the cryptographic ~~

~~~~

~~module~~

~~(e.g., tamper evidence, status indicator(s), user interface(s), ~~

~~~~

Assessment:

~~AS.14.02The~~

~~cryptographic module security policy shall consist of: a ~~

~~~~

~~specification~~

~~of the security rules, under which the cryptographic ~~

~~~~

~~module~~

~~shall operate, including the security rules derived from the ~~

~~~~

~~requirements~~

~~of the standard and the additional security rules imposed ~~

~~~~

~~by~~

~~the vendor.~~

Assessment:

~~AS.14.03The~~

~~specification shall be sufficiently detailed to answer the following ~~

~~~~

~~questions:~~

~~~~

~~~~

*

~~What access does operator X, performing service Y while in role Z, ~~

~~~~

~~have~~

~~to security-relevant data item W for every role, service, and ~~

~~~~

~~security-relevant~~

~~data item contained in the cryptographic module? ~~

~~~~

*

~~What physical mechanisms are implemented to protect the ~~

~~~~

~~cryptographic~~

~~module and what actions are required to ensure that the ~~

~~~~

~~physical~~

~~security of the module is maintained?~~

*

~~What security mechanisms are implemented in the cryptographic ~~

~~~~

~~module~~

~~to mitigate against attacks for which testable requirements are ~~

~~~~

~~not~~

~~defined in the standard? ~~

~~~~

~~Note:~~

~~This assertion is tested as part of AS14.05-AS14.09.~~

Assessment:

~~AS.14.04The~~

~~cryptographic module security policy shall be expressed in terms of~~

~~roles,~~

~~services, and cryptographic keys and CSPs. At a minimum, the~~

~~following~~

~~shall be specified:~~

*

~~an identification and authentication (I&A) policy,~~

*

~~an access control policy,* a physical security policy, and~~

*

~~a security policy for mitigation of other attacks.~~

~~Note:~~

~~This assertion is tested as part of AS14.05-AS14.09.~~

Assessment:

~~AS.14.05The~~

~~cryptographic module security policy shall specify an identification ~~

~~~~

~~and~~

~~authentication policy, including ~~

~~~~

*

~~all roles (e.g., user, crypto officer, and maintenance) and~~

~~associated ~~

~~~~

~~type~~

~~of authentication (e.g., identity-based, role-based, or none) and~~

*

~~the authentication data required of each role or operator (e.g., ~~

~~~~

~~password~~

~~or biometric data) and the corresponding strength of the ~~

~~~~

~~authentication~~

~~mechanism.~~

Assessment:

~~VE.14.05.01The~~

~~vendor shall specify all roles that may be assumed by an operator ~~

~~~~

~~of~~

~~the cryptographic module. This list shall include the User Role and ~~

~~~~

~~the~~

~~Crypto Officer Role (see AS03.03). If the cryptographic module ~~

~~~~

~~allows~~

~~for maintenance, the list shall include a Maintenance Role (see ~~

~~~~

~~AS03.04).~~

~~All other authorized roles shall be specified (see AS03.06).~~

Assessment:

~~VE.14.05.02For~~

~~Security Levels 2, 3, and 4, the vendor shall specify whether the ~~

~~~~

~~type~~

~~of authentication is identity-based or role-based for each of the ~~

~~~~

~~roles~~

~~listed in VE14.05.01. The vendor shall specify the authentication ~~

~~~~

~~data~~

~~required for each role (see AS03.17, AS03.19 and AS03.23). The~~

~~vendor~~

~~shall specify the strength of corresponding authentication ~~

~~~~

~~mechanisms~~

~~(see AS03.24, AS03.25, and AS03.28).~~

Assessment:

~~VE.14.05.03The~~

~~vendor shall utilize the tabular formats specified in Appendix C of ~~

~~~~

~~FIPS~~

~~PUB 140-2.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.14.06The~~

~~cryptographic module shall specify an access control policy. The ~~

~~~~

~~specification~~

~~shall be of sufficient detail to identify the cryptographic ~~

~~~~

~~keys~~

~~and CSPs the operator has access to while performing a service, ~~

~~~~

~~and~~

~~the type(s) of access the operator has to these parameters.~~

~~Note:~~

~~This assertion is not separately tested.~~

Assessment:

~~AS.14.07The~~

~~security policy shall specify:~~

*

~~all roles supported by the cryptographic module,~~

*

~~all services provided by the cryptographic module, ~~

~~~~

*

~~all cryptographic keys and CSPs employed by the cryptographic ~~

~~~~

~~module,~~

~~including~~

~~-~~

~~secret, private, and public cryptographic keys (both plaintext and ~~

~~~~

~~encrypted),~~

~~-~~

~~authentication data such as passwords or PINs, and~~

~~-~~

~~other security-relevant information (e.g., audited events and audit ~~

~~~~

~~data),~~

*

~~for each role, the services an operator is authorized to perform ~~

~~~~

~~within~~

~~that role, and~~

*

~~for each service within each role, the type(s) of access to the ~~

~~~~

~~cryptographic~~

~~keys and CSPs.~~

Assessment:

~~VE.14.07.01The~~

~~vendor shall specify all services that are provided to an authorized ~~

~~~~

~~role.~~

~~This list must include the Show Status Service and all Self-Test ~~

~~~~

~~Services~~

~~(see AS03.11). All other authorized roles shall be specified ~~

~~~~

~~ ~~

~~~~

Assessment:

~~VE.14.07.02For~~

~~each provided service within each authorized role, the vendor shall ~~

~~~~

~~specify~~

~~the allowed type(s) of access to security-related information, ~~

~~~~

~~including~~

~~secret and private cryptographic keys (both plaintext and ~~

~~~~

~~encrypted),~~

~~authentication data CSPs, and other protected information ~~

~~~~

~~(see~~

~~AS01.15).~~

Assessment:

~~VE.14.07.03The~~

~~vendor shall utilize the tabular format specified in Appendix C in ~~

~~~~

~~FIPS~~

~~PUB 140-2.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.14.08The~~

~~cryptographic module security policy shall specify a physical ~~

~~~~

~~security~~

~~policy, including: ~~

~~~~

*

~~the physical security mechanisms that are implemented in the ~~

~~~~

~~cryptographic~~

~~module (e.g., tamper-evident seals, locks, tamper ~~

~~~~

~~response~~

~~and zeroization switches, and alarms) and~~

*

~~the actions required by the operator(s) to ensure that physical ~~

~~~~

~~security~~

~~is maintained (e.g., periodic inspection of tamper-evident seals ~~

~~~~

~~and~~

~~zeroization switches).~~

Assessment:

~~VE.14.08.01The~~

~~vendor shall specify the physical security mechanisms that are ~~

~~~~

~~implemented~~

~~in the cryptographic module.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~VE.14.08.02The~~

~~vendor shall specify the actions required by the operator(s) to ~~

~~~~

~~ensure~~

~~that physical security is maintained.~~

~~ ~~

~~~~

~~Assessment:~~

~~AS.14.09The~~

~~cryptographic module security policy shall specify a security policy~~

~~for~~

~~mitigation of other attacks, including the security mechanisms ~~

~~~~

~~implemented~~

~~to mitigate the attacks.~~

~~ ~~

~~~~

Assessment:

~~VE.14.09.01The~~

~~vendor shall specify the security mechanisms of the cryptographic ~~

~~~~

~~module~~

~~that are designed to mitigate specific attacks. This specification~~

~~shall~~

~~indicate how the implemented mechanism(s) were shown to ~~

~~~~

~~mitigate~~

~~the attack(s) and shall describe any limitations of these ~~

~~~~

~~mechanisms~~

~~(i.e., specific conditions or circumstances under which the ~~

~~~~

~~mechanisms~~

~~are known to be ineffective).~~

Assessment:

~~VE.14.09.02The~~

~~vendor shall utilize the tabular format specified in Appendix C in ~~

~~~~

~~FIPS~~

~~PUB 140-2.~~

~~ ~~

~~~~

~~Assessment:~~

~~ ~~

~~~~

~~ ~~

~~~~

~~</body></html>~~

VE 01: Difference between revisions

Revision as of 23:27, 22 July 2005

Navigation menu

VE 01: Difference between revisions

Revision as of 23:27, 22 July 2005

Navigation menu

Search