VE 01
<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> </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>