F2009VE 07

SECTION 7: CRYPTOGRAPHIC KEY MANAGEMENT

AS.07.01 Secret keys, private keys, and CSPs shall be protected within the cryptographic module from unauthorized disclosure, modification, and substitution.

Assessment:

VE.07.01.01

VE.07.01.01 The 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 substitution.

Assessment:

AS.07.02 Public keys shall be protected within the cryptographic module against unauthorized modification and substitution.

Assessment:

VE.07.02.01

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.01

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.01

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.01

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.01

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.01

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.01

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 key.

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.01

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.02

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.01

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.