A valid signature proves that a trusted key signed these bits. It does not by itself prove the version is acceptable, that the measured image is the one about to execute, or that a key is released in the right lifecycle.
Bind the decision to the executed image
At a warehouse, seal, lot number, and contents must match; checking the seal alone does not prove the box was not swapped in transit. Secure Boot binds signer, image digest, hardware target, security version, load address, and final fetch to one transaction. The analogy does not include hash-collision assumptions, DMA races, or microarchitectural caches.
A typical path uses an immutable/ROM root to obtain a key or key identifier, verifies the manifest and signature, enforces a version floor, locks relevant settings, then transfers execution. If DMA can change writable memory after verification, the earlier pass no longer describes the current bytes. Bind the measured digest to an immutable buffer or protected load region and record acceptance at commit. OpenTitan’s key-manager theory separates software binding, version checks, and sideload outputs; interpret it against the actual product integration. Key manager.
The gap between check and use is easy to miss. If software reads a rollback counter only once, a concurrent update may change the version. If key release checks only a boot_done sticky bit, it may reuse permission from a previous image. Bind transaction ID, digest, version, lifecycle, and destination key slot; fail closed on release. Also prevent a security rejection from creating unrecoverable denial of service.
Define asset boundaries as the first instruction fetch and the first sideload-key use. First fetch must bind signature, version, digest, and transaction ID to the same transaction. Key release must also meet lifecycle and destination key-slot policy. This RTL/SVA sketch is not a product assertion and has not been wired or compiled.
Find TOCTOU and rollback
Compare a valid current image, a correctly signed but stale image, a digest for image A followed by fetch from image B, a stale boot_done sticky bit, and a production-key request in debug lifecycle. Preserve the first unauthorized acceptance edge and the rejection reason for each trace.
Offline interactive lab
RTL / SVA review direction
These are property sketches: define the harness transaction, reset and oracle, then confirm sampling boundaries before binding to the design. They have not been compiled or proven.
assert property (@(posedge clk) disable iff (!rst_n)
key_release |-> signature_ok && reference_signature_valid && active_txn_id == reference_txn_id &&
active_digest == reference_digest && active_version >= security_version_floor &&
reference_key_release_allowed && key_slot == reference_key_slot);
assert property (@(posedge clk) disable iff (!rst_n)
first_fetch |-> fetch_digest == reference_digest && fetch_txn_id == reference_txn_id &&
signature_ok && reference_signature_valid &&
fetch_version >= security_version_floor && reference_fetch_policy_ok);
cover property (@(posedge clk) disable iff (!rst_n)
key_release && signature_ok && reference_signature_valid && reference_key_release_allowed);
cover property (@(posedge clk) disable iff (!rst_n)
first_fetch && signature_ok && reference_signature_valid && reference_fetch_policy_ok);reference_*, reference_signature_valid, and security_version_floor must come from an independent harness oracle, not DUT sticky/pass signals. If first_fetch and key_release use different clocks, check each in its event domain; this sketch does not prove CDC.
This snippet does not prove CDC, timing, side-channel, or physical injection behavior; each requires its own tool evidence or measurement.
Check your reasoning
- Recognition — What does a valid signature establish, and what remains undecided? Reasoning: It authenticates a signed bit string under the selected key. Version policy, target binding, the bytes eventually fetched, and key-release policy remain separate checks.
- Contrast — How is a version floor different from signature verification? Reasoning: A signature can be valid for an old image. The version floor rejects rollback according to policy; it does not authenticate the image by itself.
- Scenario — DMA can alter the verified buffer before the first instruction fetch. What must be bound or protected? Reasoning: The digest must describe the same bytes the CPU fetches. Lock or protect the loaded region, or verify at the actual consumption boundary.
- Failure diagnosis — A sticky boot_done bit came from the previous boot transaction. Why is it insufficient evidence for key release? Reasoning: The bit does not identify the current image or transaction. Bind transaction ID, digest, lifecycle, version, and destination key slot to this release.
- Design risk / transfer — A signed image may be fetched in debug lifecycle, but its production sideload key must stay unavailable. Which results should be recorded? Reasoning: Record first fetch and first key release independently. The fetch may be allowed while the production key release is rejected.
References
OpenTitan Key Manager · NIST SP 800-193
MY ACADEMY · LESSON FILM
Lesson video
The film explains this lesson’s data path. After a section, return to the interactive exercise and change the input or fault conditions. The animation presents a teaching model; it does not replace RTL simulation.
Swipe the film horizontally, or use the arrow keys to inspect the diagrams.
Diagram scope
Teaching model · Not RTL simulation or silicon testing
Uncompiled property sketches; not CDC, side-channel or physical-injection proof
Narration uses a synthetic voice. Both the interaction and animation have model boundaries; interpret results using this lesson’s sources and validation scope.
Wrap-up: take this lesson into a design review
- Threat model and assumptions
One boot transaction contains image digest, signature result, version floor, lifecycle and key slot; final fetch/release is the asset boundary.
- Why the design fails
The verification result is detached from the later consumer, or rollback/old sticky state reuses stale authorization.
- Defenses
Bind bytes, version, lifecycle and key slot in immutable transaction context; fail closed and protect the accepting endpoint.
- Validation and checks to perform
Check valid, stale, modified, swapped-image, and lifecycle-mismatch cases; RTL/signature/memory integration is untested.
- Limits and unverified claims
Product key policy, supply-chain root trust, side channels, physical key vault and recovery-image details are outside scope.
Try a changed assumption
Add rollback-counter update and concurrent DMA. Identify when contents must be locked and when sideload key release is safe.
This wrap-up summarizes the lesson’s teaching cases, references and experiment scope. Checks not reported as completed remain future work.