NIAP: View Technical Decision Details
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0263:  Specification of key generation and use requirements in the Software File Encryption EP

Publication Date

Protection Profiles

Other References

Issue Description

There are multiple issues with the specification of key generation and use requirements in the Software File Encryption EP, including conflicts with the Application Software PP.  These include the specification of EC CDH has a key wrapping function, there being no provision for the generation of RSA keys that may be used in keychains, and a conflict between FCS_CKM_EXT.1 in the SW FE EP and a component with that same label in the App SW PP.


The following changes will be made to the SWFE EP.  Please note that this TD superseds TDs 76 and 92.

1.        The FCS_COP.1(5) SFR is modified to remove EC CDH, since it does not specify a key wrap function, and modify the application note and assurance activity.

FCS_COP.1(5)    Cryptographic operation (Key Wrapping)

FCS_COP.1.1(5)    Refinement: The application shall [selection: use platform-provided functionality to perform Key Wrapping, implement functionality to perform Key Wrapping] in accordance with a specified cryptographic algorithm


AES Key Wrap;

AES Key Wrap with Padding;

RSA using the KTS-OAEP-basic scheme;

RSA using the KTS-OAEP-receiver-confirmation scheme


and the cryptographic key size


128 bits (AES), 256 bits (AES), 2048 (RSA), 4096 (RSA)


that meet the following:


-          “NIST SP 800-38F” for Key Wrap (section 6.2) and Key Wrap with Padding (section 6.3)

-          “NIST SP 800-56B” for RSA using the KTS-OAEP-basic (section 9.2.3) and KTS-OAEP-receiver-confirmation (section9.2.4) scheme



Application Note:

This requirement specifies the protection of the FEK (that is, protecting it using the KEK specified in FCS_CKM_EXT.1) and unwrapping/decryption of the FEK with the KEK so that it may be used to encrypt or decrypt files or set of files.

This requirement allows the TSF to control how the FEK is encrypted and decrypted. When encrypting the FEK, the TSF may pass the FEK to the operational environment with various amounts of information. For instance, if 128-bit AES Key Wrap is being used, the TSF may invoke an interface specifying these parameters. If RSA is being used, the FEK may invoke a crypto-library and pass the private key and the FEK to the crypto-library; or it may invoke crypto-functionality on a smart card that contains the private key, so the TSF only passes the FEK.

In the first selection, the ST author chooses the entity that performs the decryption/encryption of the FEK. If one operation is done by the TOE platform (e.g., decryption of the FEK) and one operation is done by the TSF (e.g., encryption of the FEK), the ST author should iterate and refine the requirement to reflect this functionality. Iteration can also be used if the TOE supports either option; in this case the assurance activities will be performed for all claimed modes.


In the second selection, the ST author chooses the method by which the KEK is used to encrypt the FEK:

·             Using one of the two AES-based Key Wrap methods specified in NIST SP 800-38F;

