NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0366:  Flexibility in Password Conditioning in FCS_COP.1(5)

Publication Date
2018.10.12

Protection Profiles
PP_MD_V3.1

Other References
FCS_COP.1.1(5), FCS_CKM_EXT.3.2

Issue Description

There are ways to afford flexibility in mechanisms to prevent dictionary attacks.

Resolution

FCS_COP.1.1(5) is modified as follows:

FCS_COP.1.1(5):The TSF shall perform conditioning in accordance with a specified cryptographic algorithm HMAC-[selectionSHA-256SHA-384SHA-512]] using a salt, and [selection: PBKDF2 with [assignmentnumber of iterations] iterations, [assignment: key stretching function], no other functions] and output cryptographic key sizes [selection128256] that meet the following: NIST [selection: SP 800-132, no standard].

 

Application Note: The key cryptographic key sizes in the third selection should be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3

This password must be conditioned into a string of bits that forms the submask to be used as input into the KEK. Conditioning can be performed using one of the identified hash functions and may include a key stretching function; the method used is selected by the ST Author. If selected, NIST SP 800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function. 

Appendix A of NIST SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a key from a password and, therefore, increase the workload of performing a dictionary attack.

 

Evaluation Activity 

The evaluator shall check that the TSS describes the method by which the password is first encoded and then fed to the SHA algorithm and verify the SHA algorithm matches the first selection.

If a key stretching function, such as PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall be described The evaluator shall verify that the TSS contains a description of how the output of the hash function or key stretching function is used to form the submask that will be input into the function and is the same length as the KEK as specified in FCS_CKM_EXT.3

If any manipulation of the key is performed in forming the submask that will be used to form the KEK, that process shall be described in the TSS

No explicit testing of the formation of the submask from the input password is required. 

 

FCS_CKM_EXT.3.2 is modified as follows:

FCS_CKM_EXT.3.2: The TSF shall generate all KEKs using one of the following methods:

  • Derive the KEK from a Password Authentication Factor using according to FCS_COP.1.1(5) and

[selection:

  • Generate the KEK using an RBG that meets this profile (as specified in FCS_RBG_EXT.1),
  • Generate the KEK using a key generation scheme that meets this profile (as specified in FCS_CKM.1),
  • Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by [selection: using an XOR operation, concatenating the keys and using a KDF (as described in SP 800-108), concatenating the keys and using a KDF (as described in SP 800-56C), encrypting one key with another]

].

Application Note: The conditioning of passwords is performed in accordance with FCS_COP.1(5)

It is expected that key generation derived from conditioning, using an RBG or generation scheme, and through combination, will each be necessary to meet the requirements set out in this document. In particular, 
Figure 3 has KEKs of each type: KEK_3 is generated, KEK_1 is derived from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In Figure 3, KEK_3 may either be a symmetric key generated from an RBG or an asymmetric key generated using a key generation scheme according to FCS_CKM.1

If combined, the ST author shall describe which method of combination is used in order to justify that the effective entropy of each factor is preserved. 

The documentation of the product's encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product's key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagram(s). This documentation is not required to be part of the TSS - it can be submitted as a separate document and marked as developer proprietary. 

SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C).

 

Evaluation Activity 

The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all KEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs, software-based key storage, and KEKs) is encrypted by keys of equal or greater security strength using one of the selected methods. 

  • The evaluator shall review the TSS to verify that it contains a description of the conditioning  use to derive KEKs. This description must include the size and storage location of salts. This activity may be performed in combination with that for FCS_COP.1(5).
  • If the symmetric KEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.
  • If the KEK is generated according to an asymmetric key scheme, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_CKM.1 is invoked. The evaluator uses the description of the key generation functionality in FCS_CKM.1 or documentation available for the operational environment to determine that the key strength being requested is greater than or equal to 112 bits.
  • If the KEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR, a KDF, or encryption.


(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108. 

If "concatenating the keys and using a KDF (as described in (SP 800-56C)" is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step.

  • The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).
  • The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
    • If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
    • If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
  • The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
    • If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
    • If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).

If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the mode(s) that are supported. Table 3 maps the data fields to the notations used in SP 800-108 and SP 800-56C. 

Table 3: Notations used in SP 800-108 and SP 800-56C 

Data Fields

Notations

 

SP 800-108

SP 800-56C

Pseudorandom function

PRF

PRF

Counter length

r

r

Length of output of PRF

h

h

Length of derived keying material

L

L

Length of input values

I_length

I_length

Pseudorandom input values I

K1 (key derivation key)

Z (shared secret)

Pseudorandom salt values

n/a

s

Randomness extraction MAC

n/a

MAC



Counter Mode Tests: 

The evaluator shall determine the following characteristics of the key derivation function:

  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Location of the counter relative to fixed input data: before, after, or in the middle.
    • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
    • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
    • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.


For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. 

The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. 

Feedback Mode Tests: 
The evaluator shall determine the following characteristics of the key derivation function:

  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Whether or not zero-length IVs are supported.
  • Whether or not a counter is used, and if so:
    • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
    • Location of the counter relative to fixed input data: before, after, or in the middle.
      • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.


For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. 

For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. 

Double Pipeline Iteration Mode Tests: 

The evaluator shall determine the following characteristics of the key derivation function: 

  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Whether or not a counter is used, and if so:
    • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
    • Location of the counter relative to fixed input data: before, after, or in the middle.
      • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.


For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. 

For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

Justification

See issue description.

 
 
Site Map              Contact Us              Home