VE 07

From MozillaWiki
Revision as of 02:49, 25 November 2006 by Gfrewt (talk | contribs)
Jump to navigation Jump to search

==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.01Thevendor documentation shall describe the protection of all public

keysagainst unauthorized modification and substitution.


Assessment:

AS.07.03Documentationshall specify all cryptographic keys, cryptographic key

components,and CSPs employed by the cryptographic module.


Assessment:

==VE.07.03.01==

VE.07.03.01Thevendor documentation shall provide a list all cryptographic keys,

cryptographickey components, and CSPs used by the module.


Assessment:

AS.07.04Ifa cryptographic module employs Approved or non-Approved RNGs

inan Approved mode of operation, the data output from the RNG shall

passthe continuous random number generator test as specified in

Section4.9.2.

Assessment:

AS.07.05Thereare no requirements for this assertion number.


Assessment:

AS.07.06Approveddeterministic RNGs shall be subject to the cryptographic

algorithmtest in Section 4.9.1.

Note:This assertion is tested in AS09.13


Assessment:

AS.07.07NondeterministicRNGs shall comply with all applicable RNG

requirementsof this standard.

Note:This assertion is not separately tested.


Assessment:

AS.07.08AnApproved RNG shall be used for the generation of cryptographic

keysused by an Approved security function.


Assessment:

==VE.07.08.01==

VE.07.08.01Thevendor shall provide documentation stating that an Approved RNG

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

FIPSPUB 140-2.


Assessment:

AS.07.09Theseed and seed key shall not have the same value.


Assessment:

==VE.07.09.01==

VE.07.09.01Thevendor shall provide documentation describing the method that

ensuresthat the seed and seed key input to the Approved RNG do not

havethe same value.


Assessment:

AS.07.10Documentationshall specify each RNG (Approved and non-Approved)

employedby a cryptographic module.


Assessment:

==VE.07.10.01==

VE.07.10.01Thevendor documentation shall specify all RNGs (Approved and

non-Approved)used in the cryptographic module, their type (Approved

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

isused within the cryptographic module.

Assessment:

AS.07.11Cryptographickeys generated by the cryptographic module for use by

anApproved algorithm or security function shall be generated using an

Approvedkey generation method.


Assessment:

==VE.07.11.01==

VE.07.11.01Thevendor shall provide documentation stating that an Approved key

generationmethod is used to generate keys.


Assessment:

AS.07.12Ifan Approved key generation method requires input from a RNG,

thenan Approved RNG that meets the requirements specified in

Section4.7.1 shall be used.

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

Assessment:

AS.07.13Compromisingthe security of the key generation method (e.g., guessing

theseed value to initialize the deterministic RNG) shall require asleast

asmany operations as determining the value of the generated key.


Assessment:

==VE.07.13.01==

VE.07.13.01Thevendor shall provide documentation that provides rationale stating

howcompromising the security of the key generation method (e.g.,

guessingthe seed value to initialize the deterministic RNG) shall require

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

Assessment:

AS.07.14Ifa seed key is entered during the key generation process, entry of the

keyshall meet the key entry requirements specified in Section 4.7.4.

Note:This assertion is tested as part of AS07.23.


Assessment:

AS.07.15Ifintermediate key generation values are output from the cryptographic

moduleupon completion of the key generation process, the values shall

beoutput either 1) in encrypted form or 2) under split knowledge


Assessment:

==VE.07.15.01==

VE.07.15.01Vendordocumentation shall indicate whether any intermediate key

generationvalues are output from the module upon completion of the

keygeneration process.


Assessment:

==VE.07.15.02==

VE.07.15.02Ifintermediate key generation values are output from the cryptographic

moduleupon the completion of the key generation process, then the

documentationshall specify that the values are output either 1) in

encryptedform or 2) under split knowledge procedures.

Assessment:

AS.07.16Documentationshall specify each of the key generation methods

(Approvedand non-Approved) employed by the cryptographic module.


Assessment:

==VE.07.16.01==

VE.07.16.01Thevendor shall provide documentation stating the key generation

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

module.


Assessment:

AS.07.17Ifkey establishment methods are employed by the cryptographic

module,only Approved key establishment techniques shall be used.


Assessment:

==VE.07.17.01==

VE.07.17.01Thevendor shall provide documentation stating that an Approved key

establishmenttechnique is used. Approved key establishment

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


Assessment:

AS.07.18If,in lieu of an Approved key establishment technique, a radio

communicationscryptographic module implements

Over-The-Air-Rekeying(OTAR), it shall be implemented as specified

inthe TIA/EIA Telecommunications Systems Bulletin, APCO Project

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

StandardsProject, Digital Radio Technical Standards, TSB102.AACA,

January,1996, Telecommunications Industry Association.

Assessment:

==VE.07.18.01==

VE.07.18.01Vendordocumentation shall indicate whether the cryptographic module

isused for radio communications. If so, and the module implements

