F2009VE 09
Contents
- 1 SECTION 9: SELF-TESTS
- 2 VE.09.04.01
- 3 VE.09.05.01
- 4 VE.09.06.01
- 5 VE.09.07.01
- 6 VE.09.07.02
- 7 VE.09.09.01
- 8 VE.09.10.01
- 9 VE.09.12.01
- 10 VE.09.13.01
- 11 VE.09.16.01
- 12 VE.09.17.01
- 13 VE.09.17.02
- 14 VE.09.18.01
- 15 VE.09.18.02
- 16 VE.09.19.01
- 17 VE.09.19.02
- 18 VE.09.20.01
- 19 VE.09.20.02
- 20 VE.09.22.01
- 21 VE.09.22.03
- 22 VE.09.24.01
- 23 VE.09.27.01
- 24 VE.09.31.01
- 25 VE.09.33.01
- 26 VE.09.35.01
- 27 VE.09.35.02
- 28 VE.09.40.01
- 29 VE.09.40.02
- 30 VE.09.42.01
- 31 VE.09.43.01
- 32 VE.09.45.01
- 33 VE.09.45.02
- 34 VE.09.46.01
- 35 VE.09.46.02
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.01
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.01
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.01
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.01
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.02
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.01
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.01
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.01
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.01
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.01
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.01
VE.09.17.01The vendor documentation shall specify the method used to compare
the calculated output with the known answer.
Assessment:
VE.09.17.02
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.01
VE.09.18.01See VE09.07.01 for the vendor requirement.
Assessment:
VE.09.18.02
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.01
VE.09.19.01See VE09.07.01 for the vendor requirement.
Assessment:
VE.09.19.02
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.01
VE.09.20.01See VE09.07.01 for the vendor requirement.
Assessment:
VE.09.20.02
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.01
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.03
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.01
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.01
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:
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.01
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:
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.01
VE.09.33.01 If 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 and the module shall enter an error state and output an error indicator via the status interface.
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.01
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.02
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.01
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.02
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.01
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.01
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.01
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.02
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.01
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.02
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.