The MDF PP v.1.1 and MDF PP v2.0 require that REKs and KEKs be symmetric keys (FCS_CKM_EXT.1 and FCS_CKM_EXT.3, respectively).  Can asymmetric keys be used as REKs and KEKs in a key hierarchy to meet the Data-at-Rest encryption and key storage requirements?

Modify FCS_CKM_EXT.1 as follows:

FCS_CKM_EXT.1.1 The TSF shall support a [selection: hardware-isolated, hardware-protected] REK with a [selection: symmetric, asymmetric] key of strength [selection: 112 bits, 128 bits, 192 bits, 256 bits].

FCS_CKM_EXT.1.2 System software on the TSF shall be able only to request [selection: encryption/decryption, NIST SP 800-108 key derivation] by the key and shall not be able to read, import, or export a REK.

FCS_CKM_EXT.1.3 A REK shall be generated by a RBG in accordance with FCS_RBG_EXT.1.

Application Note: Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 128 or 256 bits in order to correspond with FCS_COP.1(1). Asymmetric keys may be of any strength corresponding to FCS_CKM.1(1). Use of 192- or 256-bit key strengths will be required for products entering evaluation after Quarter 3, 2015.

In terms of this requirement, “hardware-isolated” and “hardware-protected” both imply a design such that a REK must be isolated from the rich OS such that the kernel of the OS may only request operations of this key and may not access the raw key material.  The distinction between the two regard where the raw key material is accessed. The raw key material of “hardware-isolated” REK(s) is solely available in a separate processor execution environment, isolated from the OS both in terms of processing and memory.  The raw key material of “hardware-protected” REK(s) is not available to any software and is computationally processed by hardware. If “hardware-protected” is selected, FCS_CKM_EXT.1.4 must be included in the ST.

The lack of a public/documented API for importing or exporting, when a private/undocumented API exists, is not sufficient to meet this requirement.

The requirements allow for either symmetric encryption/decryption, asymmetric encryption/decryption, or key derivation by a mode from SP800-108 by a REK.

The RBG used to generate a REK may be a RBG native to the hardware key container or may be an off-device RBG. If performed by an off-device RBG, the device manufacturer shall not be able to access a REK after the manufacturing process has been completed. The assurance activities for these two cases differ.

Assurance Activity:

The evaluator shall review the TSS to determine that a REK is supported by the product, that the TSS includes a description of the protection provided by the product for a REK, and that the TSS includes a description of the method of generation of a REK.

The evaluator shall verify that the description of the protection of a REK describes how any reading, import, and export of that REK is prevented. (For example, if the hardware protecting the REK is removable, the description should include how other devices are prevented from reading the REK.) The evaluator shall verify that the TSS describes how encryption/decryption/derivation actions are isolated so as to prevent applications and system-level processes from reading the REK while allowing encryption/decryption/derivation by the key.

If “hardware-isolated” is selected and REK(s) are isolated from the rich OS by a separate processor execution environment, the evaluator shall verify that the description includes how the rich OS is prevented from accessing the memory containing REK key material, which software is allowed access to the REK, how any other software in the execution environment is prevented from reading that key material, and what other mechanisms prevent the REK key material from being written to shared memory locations between the rich OS and the separate execution environment.

If key derivation is performed using a REK, the evaluator shall ensure that the TSS description 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. (Additional key expansion algorithms are defined in other NIST Special Publications.)

The evaluator shall verify that the generation of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements:

• If REK(s) is/are generated on-device, the TSS shall include a description of the generation mechanism including what triggers a generation, how the functionality described by FCS_RBG_EXT.1 is invoked, and whether a separate instance of the RBG is used for REK(s).
• If REK(s) is/are generated off-device, the TSS shall include evidence that the RBG meets FCS_RBG_EXT.1. This will likely necessitate a second set of RBG documentation equivalent to the documentation provided for the RBG assurance activities. In addition, the TSS shall describe the manufacturing process that prevents the device manufacturer from accessing any REKs.

Modify FCS_CKM_EXT.3 as follows:

FCS_CKM_EXT.3.1 The TSF shall use [selection: asymmetric KEKs of [assignment: security strength greater than or equal to 112 bits] security strength, [selection: 128-bit, 256-bit] symmetric KEKs] corresponding to at least the security strength of the keys encrypted by the KEK.

Application Note:

The ST author selects all applicable KEK types implemented by the TOE. Use of 192- or 256-bit key strengths will be required for products entering evaluation after Quarter 3, 2015.

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

a)      derive the KEK from a Password Authentication Factor using PBKDF and

[selection:

b)      generate the KEK using an RBG that meets this profile (as specified in FCS_RBG_EXT.1)

c)      generate the KEK using a key generation scheme that meets this profile (as specified in FCS_CKM.1(1))

d)     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 use a KDF (as described in SP 800-108), encrypting one key with another]].

Application Note:

The PBKDF is performed in accordance with FCS_COP.1(5).

It is expected that key generation derived from PBKDF, 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(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.

Assurance Activity:

The evaluator shall examine the key hierarchy 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 PBKDF 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 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.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 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(1) is invoked. The evaluator uses the description of the key generation functionality in FCS_CKM.1(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.  If a KDF is used, the evaluator shall ensure that the TSS description 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. (Additional key expansion algorithms are defined in other NIST Special Publications.)

Modify FCS_STG_EXT.2.2 as follows:

FCS_STG_EXT.2.2 DEKs and KEKs and [selection: long-term trusted channel key material, all software-based key storage, no other keys] shall be encrypted using one of the following methods: [selection: using a SP800-56B key establishment scheme, using AES in the [selection: Key Wrap (KW) mode, Key Wrap with Padding (KWP) mode, GCM, CCM, CBC mode]].

Application Note: The ST author selects which key encryption schemes are used by the TOE. This requirement refers only to KEKs as defined this PP and does not refer to those KEKs specified in other standards.

Assurance Activity:

The evaluator shall examine the key hierarchy description in the TSS section to verify that each DEK and software-stored key is encrypted according to FCS_STG_EXT.2.

The use of asymmetric keys in a key hierarchy had not previously been considered by the authors of the MDF PP. An asymmetric encryption scheme can provide similar protection of keys as a symmetric encryption scheme.