theOTAR Protocol, the vendor shall provide documentation stating

thatthe OTAR implementation complies with APCO Project 25,

Assessment:

SECTION7: CRYPTOGRAPHIC KEY MANAGEMENT

Page32 of 59


AS.07.19Compromisingthe security of the key establishment method (e.g.,

compromisingthe security of the algorithm used for key establishment)

shallrequire as many operations as determining the value of the

cryptographickey being transported or agreed upon.

Assessment:

==VE.07.19.01==

VE.07.19.01Thevendor shall provide documentation that provides rationale stating

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

compromisingthe security of the algorithm used for key establishment)

shallrequire as many operations as determining the value of the

cryptographickey being transported or agreed upon.

Assessment:

AS.07.20Ifa key transport method is used, the cryptographic key being

transportedshall meet the key entry/output requirements of Section

4.7.4.


Assessment:

AS.07.21Documentationshall specify the key establishment methods employed

bythe cryptographic module.


Assessment:

==VE.07.21.01==

VE.07.21.01Thevendor shall provide documentation stating the key establishment

methodsemployed by the cryptographic module.


Assessment:

AS.07.22Ifcryptographic 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.23Aseed key, if entered during key generation, shall be entered in the

samemanner as cryptographic keys.


Assessment:

==VE.07.23.01==

VE.07.23.01Thekey management documentation shall describe the entry of the

seedkey.


Assessment:

AS.07.24Allencrypted secret and private keys, entered into or output from the

cryptographicmodule and used in an Approved mode of operation,

shallbe encrypted using an Approved algorithm.


Assessment:

==VE.07.24.01==

VE.07.24.01Thevendor shall supply documentation specifying the Approved

algorithmsused to encrypt secret and private keys entered into or

outputfrom the cryptographic module.


Assessment:

AS.07.25Thecryptographic 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.01Thedocumented key entry/output procedures shall describe the

mechanismsor procedures used to ensure that each key is associated

withthe correct entity.


Assessment:

AS.07.26Manually-enteredcryptographic keys (keys entered using manual

methods)shall be verified during entry into the cryptographic module

foraccuracy using the manual key entry test specified in Section 4.9.2.


Assessment:

AS.07.27Ifencrypted cryptographic keys or key components are manually

enteredinto the cryptographic module, then the plaintext values of the

cryptographickeys or key components shall not be displayed.


Assessment:

==VE.07.27.01==

VE.07.27.01Thedocumented key entry procedures shall preclude the display of

plaintextsecret or private keys that result from the entry of encrypted

keysor key components.


Assessment:

AS.07.28Documentationshall specify the key entry and output methods

employedby the cryptographic module.


Assessment:

==VE.07.28.01==

VE.07.28.01Thevendor documentation shall specify the key entry and output

methodsemployed by the cryptographic module.


Assessment:

AS.07.29ForSecurity Levels 1 and 2, secret and private keys established using

automatedmethods shall be entered into and output from a

cryptographicmodule in encrypted form.


Assessment:

==VE.07.29.01==

VE.07.29.01Thevendor documentation shall specify keys that are established using

automatedmethods. The vendor documentation shall state whether

thesekeys are entered into and output in encrypted form.


Assessment:

AS.07.37Cryptographickeys stored within the cryptographic module shall be

storedeither in plaintext form or encrypted form.

Note:This assertion is tested under AS07.40.


Assessment:

AS.07.38Plaintextsecret and private keys shall not be accessible from outside the

cryptographicmodule to unauthorized operators.

Note:This assertion is tested under AS07.01.


Assessment:

AS.07.39Thecryptographic 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.01Vendordocumentation on key storage shall describe the mechanisms or

proceduresused to ensure that each key is associated with the correct

entity.


Assessment:

AS.07.40Documentationshall specify the key storage methods employed by the

cryptographicmodule.


Assessment:

==VE.07.40.01==

VE.07.40.01Thevendor documentation shall specify the following information for

eachstored key:

a.Type and identifier

b.Storage location

c.The form in which the key is stored (plaintext, encrypted form, undersplit knowledge procedures). If the keys are stored in encryptedform, specify the Approved algorithm used to encrypt the keys.

Assessment:

AS.07.41Thecryptographic module shall provide methods to zeroize all plaintext

secretand private cryptographic keys and CSPs within the module.


Assessment:

==VE.07.41.01==

VE.07.41.01Thevendor documentation shall specify the following plaintext secret

andprivate cryptographic keys and CSPs zeroization information:

a.Zeroization techniques

b.Restrictions when plaintext secret and private cryptographic keys

andCSPs 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

notzeroized and rationale

e.Rationale explaining how the zeroization technique is performed in a

timethat is not sufficient to compromise plaintext secret and private

keysand CSPs

Assessment:

AS.07.42Documentationshall specify the key zeroization methods employed by

acryptographic module.

Note:This assertion is tested under AS07.41.