@@ -1259,7 +1259,7 @@ To limit certificate forgery or misuse of certificate content, this section defi
- REFERENCE: REQ-PKI-EMM-16
- REQUIREMENT: In case of a request for certificate modification, any modified certified names or attributes shall be validated and updated registration information shall be recorded.
- NOTE: see ETSI 319 411-1 [i.3] clause 6.3.8 for the definition of certificate modification.
- NOTE: see ETSI 319 411-1 [\[i.10\]](#_ref_i.10) clause 6.3.8 for the definition of certificate modification.
- RATIONALE: The product should never issue a certificate without having validated all its certified names and attributes at some point in time. The product should possess accurate registration information regarding certificates it modifies.
- APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate modification.
@@ -1392,7 +1392,7 @@ The assessment criteria for each security requirements are described in a struct
## 6.2 No known exploitable vulnerabilities
- REFERENCE: ASS-REQ-6.4-08
- REFERENCE: ACC_PKI_KEV_01
- OBJECTIVE: Verify that:
1. Known exploitable vulnerabilities affecting the product are identified.
2. For each identified known exploitable vulnerability, one of the following applies:
@@ -1426,15 +1426,184 @@ The assessment criteria for each security requirements are described in a struct
- [GUIDANCE] Product user guidance relied upon to prevent exploitation, where applicable.
## 6.3 Secure by default configuration
### 6.3.1 SBDC - General
Assements covered in other sections:
- Other monitoring and certificate issuance assessment requirements
- Annex K assessment requirements
- REFERENCE: ACC-PKI-SBDC-02
## 6.4 Secure updates
- REFERENCE: ACC_PKI_SU_01
- OBJECTIVE:
Verify that the product supports software update mechanisms capable of updating all mutable parts of its software, excluding only those parts that are immutable due to technical constraints (e.g., ROM-based software).
- PREPARATION:
- Identify all software components of the product.
- Determine which components are mutable and which are immutable (e.g., ROM-based).
- Prepare a test environment with access to the product's update mechanisms.
- ACTIVITIES:
- Attempt to update each mutable component of the product's software.
- Verify that updates are successfully applied to all mutable components.
- Confirm that immutable components (e.g., ROM-based) are not updated and that this is justified by technical constraints.
- Document any components that cannot be updated and validate their immutability.
- VERDICT:
- SUCCESS:
- All mutable components can be updated.
- Immutable components are correctly identified and justified.
- FAIL:
- Any mutable component cannot be updated.
- Immutable components are not justified or incorrectly classified.
- EVIDENCE:
- Logs or screenshots of successful updates for mutable components.
- Documentation or technical specifications justifying immutability for excluded components.
- Test reports confirming the update process.
- REFERENCE: ACC_PKI_SU_02
- OBJECTIVE:
Verify that the product only installs updates signed by a known and trusted entity with a valid key identified by its PKC (Public Key Certificate).
- PREPARATION:
- Obtain a valid signed update from a trusted entity.
- Obtain an unsigned update or an update signed with an invalid/unknown key.
- Prepare a test environment with the product configured to recognize the trusted entity's PKC.
- ACTIVITIES:
- Attempt to install the valid signed update and verify it is accepted.
- Attempt to install the unsigned update or update signed with an invalid key and verify it is rejected.
- Check that the product validates the signature and PKC before installation.
- Test edge cases, such as expired or revoked certificates.
- VERDICT:
- SUCCESS:
- Valid signed updates are installed.
- Unsigned or invalidly signed updates are rejected.
- FAIL:
- Valid signed updates are rejected.
- Unsigned or invalidly signed updates are accepted.
- EVIDENCE:
- Logs or screenshots showing successful installation of valid updates.
- Logs or screenshots showing rejection of unsigned or invalidly signed updates.
- Test reports confirming signature and PKC validation.
- REFERENCE: ACC_PKI_SU_03
- OBJECTIVE:
Verify that the device administrator can configure when available updates are installed, with options such as immediate installation upon receipt or deferred installation during a maintenance period.
- PREPARATION:
- Identify the administrator configuration interface for update settings.
- Prepare test scenarios for different update installation options (e.g., immediate, deferred).
- ACTIVITIES:
- Configure the product to install updates immediately upon receipt and verify the behavior.
- Configure the product to defer updates to a specified maintenance period and verify the behavior.
- Attempt to trigger an update under each configuration and confirm it follows the configured timing.
- Verify that the administrator has sufficient control over the update timing.
- VERDICT:
- SUCCESS:
- The administrator can configure update timing options.
- Updates are installed according to the configured timing (immediate or deferred).
- FAIL:
- The administrator cannot configure update timing.
- Updates are not installed according to the configured timing.
- EVIDENCE:
- Screenshots or logs of the administrator interface showing configuration options.
- Test reports confirming updates are installed according to the configured timing.
- Documentation of the update process under different configurations.
## 6.5 Authentication and access control
### 6.5.1 AC - General
- REFERENCE: ACC_PKI_AC_01
- OBJECTIVE:
Verify the product allows to create different user profiles (users with different access rights to functions, configuration, and stored data) for the roles defined by PKI policies, each with distinct credentials.
- PREPARATION:
Access to the administrative and user interfaces of the product.
- ACTIVITIES:
- Create one account for each manageable profile (at least: PKI Administrator, PKI Operator, PKI Officer, PKI Auditor) with unique credentials.
- For each account:
- Attempt to log in using credentials from other accounts or invalid credentials.
- Log in with the correct credentials for each account.
- Verify that only the authorized actions defined by the user profile are accessible.
- If the account is not authorized to, attempt to read stored data
- If the account is not authorized to, attempt to read configuration data
- If the account is not authorized to, attempt to modify stored data
- If the account is not authorized to, attempt to modify configuration data
- VERDICT:
SUCCESS: if only correct identification and authentication allows access to the specific rights of a user profile, and only authorized users may read or modify stored data or configuration data, or perform protected actions.
FAIL: if unauthorized access or incorrect rights assignment is detected.
- EVIDENCE:
- Results of identification and authentication attempts (successful and failed).
- List of validated functionalities and data access rights for each user profile.
- Screenshots or logs of access attempts and rights verification.
- REFERENCE: ACC_PKI_AC_02
- OBJECTIVE:
- Verify that the product only allows identified and authenticated authorized users to perform access-controlled actions.
- PREPARATION:
- Access to the product interfaces.
- ACTIVITIES:
- Enumerate product interfaces and identify any interfaces without access control.
- Attempt to perform protected actions without being identified or authenticated.
- Log in as authorized users, then try to intercept and replay user authentication data or session authentication tokens.
- Systematically try all possible combinations of usernames, passwords, or other credentials to attempt unauthorized access.
- VERDICT:
- SUCCESS: No unauthorized users may read or modify stored data or configuration data, or perform protected actions.
- FAIL: If unauthorized access or incorrect rights assignment is detected.
- EVIDENCE:
- Results of identification and authentication attempts (both successful and failed).
- Screenshots or logs of access attempts, rights verification, or rejected actions.
### 6.5.2 AC - Monitoring
- REFERENCE: ACC_PKI_AC_03
- OBJECTIVE: Verify the product's ability to detect unauthorised modifications to the stored audit records during the audit.
- PREPARATION: Ability to trigger auditable events as a user, and ability to audit events. Ability to directly modify the contents of existing audit records.
- ACTIVITIES: Trigger an auditable event. Access and copy the corresponding audit record separately.
- Directly modify the contents of the stored audit record in the product.
- Attempt to access the audit record.
- VERDICT: SUCCESS if the last audit fails; else FAIL.
- EVIDENCE:
a) the way the event was triggered, and the corresponding audit record which was copied;
b) the way the audit record was directly modified;
c) the way the last audit was attempted, and the corresponding response from the product.
## 6.6 Confidentiality
## 6.7 Integrity
## 6.8 Data minimisation
### 6.8.1 General
- REFERENCE: ACC-PKI-DM-01
- OBJECTIVE:
Determine whether the product only maintains network configuration data necessary for communication with PKI system elements required by the applicable use case and does not maintain unnecessary network configuration information.
- PREPARATION:
- Product architecture and deployment documentation.
- List of PKI system components and interfaces to connect to.
- List of external components and interfaces to connect to.
- Access to configuration files, administrative guides, and installation procedures.
- ACTIVITIES:
@@ -1457,16 +1626,35 @@ The assessment criteria for each security requirements are described in a struct
- Configuration files and parameter listings.
- Assessment records demonstrating the review of network configuration parameters.
- REFERENCE: ACC-PKI-SBDC-02
- REFERENCE: REQ-PKI-DM-02
- OBJECTIVE:
- Determine whether the product maintains only the configuration data required to implement the PKC management functions applicable to the use case.
Verify that the product only maintains and processes user data necessary for certificate management.
- PREPARATION:
- Access to the product's user data storage and certificate management logs.
- ACTIVITIES:
- Review the user data stored and processed by the product.
- Identify all user data related to certificate management (e.g., certificate requests, updates).
- Verify that no unnecessary or unrelated user data is stored or processed.
- Confirm that the stored and processed data is limited to what is required for certificate management.
- VERDICT:
- SUCCESS: If the product only maintains and processes user data necessary for certificate management.
- FAIL: If unnecessary or unrelated user data is found.
- EVIDENCE:
- List of stored and processed user data.
- Documentation or logs showing the alignment of user data with certificate management requirements.
- REFERENCE: ACC-PKI-DM-03
- OBJECTIVE:
Determine whether the product maintains only the configuration data required to implement the PKC management functions applicable to the use case.
-Obtain Annex U use case definitions.
-Obtain product configuration documentation.
- Obtain a list of implemented PKC management functions and associated configuration parameters.
-PREPARATION:
-Product configuration documentation.
- List of implemented PKC management functions and associated configuration parameters.
- ACTIVITIES:
1. Review the applicable use case requirements.
@@ -1478,18 +1666,14 @@ The assessment criteria for each security requirements are described in a struct
- VERDICT:
- SUCCESS:
- All PKC configuration parameters support identified certificate management functions required by the applicable use case.
- No unnecessary PKC management functions or associated configuration data are maintained.
- FAIL:
- Configuration data are maintained for PKC functions not required by the applicable use case.
- Unnecessary PKC management capabilities are present.
- EVIDENCE:
- Use case analysis.
- Product functional specifications.
- Configuration documentation.
- Assessment records mapping configuration parameters to PKC functions.
@@ -1665,217 +1849,8 @@ The assessment criteria for each security requirements are described in a struct
- Assessment records demonstrating key handling and destruction procedures.
## 6.4 Secure updates
- REFERENCE: ACC_PKI_SU_01
- OBJECTIVE:
Verify that the product supports software update mechanisms capable of updating all mutable parts of its software, excluding only those parts that are immutable due to technical constraints (e.g., ROM-based software).
- PREPARATION:
- Identify all software components of the product.
- Determine which components are mutable and which are immutable (e.g., ROM-based).
- Prepare a test environment with access to the product's update mechanisms.
- ACTIVITIES:
- Attempt to update each mutable component of the product's software.
- Verify that updates are successfully applied to all mutable components.
- Confirm that immutable components (e.g., ROM-based) are not updated and that this is justified by technical constraints.
- Document any components that cannot be updated and validate their immutability.
- VERDICT:
- SUCCESS:
- All mutable components can be updated.
- Immutable components are correctly identified and justified.
- FAIL:
- Any mutable component cannot be updated.
- Immutable components are not justified or incorrectly classified.
- EVIDENCE:
- Logs or screenshots of successful updates for mutable components.
- Documentation or technical specifications justifying immutability for excluded components.
- Test reports confirming the update process.
- REFERENCE: ACC_PKI_SU_02
- OBJECTIVE:
Verify that the product only installs updates signed by a known and trusted entity with a valid key identified by its PKC (Public Key Certificate).
- PREPARATION:
- Obtain a valid signed update from a trusted entity.
- Obtain an unsigned update or an update signed with an invalid/unknown key.
- Prepare a test environment with the product configured to recognize the trusted entity's PKC.
- ACTIVITIES:
- Attempt to install the valid signed update and verify it is accepted.
- Attempt to install the unsigned update or update signed with an invalid key and verify it is rejected.
- Check that the product validates the signature and PKC before installation.
- Test edge cases, such as expired or revoked certificates.
- VERDICT:
- SUCCESS:
- Valid signed updates are installed.
- Unsigned or invalidly signed updates are rejected.
- FAIL:
- Valid signed updates are rejected.
- Unsigned or invalidly signed updates are accepted.
- EVIDENCE:
- Logs or screenshots showing successful installation of valid updates.
- Logs or screenshots showing rejection of unsigned or invalidly signed updates.
- Test reports confirming signature and PKC validation.
- REFERENCE: ACC_PKI_SU_03
- OBJECTIVE:
Verify that the device administrator can configure when available updates are installed, with options such as immediate installation upon receipt or deferred installation during a maintenance period.
- PREPARATION:
- Identify the administrator configuration interface for update settings.
- Prepare test scenarios for different update installation options (e.g., immediate, deferred).
- ACTIVITIES:
- Configure the product to install updates immediately upon receipt and verify the behavior.
- Configure the product to defer updates to a specified maintenance period and verify the behavior.
- Attempt to trigger an update under each configuration and confirm it follows the configured timing.
- Verify that the administrator has sufficient control over the update timing.
- VERDICT:
- SUCCESS:
- The administrator can configure update timing options.
- Updates are installed according to the configured timing (immediate or deferred).
- FAIL:
- The administrator cannot configure update timing.
- Updates are not installed according to the configured timing.
- EVIDENCE:
- Screenshots or logs of the administrator interface showing configuration options.
- Test reports confirming updates are installed according to the configured timing.
- Documentation of the update process under different configurations.
## 6.5 Authentication and access control
### 6.5.1 General
- REFERENCE: ACC_PKI_AC_01
- OBJECTIVE:
Verify the product allows to create different user profiles (users with different access rights to functions, configuration, and stored data) for the roles defined by PKI policies, each with distinct credentials.
- PREPARATION:
Access to the administrative and user interfaces of the product.
- ACTIVITIES:
- Create one account for each manageable profile (at least: PKI Administrator, PKI Operator, PKI Officer, PKI Auditor) with unique credentials.
- For each account:
- Attempt to log in using credentials from other accounts or invalid credentials.
- Log in with the correct credentials for each account.
- Verify that only the authorized actions defined by the user profile are accessible.
- If the account is not authorized to, attempt to read stored data
- If the account is not authorized to, attempt to read configuration data
- If the account is not authorized to, attempt to modify stored data
- If the account is not authorized to, attempt to modify configuration data
- VERDICT:
SUCCESS: if only correct identification and authentication allows access to the specific rights of a user profile, and only authorized users may read or modify stored data or configuration data, or perform protected actions.
FAIL: if unauthorized access or incorrect rights assignment is detected.
- EVIDENCE:
- Results of identification and authentication attempts (successful and failed).
- List of validated functionalities and data access rights for each user profile.
- Screenshots or logs of access attempts and rights verification.
- REFERENCE: ACC_PKI_AC_02
- OBJECTIVE:
- Verify that the product only allows identified and authenticated authorized users to perform access-controlled actions.
- PREPARATION:
- Access to the product interfaces.
- ACTIVITIES:
- Enumerate product interfaces and identify any interfaces without access control.
- Attempt to perform protected actions without being identified or authenticated.
- Log in as authorized users, then try to intercept and replay user authentication data or session authentication tokens.
- Systematically try all possible combinations of usernames, passwords, or other credentials to attempt unauthorized access.
- VERDICT:
- SUCCESS: No unauthorized users may read or modify stored data or configuration data, or perform protected actions.
- FAIL: If unauthorized access or incorrect rights assignment is detected.
- EVIDENCE:
- Results of identification and authentication attempts (both successful and failed).
- Screenshots or logs of access attempts, rights verification, or rejected actions.
### 6.5.2 Monitoring
- REFERENCE: ACC_PKI_AC_03
- OBJECTIVE: Verify the product's ability to detect unauthorised modifications to the stored audit records during the audit.
- PREPARATION: Ability to trigger auditable events as a user, and ability to audit events. Ability to directly modify the contents of existing audit records.
- ACTIVITIES: Trigger an auditable event. Access and copy the corresponding audit record separately.
- Directly modify the contents of the stored audit record in the product.
- Attempt to access the audit record.
- VERDICT: SUCCESS if the last audit fails; else FAIL.
- EVIDENCE:
a) the way the event was triggered, and the corresponding audit record which was copied;
b) the way the audit record was directly modified;
c) the way the last audit was attempted, and the corresponding response from the product.
## 6.6 Confidentiality
## 6.7 Integrity
## 6.8 Data minimisation
### 6.8.1 General
- REFERENCE: ACC-PKI-DM-01
- OBJECTIVE:
Verify that the product only maintains configuration data necessary to connect to other IT elements.
- PREPARATION:
- Access to the product interfaces and configuration data
- Architecture documentation.
- ACTIVITIES:
- Review the product's stored configuration data.
- Identify all configuration parameters related to external IT components connections.
- Verify that no unnecessary or unrelated configuration data is stored.
- Confirm that the stored data aligns with the product architecture description.
- Verify that no unecessary ports are open or communication protocol implemented.
- VERDICT:
- SUCCESS: If the product only maintains configuration data sufficient for connecting to the relevant external IT elements.
- FAIL: If unnecessary or unrelated configuration data is found.
- EVIDENCE:
- List of stored configuration data.
- Documentation or logs showing the alignment of configuration data with PKI system requirements.
- REFERENCE: REQ-PKI-DM-02
- OBJECTIVE:
Verify that the product only maintains and processes user data necessary for certificate management.
- PREPARATION:
- Access to the product's user data storage and certificate management logs.
- ACTIVITIES:
- Review the user data stored and processed by the product.
- Identify all user data related to certificate management (e.g., certificate requests, updates).
- Verify that no unnecessary or unrelated user data is stored or processed.
- Confirm that the stored and processed data is limited to what is required for certificate management.
- VERDICT:
- SUCCESS: If the product only maintains and processes user data necessary for certificate management.
- FAIL: If unnecessary or unrelated user data is found.
- EVIDENCE:
- List of stored and processed user data.
- Documentation or logs showing the alignment of user data with certificate management requirements.
