NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0130:  NIT Technical Decision for Requirements for Destruction of Cryptographic Keys

Publication Date
2016.12.08

Protection Profiles
CPP_FW_V1.0, CPP_ND_V1.0

Other References
FCS_CKM.4

Issue Description

The Network Interpretations Team (NIT) has issued a technical decision regarding requirements on destruction of cryptographic keys in the NDcPP v1.0 and FW cPP v1.0.

Resolution

To align with the NIT interpretation #3, revision 2, the wording of FCS_CKM.4.1 is changed and an Application Note is added.

For further information, please see the NIT interpretation at: https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/NITDecisionRfI03rev2.pdf.

FCS_CKM.4 is changed to:

FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method

• For plaintext keys in volatile storage, the destruction shall be executed by a [selection: single overwrite consisting of [selection: a pseudo-random pattern using the TSF’s RBG, zeroes, ones, a new value of the key, [assignment: a value that does not contain any CSP]], destruction of reference to the key directly followed by a request for garbage collection];

• For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by a part of the TSF that [selection:

o   logically addresses the storage location of the key and performs a [selection: single, [assignment: number of passes]-pass] overwrite consisting of [selection: a pseudo-random pattern using the TSF’s RBG, zeroes, ones, a new value of the key, [assignment: a value that does not contain any CSP]];

o   instructs a part of the TSF to destroy the abstraction that represents the key]]

that meets the following: No Standard.

 

The following Application Note is added to FCS_CKM.4:

In parts of the selections where keys are identified as being destroyed by “a part of the TSF”, the TSS identifies the relevant part and the interface involved. The interface referenced in the requirement could take different forms for different TOEs, the most likely of which is an application programming interface to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation the application may simply have a handle to a resource and can only ask another part of the TSF such as the interpreter or OS to delete the resource.

Where different key destruction methods are used for different keys and/or different destruction situations then the different methods and the keys/situations they apply to are described in the TSS (and the ST may use separate iterations of the SFR to aid clarity). The TSS describes all relevant keys used in the implementation of SFRs, including cases where the keys are stored in a non-plaintext form. In the case of non-plaintext storage, the encryption method and relevant key-encrypting-key are identified in the TSS.

Some selections allow assignment of “a value that does not contain any CSP”. This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG_EXT requirements, and not being any of the particular values listed as other selection options. The point of the phrase “does not contain any CSP” is to ensure that the overwritten data is carefully selected, and not taken from a general pool that might contain current or residual data that itself requires confidentiality protection.

Key destruction does not apply to the public component of asymmetric key pairs.

Justification

See issue.

 
 
Site Map              Contact Us              Home