zeroRISC
Secure boot is well understood. The concept is simple: before executing code, verify its cryptographic signature against a trusted key. If the signature checks out, boot proceeds. If it does not, execution halts. In the 1990s and 2000s, this was a meaningful security advancement. By 2026, it is the minimum viable baseline — and for RISC-V embedded systems, the minimum is rarely sufficient.
Verified firmware boot goes further. Rather than simply checking whether code was signed by a trusted party, verified boot establishes a continuous chain of cryptographic evidence about the exact state of a system at boot time, making that evidence available to remote parties who need to make trust decisions about the device.
The Limitations of Classic Secure Boot
Standard secure boot implementations share a fundamental structural weakness: they verify that code was signed, not that the code is correct or uncompromised relative to a known reference. A signed firmware image that contains a vulnerability is verified as legitimate. A device that has been running compromised code for months may have had its secure boot keys extracted and used to re-sign the malicious firmware.
For embedded systems with long field lives — industrial controllers, medical devices, infrastructure hardware — this matters enormously. The threat landscape at the time of deployment is not the threat landscape three years into a device's operational life. Security architectures that cannot reason about runtime integrity are architectures that age poorly.
RISC-V platforms introduce additional complexity because the ecosystem is heterogeneous. Unlike x86 systems where UEFI provides a reasonably standardized secure boot interface, RISC-V implementations vary widely in their boot ROM capabilities, their cryptographic hardware support, and their memory protection mechanisms. A secure boot implementation that is correct for one RISC-V implementation may be inadequate for another.
Key rollback is another gap in classic secure boot. A device that receives a firmware rollback — either through an attacker-controlled update or a misconfigured update service — may be downgraded to a version with known vulnerabilities. Without anti-rollback hardware support, a device that successfully boots a vulnerable firmware version appears as legitimate to a secure boot check as one running the current version.
Verified Boot: Measurement-Based Security
Verified firmware boot extends secure boot by adding a measurement layer. At each stage of the boot process, the executing code hashes the code it is about to launch and records that hash in tamper-resistant storage before transferring control. The resulting sequence of measurements forms a log that captures the exact boot path the device took.
This measurement log serves three functions that classic secure boot cannot provide:
- Post-hoc auditability: The log can be inspected to understand what code ran at boot time, even after the fact
- Remote attestation: A relying party can request a signed quote of the measurement log to verify the device's boot state before trusting it
- Policy enforcement: Access control decisions can be conditioned on verified boot state, not just device identity
Implementing Verified Boot on RISC-V
A practical verified boot implementation for RISC-V requires three hardware components that not all implementations provide: a hardware random number generator for key generation, a tamper-resistant storage mechanism for measurement logs (PCRs or equivalent), and a hardware-rooted attestation key that the processor cannot access directly.
The boot sequence for a RISC-V system with verified boot typically proceeds as follows. First, the machine mode boot ROM executes from mask ROM or locked flash, verifies the bootloader, and records the bootloader hash. The bootloader then verifies the operating system kernel or security firmware, records those hashes, and transfers control. At each stage, the measurement chain extends.
The critical security property is that measurement recording must be architecturally enforced — it cannot be something that well-behaved software does voluntarily. On RISC-V, this typically means using a dedicated security subsystem with hardware-enforced isolation from the main application processor, similar to the ARM TrustZone model but implemented through RISC-V's physical memory protection units and potentially through a separate security core.
Anti-Rollback and Monotonic Counters
A complete verified boot implementation must address firmware rollback: an attacker's ability to downgrade a device to a firmware version with known vulnerabilities. Hardware-enforced anti-rollback requires a monotonic counter stored in one-time-programmable memory: each firmware version is associated with a minimum counter value, and the boot ROM refuses to boot firmware whose minimum counter requirement is below the current counter value.
RISC-V SoCs that support hardware anti-rollback provide this through OTP-based monotonic counters in the security subsystem. For devices without hardware anti-rollback support, software-based solutions using EEPROM counters are a weaker alternative that is still better than no anti-rollback protection at all.
The interaction between anti-rollback and key management requires careful design. If a firmware update changes the attestation key rotation policy, devices rolled back to a previous firmware version may present attestation credentials that the updated relying party infrastructure no longer accepts. This edge case must be addressed in the update protocol design.
Firmware Update Considerations
Verified boot interacts non-trivially with firmware update mechanisms. A secure over-the-air update system must update not just the firmware image but also the reference measurements against which future attestations will be verified. This requires a carefully designed update protocol that does not create a window during which the device appears to be in a compromised state to remote verifiers.
The zeroRISC platform includes an atomic update mechanism that maintains boot verification continuity through firmware updates: new measurements are pre-registered with the attestation service before the update is applied, so the transition from old to new firmware is verifiable without a measurement gap.
Update delivery itself must be authenticated and integrity-protected. An update channel that can be injected with malicious images is not a secure update mechanism. The zeroRISC SDK includes a reference update client that validates server-side update signatures against a hardware-pinned update key before applying any update, with optional mutual TLS for transport-layer protection.
What This Means for Your Architecture
If you are designing a RISC-V embedded system for deployment in a regulated environment or one where remote security verification will be required, verified boot is not optional — it is the foundation on which every other security control depends. The question is not whether to implement it, but how to do so correctly given your specific hardware constraints.
Our team works with RISC-V chip designers and embedded software engineers to design and implement verified boot architectures suited to specific deployment contexts. Whether you are starting from a clean-sheet RISC-V SoC design or retrofitting security capabilities into an existing platform, we can help you identify the right architecture and the gaps that need to be addressed. Contact us to discuss your architecture.
