Archived TD0046: Asymmetric KEK Modification
FCS_CKM_EXT.7.1 requirement that currently reads “The [selection: TSF, TOE environment] shall generate a hardware-protected REK with an AES key of size [selection: 128-bit, 256-bit].” does not allow for the use of asymmetric keys.
Modify FCS_CKM_EXT.1(2) as follows:
FCS_CKM_EXT.1.1(2) The [selection: TSF, TOE environment] shall be able to generate
[selection: asymmetric KEKs of [assignment: security strength greater than or equal to 112 bits] security strength in accordance with FCS_CKM.1(1), [selection: size 128-bit, 256-bit] symmetric KEKS from
There are two major types of keys: data encryption keys (DEKs) and key encryption keys (KEKs). KEKs are used to protect other keys - DEKs, other KEKs, and other types of keys stored by the user or applications. This requirement addresses the generation of KEKs used to protect other keys but not used to archive those keys.
The ST author can select asymmetric or symmetric KEKs (or both). If asymmetric KEKs are selected, the security strength corresponding to the modulus (per FCS_CKM.1(1) will be in assigned in the requirement in the ST. If symmetric generation is chosen, then the size of the symmetric key is assigned, and the method or methods of generating the symmetric KEKs also will need to be selected.
For the generation of symmetric KEKs, if any option but the RBG option is selected, FCS_CKM_EXT.7 in Annex C must be included. Use of 192- or 256-bit key strengths will be required for products entering evaluation after Quarter 3, 2015.
Modify the TSS Assurance Activity for FCS_CKM_EXT.1(2) as follows:
For KEKs generated using an RBG, the evaluator shall examine the TSS of the TOE to verify that it describes, for either the TOE or the TOE environment, how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator shall review the TSS and other evidence to determine that the key size being requested from the RBG is identical to the key size used for the encryption/decryption of the data or key.
For KEKs 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.
For each KEK that is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and contains a justification for preserving the effective entropy.
Modify FCS_CKM_EXT.1.1(3) as follows:
FCS_CKM_EXT.1(3) Extended: Key Generation for Key Encryption Keys (TOE Key Archival)
FCS_CKM_EXT.1.1(3) The [selection: TSF, TOE environment] shall be able to generate KEKs of [selection: [assignment: security strength greater than or equal to 112 bits] security strength, [selection: 128-bit, 256-bit] key size] for the archival of TOE keys from two or more shares according to a key sharing mechanism.
Modify FCS_STG_EXT.1 as follows:
FCS_STG_EXT.1.1 Persistent private and secret keys shall be stored
[selection: encrypted within the [selection: TSF, TOE environment] in accordance with
[selection: a SP800-56B key establishment scheme, FCS_COP.1(1) using
[selection AES-CBC, AES-CCM, AES-GCG, AES Key Wrap, or AES Key Wrap with Padding]
], in an environment-provided cryptographic module
This requirement ensures that persistent secret keys and private keys are stored securely when not in use. If some secrets/keys are manipulated by the TOE and others are manipulated by the environment, then both of the selections can be specified by the ST author and the ST author must identify in the TSS those keys which are manipulated by the TOE and those by the environment.
If the TOE is an application, and not a dedicated server, then it should store its private keys in the environment-provided key storage.
The ST author is responsible for selecting the manner in which the keys are stored and where they are stored in the selections above. Both asymmetric and symmetric key methods are supported. If asymmetric keys are used according to an SP800-56B scheme, the ST author ensures that appropriate selections are made in FCS_CKM.1(1).
Modify the TSS Assurance Activity for FCS_STG_EXT.1.1 as follows:
Regardless of whether this requirement is met by the TOE or the TOE environment, the evaluator will check the TSS to ensure that it lists each persistent secret and private key needed to meet the requirements in the ST. For each of these items, the evaluator will confirm that the TSS lists for what purpose it is used, and how it is stored. For protection schemes involving SP800-56B methods, the evaluator will ensure that the appropriate selections are made in FCS_CKM.1(1), and will determine that the ST contains a description of how the key is protected with respect to SP800-56B.
Modify FCS_CKM_EXT.7 as follows:
FCS_CKM_EXT.7.1 The [selection: TSF, TOE environment] shall support a REK with a [selection: symmetric, asymmetric] key of strength [selection: 112 bits, 128 bits, 192 bits, 256 bits].
FCS_CKM_EXT.7.2 A REK shall not be able to be read from or exported from the hardware.
FCS_CKM_EXT.7.3 System software on the TSF shall be able only to request encryption/decryption by the key and shall not be able to read, import, or export a REK.
FCS_CKM_EXT.7.4 A REK shall be generated [selection: by a RBG in accordance with FCS_RBG_EXT.1., according to FCS_CKM.1.1(1) ]
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.
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 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.
Modify the TSS Assurance Activity for FCS_CKM_EXT.7 as follows:
The evaluator shall examine 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.
If an asymmetric REK is generated, the evaluator shall verify that the description of the method of generation of a REK indicates how the mechanism adheres to FCS_CKM.1.(1) requirements.
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. The evaluator shall verify that the TSS describes how encryption/decryption actions are isolated so as to prevent applications and system-level processes from reading the REK while allowing encryption/decryption by the key.
REK generated by the TOE:
If a REK is generated by the TOE, 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).
REK generated by the TOE environment:
If a REK is generated by the TOE environment, the TSS shall include evidence that the RBG meets FCS_RBG_EXT.1.2. This will likely 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.
The use of asymmetric keys in a key hierarchy had not previously been considered by the authors of the CA PP. An asymmetric encryption scheme can provide similar protection of keys as a symmetric encryption scheme.