DSC0003 - Editorial Corrections in Supporting Document

There is no support for a "common application developer" in the cPP as mentioned in 2.1.6.1.3.

There is a typo referencing FCS_COP.1/SK (which does not exist) in 2.2.8.1.3.

There is a typo referencing FMT_SMF_EXT.1 (which does not exist) in 2.4.1.1.3.

There is a typo referencing FPT_PHP.1 (which does not exist) in 2.5.4.1.3.

There is a typo referencing FCS_COP.1/KDF (which does not exist) in 4.1.1.2.1 and 4.1.1.2.3.

The description and tests associated with this selection will be removed.

The reference will be corrected to FCS_COP.1/SKC.

The reference will be corrected to FMT_SMF.1.

The reference will be corrected to FPT_PHP.3.

The reference will be corrected to FCS_CKM_EXT.5.

2.1.6.1.3 Test

The evaluator shall test the functionality of each security function as described below. If the TOE supports both import and generation of keys, the evaluator shall repeat the testing as needed to demonstrate that the keys resulting from both operations are treated in the same manner. The devices used with the tooling may need to be non-production devices in order to enable the execution and gathering of evidence.

Test 1: The evaluator shall import or generate keys/secrets of each supported type according to the operational guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key/secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur during import.

Test 2: The evaluator shall write, or the developer shall provide access to, an application that uses a generated or imported key/secret:

The evaluator shall repeat this test with the application-imported or application-generated keys/secrets and a different application’s imported keys/secrets or generated keys/secrets. The evaluator shall verify that the TOE requires approval before allowing the application to use the key/secret imported or generated by the user or by a different application:

If the ST author has selected common application developer, this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.

Test 3: The evaluator shall destroy keys/secrets of each supported type according to the operational guidance. The evaluator shall write, or the developer shall provide access to, an application that destroys an imported or generated key/secret. The evaluator shall repeat this test with the application-imported or application-generated keys/secrets and a different application’s imported or generated keys/secrets. The evaluator shall verify that the TOE requires approval before allowing the application to destroy the key/secret imported by the administrator or by a different application:

If the ST author has selected common application developer, this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.

2.2.8.1.3 Test

If the TOE stores SDEs and authorization data inside the TSF, the evaluator shall ensure that external interfaces cannot extract this data in plaintext.

In this case, use the evaluation activities of the FPT_PHP.3 if protected storage is selected, FCS_COP.1/SKC if symmetric encryption using… is selected, and FCS_COP.1/KAT if key wrapping using… is selected.

If the TOE stores authentication data inside the operational environment, the evaluator shall ensure that plaintext data is not visible on the interface between the TOE and the operational environment.

2.4.1.1.3 Test

For each management function described in FMT_SMF_EXT.1.1, the evaluator shall perform the function with administrator authorization data and confirm it succeeds, and again with client application authorization data and confirm that it fails.

2.5.4.1.3 Test

Immutability

For immutable Root of Trust identity, the evaluator shall confirm a successful evaluation of FPT_PHP.1 (Physical Protection) FPT_PHP.3 (Resistance to Physical Attack).

Mutability

For a mutable Root of Trust identity, the evaluator shall perform the following tests:

4.1.1.2.1 TSS

The evaluator shall examine the TSS to verify that it describes how the TOE obtains an SK through direct generation as specified in FCS_RBG_EXT.1, FCS_COP.1/KDF FCS_CKM_EXT.5, or FCS_COP.1/PBKDF. The evaluator shall review the TSS to verify that it describes how the ST invokes the functionality described by FCS_RBG_EXT.1 and FCS_COP.1/PBKDF where applicable.

[conditional] If the symmetric key is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.

4.1.1.2.3 Test

For each selected key generation method, the evaluator shall configure the selected generation capability. The evaluator shall use the description of the RBG interface to verify that the TOE requests and receives an amount of RBG output greater than or equal to the requested key size. The evaluator shall perform the tests as described for FCS_COP.1/KDF FCS_CKM_EXT.5 and FCS_COP.1/PBKDF.