TD0351: Additional methods for DEK formation
Publication Date
2018.09.20
Protection Profiles
PP_MD_V3.1
Other References
FCS_CKM_EXT.2.1
Issue Description
The methods that MDFPP allows for KEK formation should be expanded to DEKs. Resolution
FCS_CKM_EXT.2.1: All DEKs shall be [selection: - randomly generated - from the combination of a randomly generated DEK with another DEK or salt 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)] with entropy corresponding to the security strength of AES key sizes of [selection: 128, 256] bits. Application Note: The intent of this requirement is to ensure that the DEK cannot be recovered with less work than a full exhaust of the key space for AES. The key generation capability of the TOE uses a RBG implemented on the TOE device (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes the selection appropriate for the device. A DEK is used in addition to the KEK so that authentication factors can be changed without having to re-encrypt all of the user data on the device. The ST author selects all applicable DEK generation types implemented by the TOE. 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, and the ST author shall describe that each combined value was originally generated from an Approved DRBG described in FCS_RBG_EXT.1 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). Assurance Activity TSS The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all DEKs 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 DEK is generated or combined from keys of equal or greater security strength using one of the selected methods.
- If the symmetric DEK 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.1 or 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 DEK 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, or a KDF. 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).
(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 or SP 800-56C. Guidance The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being generated or combined is identical to the key size and mode to be used for the encryption/decryption of the data. Tests 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
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. o Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. o Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. o 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: o One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). o 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: o One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). o 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. |