@@ -176,8 +176,12 @@ The boundary is determined by whether the component executes between power-on an
NOTE: Components that cannot be updated post-manufacture are addressed with specific provisions in Section 5.
NOTE: Boot managers for smart cards and secure elements may be subject to additional conformity assessment procedures when integrated into Class II critical products. Such components may conform to this standard but require evaluation in their specific security context.
<mark>#FIXME More out-of-scope clarification needed?</mark>
## 1.4 Composite products
When boot manager functionality is integrated into larger products (such as operating systems, hypervisors, or embedded devices), the product manufacturer demonstrates conformance through evaluation of the complete product, with boot manager requirements assessed as part of the whole.
@@ -277,6 +281,8 @@ For the purposes of the present document, the [following] abbreviations [given i
- APT: Advanced Persistent Threat
- BIOS: Basic Input/Output System
- CDI: Compound Device Identity
- DICE: Device Identifier Composition Engine
- DMA: Direct Memory Access
- HSM: Hardware Security Module
- NVRAM: Non-Volatile Random Access Memory
@@ -371,6 +377,8 @@ Power On -> Hardware Init -> Boot Manager -> Boot Target
Verified boot implements cryptographic verification with enforcement throughout the boot process. Components are cryptographically verified before execution, creating a verification chain from power-on through boot target execution.
@@ -387,6 +395,8 @@ Power On -> Hardware Init -> Boot Loader -> Boot Target
[Keys/Hashes]----|---------------|
```
<mark>#FIXME Extent technical descriptions of verified boot?</mark>
#### 4.3.1.3 Measured Boot
Measured boot records cryptographic measurements of each boot stage without preventing execution. During initialization, the system activates measurement capabilities and records a cryptographic hash of each subsequent stage into secure storage.
@@ -407,6 +417,8 @@ Power On → Hardware Init → Boot Loader → Boot Target
[Hardware-Protected Storage (PCRs or CDI chain)]
```
<mark>#FIXME Extent technical descriptions of measured boot?</mark>
### 4.3.2 Functional extensions
Additional functions such as network boot, multi-boot selection, or recovery modes can be incorporated into any of the architectures described in Section 4.3.1.
@@ -535,6 +547,8 @@ The boot manager depends on the following security functions from the hardware p
When these platform functions are unavailable, the boot manager shall document compensating controls or limitations.
NOTE: Hardware security mechanisms may include various implementations such as secure elements or hardware security modules features including write protection latches that can protect boot manager code from tampering by higher-privilege software layers.
### 4.5.3 Security functions delegated to boot target
The following security functions are outside the scope of the boot manager and are the responsibility of the loaded boot target:
@@ -546,7 +560,7 @@ The following security functions are outside the scope of the boot manager and a
- Ongoing vulnerability management and patching
- Security event logging (post-handoff)
NOTE: Boot managers may provide runtime services that support boot target security, but the boot target is responsible for utilizing these services appropriately.
NOTE: Some boot managers provide runtime services that remain accessible after boot target handoff (e.g., UEFI runtime services for variable storage, time services, or capsule updates). These runtime services are within scope when they affect boot security, integrity, or configuration. Runtime services unrelated to boot security (e.g., general OS services) are out of scope.
### 4.5.4 Trust boundaries
@@ -845,7 +859,7 @@ A manufacturer of a boot manager shall implement secure by design principles thr
**Applicability**
Bsseline requirement, applicable to all boot managers.
Baseline requirement, applicable to all boot managers.
