VE 09

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.