Building a Hardware Root of Trust for RISC-V: A Practical Guide

A hardware root of trust (HRoT) is the foundational security primitive from which all higher-level security guarantees in an embedded system derive their validity. Unlike software-based trust anchors, a properly implemented HRoT cannot be tampered with after manufacturing — making it the essential starting point for any serious embedded security architecture.

For RISC-V platforms, implementing a hardware root of trust presents both unique opportunities and distinct challenges. The open nature of the RISC-V ISA means you are not locked into a single silicon vendor's proprietary security model, but it also means the security architecture must be deliberately designed rather than inherited.

What Makes a Root of Trust "Hardware"

The distinction between hardware and software roots of trust is not merely academic. A software root of trust depends on the integrity of the software stack below it — a circular dependency that ultimately bottoms out in silicon. A hardware root of trust, by contrast, derives its integrity from physical properties: immutable memory programmed during manufacturing, physically unclonable functions (PUFs), or dedicated secure elements that are architecturally isolated from the main processor.

For RISC-V systems, the most practical approaches to hardware root of trust fall into three categories:

• One-time programmable (OTP) memory: Key material and device identity programmed at manufacturing time, readable but not writable by firmware
• Dedicated security subsystem: A separate RISC-V core running security firmware, isolated from the application processor via hardware partitioning
• Integrated secure boot ROM: Boot code stored in mask ROM or hardware-locked flash that executes before any other code

Each approach offers a different tradeoff between security strength, integration complexity, and silicon cost. The choice depends heavily on the threat model for the specific deployment and the resources available in the SoC budget.

Key Provisioning: Getting Identity Into Silicon

The security of any root of trust depends entirely on the secrecy of the initial key material. Key provisioning — the process of getting device-unique secret keys into hardware — is where most HRoT implementations fail in practice, not in theory.

The most robust approach for RISC-V platforms is to generate keys on-device using a hardware random number generator and a PUF-based seed, then provision only the public key material or certificate chain to a manufacturing database. This eliminates the key injection step that is typically the highest-risk moment in device manufacturing.

Where on-device key generation is not feasible due to silicon constraints, injection must occur in a Hardware Security Module (HSM)-controlled environment with strict physical and logical access controls. The key injection station should be air-gapped during provisioning and all provisioning events should be logged with cryptographic attestation.

Supply chain compromise during the provisioning step is a serious threat vector. A contract manufacturer with access to the key injection station could, in principle, extract device keys and use them to later impersonate devices in the field. Mitigations include using on-device key generation wherever feasible, limiting provisioning station access to the minimum required personnel, and using hardware-enforced logging that cannot be retroactively modified.

Attestation Flows on RISC-V

Once a root of trust is provisioned, the primary use case for most embedded deployments is remote attestation: the ability for a device to prove to an external verifier that it is running genuine, unmodified firmware on authenticated hardware.

A RISC-V attestation flow typically involves four phases:

• Measurement: Each boot stage hashes the next stage and records the hash in a Platform Configuration Register (PCR) or equivalent structure
• Quoting: The root of trust signs a summary of all recorded measurements using its device-unique key
• Verification: The relying party validates the signature against the expected device public key and checks measurements against known-good reference values
• Policy enforcement: The relying party grants or denies access based on attestation results

The design of the measurement structure matters significantly. Measurements should be extend-only: once a value is recorded, it cannot be modified by later boot stages. This property ensures that a compromised application cannot retroactively alter the measurement record to appear clean. On RISC-V, this is typically enforced by having the measurement registers located in the security subsystem and accessible only through controlled interfaces.

PUF-Based Identity: An Emerging Approach

Physically Unclonable Functions (PUFs) represent an increasingly attractive approach to device identity for RISC-V platforms. A PUF generates a reproducible but unpredictable output from the unique physical characteristics of a specific silicon die — variations in manufacturing that cannot be controlled or reproduced exactly.

PUF-based identity has a significant advantage over OTP-based identity: the secret value never exists in persistent storage where it could be extracted. The PUF output is regenerated on demand from the device's physical properties. Even an attacker who extracts all persistent storage from a device cannot recover the PUF-derived secrets.

The practical challenges of PUF deployment include reliability (PUF outputs can vary with temperature and aging) and enrollment (the device must be enrolled with its expected PUF output range during manufacturing, which requires secure handling of enrollment data). Several commercial IP vendors offer PUF implementations for RISC-V SoC integration with built-in error correction.

Common Implementation Pitfalls

Most HRoT implementations we review in the field share a set of recurring vulnerabilities. The most serious involve measurement coverage gaps: scenarios where firmware or configuration data that affects security properties is not included in the attestation measurement chain. If a hardware configuration register can be modified after the measurement phase, it may as well not be measured at all.

A second common failure is insufficient isolation between the security subsystem and the application processor. RISC-V hardware partitioning mechanisms vary widely across implementations — some provide robust physical memory protection units (PMPs) with fine-grained access control, while others rely on software-enforced boundaries that can be bypassed by a compromised OS kernel.

The zeroRISC platform addresses both issues by design: our measurement chain covers all security-relevant configuration registers, and our security subsystem operates on a dedicated RISC-V core with hardware-enforced isolation that cannot be overridden by application-layer software.

Next Steps

If you are evaluating hardware root of trust implementations for your RISC-V platform, start by mapping your threat model to specific HRoT capabilities. Not every use case requires the same level of protection. An industrial sensor with a 10-year field life in a physically secure location has very different requirements from an edge gateway exposed to potential physical attack.

Our team is available to review your specific architecture and identify the right implementation path. Contact us to discuss your requirements.