·             Using one of the two the KTS-OAEP schemes for RSA as described in NIST SP 800-56B (KTS-OAEP-basic described in section 9.2.3.


Based on the method(s) chosen in the second selection, the last two selections should be used to indicate the appropriate key sizes and standard reference(s).

The Assurance Activity is modified as follows:

 The EC CDH test activity is removed.


2.       FCS_CKM.1(1) “Cryptographic Key Generation (for asymmetric keys) is removed from Annex C.2 as it will be replaced by the FCS_CKM.1 iterations in the underlying Application Software PP. 


3.       FCS_KYC_EXT.1 is modified below to add a supplemental key chain selection in FCS_KYC_EXT.1 for an ST-author-specified method of key chain protection.  This will help characterize implementations that do not conform to the listed methods. It is also modified via an application note to indicate conditions when the FCS_CKM.1 iterations from the App SW PP should be included in the ST.


FCS_KYC_EXT.1  Key Chaining and Key Storage

FCS_KYC_EXT.1.1  The TSF shall maintain a primary key chain of:


-          a conditioned password as the FEK;

-          KEKs originating from one or more authorization factors(s) to the FEK(s) using the following method(s):


        - utilization of the platform key storage;

        - utilization of platform key storage that performs key wrap with a TSF provided key;

        - implement key wrapping as specified in FCS_COP.1(5);

        - implement key combining as specified in FCS_SMC_EXT.1;

        - implement key encryption as specified in FCS_COP.1(1) in [selection: CBC, GCM] mode


       while maintaining an effective strength of [selection:

-          [selection: 128 bits, 256 bits] for symmetric keys;

-          [selection: 112 bits, 128 bits, 192 bits, 256 bits] for asymmetric keys;

     ] commensurate with the strength of the FEK] and [selection:

-          no supplemental key chains,

-          other supplemental key chains that protect a key or keys in the primary key chain using the following method(s):


-          utilization of the platform key storage

-          utilization of the platform key storage that performs key wrap with a TSF provided key,

-          implement key wrapping as specified in FCS_COP.1(5),

-          implement key combining as specified in FCS_SMC_EXT.1;

-          implement key encryption as specified in FCS_COP.1(1) in [selection: CBC, GCM] mode

-          [assignment: other protection method]



Application Note:

If any keys used in the keychain are generated by the TSF (for instance, an RSA Key Pair to be used in the KTS-OAEP scheme, or an EC keypair used to establish a symmetric key (via EC CDH, for instance) to be used to AES Keywrap the FEK or another KEK), the FCS_CKM.1(1) (in the case where the keys are used to directly wrap the target key) and/or FCS_CKM.2 (in the case where the keys are used to establish a symmetric key that will be used to wrap the target key) SFRs from the Application Software PP are included in the ST by the ST author.  This supplements any SFR selection criteria listed in the Application Software PP for these SFRs.

For the first selection, the ST author selects the method used for the keychain.  If the second option is chosen (“KEKs originating…”), then the ST author chooses all methods for production and protection of KEKs in the keychain from the options in the second selection.  For this option, the ST author must also specify the strength of the keys in the keychain.  It should be noted that “maintaining overall strength…commensurate with the overall strength of the FEK” is meant to cover the use case for this EP of a powered-off device being recovered by an adversary, who subsequently attempts to recover the FEK through a compromise of the key chain.

The third selection in the requirement is used to select the types of keys used in the key chain (both symmetric and asymmetric keys are allowed).  The bit sizes selected in the fourth and fifth selections are chosen by the ST author to be commensurate with the strength of the FEK in the following manner: for symmetric FEKs of 128 bits, the ST author can select any of the choices for both symmetric and asymmetric keys.  For symmetric FEKs of 256 bits, the ST author selects 256 bits if the symmetric key option is chosen and 192 bits or 256 bits if the asymmetric key option is chosen.

If a supplemental keychain is used, then the ST author selects the second option in the sixth selection and then chooses the method by which these keys are protected.  Keys in the supplemental key chain may be of any size, as they only provide additional protection to the primary key chain.  If a protection method is used that is not listed, the ST author can use the assignment to specify that protection method (note this is valid for supplemental keychains only). Compromise (according the EP use case) of the secondary key chain cannot circumvent the protection provided by the primary keychain.


Assurance Activity

Requirement met by the TOE

The evaluator shall verify the TSS* contains a high level description of the key hierarchy for all keychains and authorization methods selected in FIA_AUT_EXT that are used to protect the KEK or FEK. The evaluator shall examine the TSS to ensure it describes each key chain in detail, and these descriptions correspond with the selections of the requirement. The description of each key chain shall be reviewed to ensure it maintains a chain of keys using key wrap that meet FCS_COP.1(5) if mandated by the selections in the requirement.

The evaluator shall verify the TSS* to ensure that it describes how each key chain process functions, such that it does not expose any material that might compromise any key in the chain. A high-level description should include a diagram illustrating the key hierarchy implemented and detail where all keys and keying material is stored or what it is derived from. The evaluator shall examine the primary key hierarchy to ensure that at no point the chain could be broken without a cryptographic exhaust or knowledge of the KEK or FEK and the effective strength of the FEK is maintained throughout the Key Chain as specified in the requirement.

*if necessary, this information could be contained in a proprietary document and not appear in the TSS.


4.        To address the issue with there being a FCS_CKM_EXT.1 in both the Software File Encryption EP and the Application Software PP, the following is added to the application note for FCS_CKM_EXT.1 in the Software File Encryption EP.  In future revisions of the Software File Encryption EP, consideration will be given to renaming this component.

Application Note:

The ST author must include in the ST the appropriate component from Appendix C concerning the generation/support of the selected authorization factor. As previously indicated, the authorization factor can either be derived by the TSF in the case of passwords/passphrases or using an RBG, or the TOE can use an external entity that contains a key pair associated with that user that is used to protect the FEK (the TSF in this case will have a reduced role in the cryptographic operations involving the KEK and FEK depending on the specific scheme and implementation used; some cryptographic functions will be provided by the external entity (such as those used to decrypt the FEK)).

If the TOE includes support for TLS, the Application Software PP requires that the FCS_CKM_EXT.1 component be included in the ST.  This will create a naming conflict with this component.  To resolve that conflict, the ST author will indicate that the FCS_CKM_EXT.1 component from the Application Software PP is “FCS_CKM_EXT.1(1)” in the ST, and that this component is labeled “FCS_CKM_EXT.1(2)” in the ST.

[The remainder of the application note is unchanged.]


5.       Appendix E, E.1 Glossary of Terms is modified to add:

    Primary key chain - The direct key chain from the authorization factor to the FEK.

    Supplemental key chain - Other key chains that add protection or functionality without compromising the security of the primary key chain.


The Software File Encryption EP currently contains inconsistencies that make it difficult or impossible to specify products that should be able to claim conformance to the EP.  The changes detailed above resolve those inconsistencies.

Site Map              Contact Us              Home