@@ -792,8 +792,6 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
- EXAMPLE: The role of the access control countermeasure is described in ETSI TS 102 165-2 [\[i.8\]](#_ref_i.8)(clause 6) where permission to access a resource is only ever true (PERMIT) or false (DENY) and where the decision to give permission is always deterministic.
- APPLICABILITY: All use cases.
TODO
### 5.3.2 SDBC - Monitoring
- REFERENCE: REQ-PKI-SBDC-02
@@ -811,15 +809,16 @@ TODO
### 5.3.4 SDBC - Certificates
- REFERENCE: REQ-PKI-SBDC-04
- REQUIREMENT: Certificates validity periode shall be default be limited to 3 years.
- RATIONALE: XXX
- REQUIREMENT: Certificates validity periode shall be limited to 3 years by default.
- RATIONALE: The longer a certificate is valid, the higher the risk that cryptographic attacks on its signature may succeed. A default limitation to 3 years reduces unnecessary exposure of certificates to potential vulnerabilities.
- APPLICABILITY: All use cases.
## 5.4 Secure updates
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c).
- REFERENCE: REQ-PKI-SU-01: The product shall support software update mechanisms, that allow to update every part of the product's software, except for parts of the product's software that are immutable due to technical reasons.
- REFERENCE: REQ-PKI-SU-01:
- REQUIREMENT: The product shall support software update mechanisms, that allow to update every part of the product's software, except for parts of the product's software that are immutable due to technical reasons.
- NOTE: Part of the product's software can be immutable due to its technology (e.g. software installed in a ROM).
- APPLICABILITY: All use cases.
@@ -1362,6 +1361,88 @@ The assessment criteria for each security requirements are described in a struct
## 6.3 Secure by default configuration
## 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.
