NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
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:

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

[selection:

  • a conditioned password as the FEK,
  • KEKs originating from one or more authorization factor(s) to the FEK(s) using the following method(s):

[selection:

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

]

while maintaining an overall 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):

[selection:

 

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
]

 ].

The application note is replaced with the following:


Application Note:

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.
 
In addition, the following glossary terms are defined:

  • 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 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.

 
 
Site Map              Contact Us              Home