@@ -1857,7 +1857,7 @@ Validity of access control requirement are covered by section 6.5:
- API invocation logs.
- Audit records.
###6.6.2 CON - Key management
###6.6.3 CON - Key management
- REFERENCE: ACC-PKI-CON-05
- OBJECTIVE:
@@ -1922,7 +1922,7 @@ Assessment requirements covering Monitoring are presented in section 6.13.
The validity of the cryptographic mechanisms used to encure those funtions is covered by annex K assessment requirement.
###6.7.1 INT - Monitoring
###6.7.1 INT - Monitoring
- REFERENCE: ACC-PKI-INT-01
- OBJECTIVE:
@@ -2252,7 +2252,7 @@ The validity of the cryptographic mechanisms used to encure those funtions is co
- Test results and interface traces.
- Assessment records.
### 6.8.2 Secret management
### 6.8.2 DM - Secret management
- REFERENCE: ACC_PKI_DM_03
- OBJECTIVE:
@@ -2480,7 +2480,7 @@ REFERENCE: ACC_PKI_DM_04
- System event logs.
- Test reports.
###6.9.2 AP - Certificate status services
###6.9.2 AP - Certificate status services
- REFERENCE: ACC-PKI-AP-06
- OBJECTIVE:
@@ -2668,7 +2668,7 @@ As stated in clause 5.10, since minimizing the impact on other systems relies on
- Test records demonstrating that no additional interfaces are present or accessible.
## 6.12 Exploitation mitigation mechanisms
### 6.12.1 Certificate issuance
### 6.12.1 EMM - Certificate issuance
- REFERENCE: ACC_PKI_EMM_01
- OBJECTIVE:
@@ -2805,7 +2805,7 @@ and REQ-PKI-EMM-04.
c) the key pairs issued by the product if any, and how and when they were obtained;
d) the random values generated by the product.
### 6.12.2 Certificate status
### 6.12.2 EMM - Certificate status
- REFERENCE: ACC_PKI_EMM_09
- OBJECTIVE: Verify the certificate revocation statuses to be either or both of CRLs as defined by and subject to the requirements of ITU-T X.509 [\[2\]](#_ref_2), or OCSP responses as defined by and subject to the requirements of RFC 6960 [\[i.3\]](#_ref_i.3).
@@ -3059,6 +3059,100 @@ REFERENCE: ACC_PKI_MON_02
## 6.14 Data removal and transparency
- REFERENCE: ACC-PKI-DRT-01
- OBJECTIVE:
- Verify that all public keys stored by the product outside of a secure cryptographic device are protected against undetected modification.
- Verify that the product detects unauthorized modification of stored public keys before they are released or used.
- Verify that, upon detection of a modification, the product does not release the public key to the requesting entity and does not use the modified public key for any cryptographic operation.
- PREPARATION:
- Identify all locations where public keys are stored outside secure cryptographic devices (e.g., databases, filesystems, configuration repositories, directories, caches, backups).
- Identify the mechanisms used to protect public key integrity (e.g., digital signatures, hashes, message authentication codes, integrity checks).
- Valid test public keys and associated integrity protection information.
- Tools and permissions necessary to modify stored public key data and integrity protection data.
- ACTIVITIES:
- Store one or more valid public keys in each identified and accessible storage location.
- Access and use the stored public keys and verify that:
- Integrity verification is performed prior to release or use.
- Valid public keys are successfully released and used.
- Modify a stored public key without updating its integrity protection information.
- Attempt to access or use the modified public key and verify that:
- The integrity verification mechanism detects the modification.
- The modified public key is not returned to the requesting entity.
- The modified public key is not used in any cryptographic operation.
- Attempt to perform cryptographic operations that depend on the modified public key and verify that such operations fail safely.
- Review system logs and verify that integrity verification failures are appropriately recorded, where logging is implemented.
- VERDICT:
- SUCCESS:
- All public keys stored outside secure cryptographic devices are protected by an integrity verification mechanism.
- Unauthorized modifications of stored public keys are reliably detected.
- Modified public keys are neither released nor used by the product.
- Cryptographic operations depending on modified public keys fail safely and predictably.
- FAIL:
- A stored public key can be modified without detection.
- A modified public key is released to a none-authorized user.
- A modified public key is used by the product.
- Integrity verification mechanisms can be bypassed or are not consistently applied.
- Cryptographic operations continue using modified public keys.
- EVIDENCE:
- Public key storage locations.
- Documentation of integrity protection mechanisms.
- Test records showing successful verification of valid public keys.
- Test records demonstrating detection of unauthorized modifications.
- Screenshots or log extracts showing integrity verification failures.
- Evidence that modified public keys were neither released nor used.
- REFERENCE: ACC-PKI-DRT-02
- OBJECTIVE:
- Verify that all secrets temporarily manipulated by the product in plaintext form are zeroized after use.
- Verify that plaintext secrets are not retained in memory, temporary files, caches, or other storage locations beyond their required period of use.
- Verify that secret zeroization occurs consistently during normal operation and error conditions.
- PREPARATION:
- Identify all secrets that may be temporarily manipulated in plaintext form, including:
- Private keys.
- Authentication credentials.
- Passphrases and passwords.
- Key-encryption keys.
- Session keys and other cryptographic secrets.
- Identify all components and processes that temporarily process these secrets.
- Documentation describing secret handling and zeroization mechanisms.
- Tools capable of examining process memory, temporary files, and storage artifacts.
- ACTIVITIES:
- Execute all functions that temporarily manipulate secrets in plaintext form.
- During and after each operation, inspect:
- Process memory.
- Temporary files.
- Cache locations.
- Swap or paging areas, where applicable.
- Inter-process communication buffers, where applicable.
- Verify that plaintext secrets are present only for the duration necessary to perform the operation.
- Verify that plaintext secrets are overwritten or cleared immediately after use.
- Induce abnormal conditions, including:
- Operation failures.
- Interrupted processing.
- Unexpected exceptions.
- Service restarts.
- Verify that plaintext secrets are also zeroized following abnormal termination conditions.
- Repeat the assessment for all identified components that temporarily manipulate secrets.
- VERDICT:
- SUCCESS:
- All identified plaintext secrets are zeroized after use.
- Plaintext secrets are not retained in memory or temporary storage beyond their operational need.
- Zeroization occurs during both normal and abnormal execution paths.
- No recoverable plaintext secret material remains after completion of processing.
- FAIL:
- One or more plaintext secrets remain accessible after use.
- Plaintext secrets persist in memory, temporary files, caches, or buffers beyond their required lifetime.
- Zeroization is not performed during abnormal termination conditions.
- Recoverable plaintext secret material can be obtained after the completion of processing.
- EVIDENCE:
- Inventory of secrets manipulated in plaintext form.
- Design documentation describing secret handling and zeroization mechanisms.
- Memory analysis reports demonstrating the removal of plaintext secrets.
- Inspection results for temporary files, caches, and storage artifacts.
- Test records for normal and abnormal execution scenarios.
- Screenshots, logs, or forensic reports demonstrating successful zeroization.
## 6.15 Vulnerability handling
The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[i.17\]](#_ref_i.17) shall be met for the product
