Archived
TD0076: Correction to SWFE Keychain Requirement
Publication Date
2015.12.24
Protection Profiles
PP_APP_SWFE_EP_v1.0
Other References
PP_APP_SWFE_EP_v1.0, FCS_KYC_EXT.1.1
Issue Description
FCS_KYC_EXT.1.1 as currently written does not support the concept of primary and supplemental key chains. Also, the "effective strength" part of the requirement does not differentiate between symmetric and asymmetric keys. Resolution
FCS_KYC_EXT.1.1 is rewritten as follows: [selection:
[selection: utilization of the platform key storage, ] while maintaining an overall effective strength of [selection:
] commensurate with the strength of the FEK. ] and [selection:
[selection:
utilization of the platform key storage, ]. The application note is replaced with the following:
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. Compromise (according the EP use case) of the secondary key chain cannot circumvent the protection provided by the primary keychain.
The TSS assurance activity is replaced with the following:
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. Justification
The SFR now separates primary key chains from supplemental key chains, and addresses the effective strength of both symmetric and asymmetric keys. |