@@ -252,7 +252,7 @@ For the purposes of the present document, the [following] terms [given in ... an
**Immutable components**: Components that cannot be modified after manufacture or initial programming.
**Immutable components**: Components that cannot be modified after manufacture or initial programming.
**Rollback protection**: Security mechanism preventing installation of older firmware versions that may contain known vulnerabilities.
**Rollback protection**: Security mechanism preventing unauthorized installation of older firmware versions that may contain known vulnerabilities.
**Factory reset**: Process of restoring boot manager to its original manufactured state, removing all user configuration and enrolled credentials.
**Factory reset**: Process of restoring boot manager to its original manufactured state, removing all user configuration and enrolled credentials.
@@ -351,7 +351,7 @@ The architectural pattern chosen is not merely a design decision but the primary
#### 4.3.1.1 Basic Boot
#### 4.3.1.1 Basic Boot
Basic boot implements sequential stage execution without cryptographic verification or integrity verification mechanisms.
Basic boot implements sequential stage execution without cryptographic verification mechanisms.
The system begins with power-on, proceeds through hardware initialization, and continues with sequential stage execution where each stage directly loads and executes the next until the boot target is reached.
The system begins with power-on, proceeds through hardware initialization, and continues with sequential stage execution where each stage directly loads and executes the next until the boot target is reached.
@@ -420,7 +420,7 @@ Boot managers operate across diverse environments that affect security requireme
@@ -653,6 +654,8 @@ Boot managers present unique risks due to their position as the foundation of sy
- Invisibility (below OS visibility)
- Invisibility (below OS visibility)
- Trust establishment (foundation for all security)
- Trust establishment (foundation for all security)
Detailed risk factors are provided in Annex C.
### 4.8.4 Capability-based risk considerations
### 4.8.4 Capability-based risk considerations
While this standard applies requirements based on technical capabilities rather than risk assessment, manufacturers should consider deployment risks when selecting which capabilities to implement:
While this standard applies requirements based on technical capabilities rather than risk assessment, manufacturers should consider deployment risks when selecting which capabilities to implement:
@@ -765,7 +768,7 @@ Example patterns from this standard:
- [SBD-BASE-RQ-1-01]: Baseline requirement applying to all boot managers
- [SBD-BASE-RQ-1-01]: Baseline requirement applying to all boot managers
- [SBD-VERIFIED-RQ-1-07]: Applies when condition [BA-2] is present
- [SBD-VERIFIED-RQ-1-07]: Applies when condition [BA-2] is present
- [SBD-UPDATE-OB-1-09]: Applies when conditions [UC-1], [UC-2], or [UC-3] are present
- [SBD-UPDATE-RQ-1-09]: Applies when conditions [UC-1], [UC-2], or [UC-3] are present
- [LOG-MEASURED-RQ-1-06]: Applies when condition [BA-3] is present
- [LOG-MEASURED-RQ-1-06]: Applies when condition [BA-3] is present
NOTE: Requirements using "OB" denote manufacturer obligations (processes, documentation) while "RQ" denotes technical product requirements. Both types may be baseline or conditional.
NOTE: Requirements using "OB" denote manufacturer obligations (processes, documentation) while "RQ" denotes technical product requirements. Both types may be baseline or conditional.
@@ -805,6 +808,8 @@ REQUIREMENT: The boot manager shall be accompanied by documentation demonstratin
RATIONALE: Boot managers require systematic risk assessment and secure development practices tailored to their unique constraints (pre-OS execution, limited resources, physical access risks) and critical role as foundation of system trust.
RATIONALE: Boot managers require systematic risk assessment and secure development practices tailored to their unique constraints (pre-OS execution, limited resources, physical access risks) and critical role as foundation of system trust.
<mark>#FIXME example</mark>
#### 5.2.2.2 SBD-BASE-RQ-1-02
#### 5.2.2.2 SBD-BASE-RQ-1-02
APPLICABILITY: All boot managers
APPLICABILITY: All boot managers
@@ -821,6 +826,8 @@ EXAMPLE 2: Persistent firmware implants (bootkits) survive OS reinstallation and
EXAMPLE 3: TOCTOU vulnerabilities in boot sequences occur when an attacker modifies a component between verification and execution.
EXAMPLE 3: TOCTOU vulnerabilities in boot sequences occur when an attacker modifies a component between verification and execution.
<mark>#FIXME example</mark>
#### SBD-BASE-RQ-1-XX
#### SBD-BASE-RQ-1-XX
**[SBD-BASE-RQ-1-03]** The boot manager shall be accompanied by security architecture documentation that includes: (i) complete boot flow from power-on to OS handoff; (ii) trust boundaries between boot stages; (iii) cryptographic key hierarchy and storage; (iv) memory layout and protection mechanisms; (v) interfaces exposed at each boot stage; (vi) recovery and failsafe mechanisms; and (vii) sufficient information to understand the security architecture.
**[SBD-BASE-RQ-1-03]** The boot manager shall be accompanied by security architecture documentation that includes: (i) complete boot flow from power-on to OS handoff; (ii) trust boundaries between boot stages; (iii) cryptographic key hierarchy and storage; (iv) memory layout and protection mechanisms; (v) interfaces exposed at each boot stage; (vi) recovery and failsafe mechanisms; and (vii) sufficient information to understand the security architecture.
@@ -1122,6 +1129,8 @@ NOTE: Constrained devices may lack cryptographic signature verification but must
EXAMPLE: A boot manager verifies bootloader signature before execution. If signature is invalid or missing, boot halts with error message rather than executing unverified code.
EXAMPLE: A boot manager verifies bootloader signature before execution. If signature is invalid or missing, boot halts with error message rather than executing unverified code.
EXAMPLE: A boot manager stores a version counter in protected non-volatile storage. When updated from version 5 to version 6, the counter increments from 5 to 6. Subsequent attempt to install version 5 is rejected because the stored counter (6) is greater than the version being installed (5).
EXAMPLE: A boot manager stores a version counter in protected non-volatile storage. When updated from version 5 to version 6, the counter increments from 5 to 6. Subsequent attempt to install version 5 is rejected because the stored counter (6) is greater than the version being installed (5).
<mark>#FIXME example</mark>
#### INTEGRITY-BASE-RQ-1-XX
#### INTEGRITY-BASE-RQ-1-XX
**[INTEGRITY-BASE-RQ-1-03]** Boot managers shall protect configuration data integrity by: (i) computing and verifying checksums or hashes of configuration; (ii) detecting unauthorized modifications to security policies; (iii) using authenticated encryption for sensitive settings where feasible; (iv) implementing tamper detection for security-critical parameters; and (v) restoring secure defaults when corruption is detected.
**[INTEGRITY-BASE-RQ-1-03]** Boot managers shall protect configuration data integrity by: (i) computing and verifying checksums or hashes of configuration; (ii) detecting unauthorized modifications to security policies; (iii) using authenticated encryption for sensitive settings where feasible; (iv) implementing tamper detection for security-critical parameters; and (v) restoring secure defaults when corruption is detected.
@@ -1539,12 +1550,16 @@ Boot managers present unique challenges for vulnerability management. Many boot
**[VULN-BASE-OB-1-03]** Manufacturers shall provide vulnerability disclosure including: (i) clear identification of affected boot manager versions; (ii) impact assessment and severity ratings; (iii) mitigation measures where updates aren't possible; (iv) coordinated disclosure following industry practices; (v) security advisory publication for critical vulnerabilities; and (vi) clear indication of which products can/cannot be updated.
**[VULN-BASE-OB-1-03]** Manufacturers shall provide vulnerability disclosure including: (i) clear identification of affected boot manager versions; (ii) impact assessment and severity ratings; (iii) mitigation measures where updates aren't possible; (iv) coordinated disclosure following industry practices; (v) security advisory publication for critical vulnerabilities; and (vi) clear indication of which products can/cannot be updated.
<mark>#FIXME change wording</mark>
**[VULN-BASE-RQ-1-04]** Boot managers shall support end-of-life procedures by: (i) clear communication of support lifecycle; (ii) final security updates before end-of-support; (iii) documentation of residual risks; (iv) migration paths where applicable; and (v) secure decommissioning guidance.
**[VULN-BASE-RQ-1-04]** Boot managers shall support end-of-life procedures by: (i) clear communication of support lifecycle; (ii) final security updates before end-of-support; (iii) documentation of residual risks; (iv) migration paths where applicable; and (v) secure decommissioning guidance.
**[VULN-IMMUTABLE-OB-1-05]** Applicable when no Update capability [UC-0] is present. For boot managers that cannot be updated (ROM, OTP, or hardware-limited), manufacturers shall: (i) document this limitation clearly; (ii) implement maximum security in initial release; (iii) provide detailed compensating controls guidance; (iv) maintain vulnerability monitoring and disclosure throughout product lifetime; and (v) specify hardware replacement as the update mechanism; (vi) implement defense-in-depth to reduce vulnerability impact; and (vii) provide clear end-of-life guidance when vulnerabilities cannot be mitigated.
**[VULN-IMMUTABLE-OB-1-05]** Applicable when no Update capability [UC-0] is present. For boot managers that cannot be updated (ROM, OTP, or hardware-limited), manufacturers shall: (i) document this limitation clearly; (ii) implement maximum security in initial release; (iii) provide detailed compensating controls guidance; (iv) maintain vulnerability monitoring and disclosure throughout product lifetime; and (v) specify hardware replacement as the update mechanism; (vi) implement defense-in-depth to reduce vulnerability impact; and (vii) provide clear end-of-life guidance when vulnerabilities cannot be mitigated.
NOTE: Inability to update does not exempt manufacturers from vulnerability management obligations. It increases the obligation for secure initial design and clear communication.
NOTE: Inability to update does not exempt manufacturers from vulnerability management obligations. It increases the obligation for secure initial design and clear communication.
<mark>#FIXME change wording</mark>
**[VULN-UPDATE-RQ-1-06]** Applicable when Update capability [UC-1], [UC-2], or [UC-3] is present. Update mechanisms shall prevent downgrade attacks through: (i) version checking before installation; (ii) anti-rollback counters; (iii) minimum version enforcement; (iv) signed version metadata; and (v) hardware-backed version protection where available.
**[VULN-UPDATE-RQ-1-06]** Applicable when Update capability [UC-1], [UC-2], or [UC-3] is present. Update mechanisms shall prevent downgrade attacks through: (i) version checking before installation; (ii) anti-rollback counters; (iii) minimum version enforcement; (iv) signed version metadata; and (v) hardware-backed version protection where available.
**[VULN-UPDATE-RQ-1-07]** Applicable when Update capability [UC-1], [UC-2], or [UC-3] is present. Updates shall maintain availability by: (i) backup and recovery mechanisms; (ii) atomic update operations; (iii) automatic rollback on failure; (iv) retention of previous working version; and (v) recovery mode preservation.
**[VULN-UPDATE-RQ-1-07]** Applicable when Update capability [UC-1], [UC-2], or [UC-3] is present. Updates shall maintain availability by: (i) backup and recovery mechanisms; (ii) atomic update operations; (iii) automatic rollback on failure; (iv) retention of previous working version; and (v) recovery mode preservation.
@@ -1606,10 +1621,16 @@ Boot managers require rigorous security testing due to their critical role in es
**[TEST-BASE-OB-1-01]** Manufacturers shall perform security testing including: (i) cryptographic validation of all algorithms; (ii) verification of signature checking; (iii) testing of authentication mechanisms; (iv) validation of rollback protection; and (v) confirmation of secure failure modes.
**[TEST-BASE-OB-1-01]** Manufacturers shall perform security testing including: (i) cryptographic validation of all algorithms; (ii) verification of signature checking; (iii) testing of authentication mechanisms; (iv) validation of rollback protection; and (v) confirmation of secure failure modes.
<mark>#FIXME change wording</mark>
**[TEST-BASE-OB-1-02]** Manufacturers shall conduct attack resistance testing including: (i) fuzzing of all inputs; (ii) fault injection testing where feasible; (iii) timing attack analysis; (iv) buffer overflow testing; and (v) bypass attempt validation.
**[TEST-BASE-OB-1-02]** Manufacturers shall conduct attack resistance testing including: (i) fuzzing of all inputs; (ii) fault injection testing where feasible; (iii) timing attack analysis; (iv) buffer overflow testing; and (v) bypass attempt validation.
<mark>#FIXME change wording</mark>
**[TEST-BASE-OB-1-03]** Security reviews shall include: (i) code review for security vulnerabilities; (ii) third-party security assessment for critical implementations; (iii) architecture review against threat model; (iv) binary analysis of production builds; and (v) supply chain security review.
**[TEST-BASE-OB-1-03]** Security reviews shall include: (i) code review for security vulnerabilities; (ii) third-party security assessment for critical implementations; (iii) architecture review against threat model; (iv) binary analysis of production builds; and (v) supply chain security review.
<mark>#FIXME change wording</mark>
#### 5.13.2.4 Output
#### 5.13.2.4 Output
- Security test results and reports
- Security test results and reports
@@ -1703,6 +1724,8 @@ Requirements marked with capability conditions (e.g., [BA-2], [UC-3], [BS-3]) on
3. Provide evidence only for applicable requirements
3. Provide evidence only for applicable requirements
4. Document why non-applicable requirements were excluded
4. Document why non-applicable requirements were excluded
<mark>#FIXME manufacturer or neutral language?</mark>
### 6.1.6 Component vs. product assessment
### 6.1.6 Component vs. product assessment
When a boot manager is provided as a component rather than a complete product:
When a boot manager is provided as a component rather than a complete product:
