zeroRISC
In a distributed system, how do you know that the device you are communicating with is the device it claims to be, running the firmware it claims to be running, on hardware that has not been tampered with? This is the problem remote attestation solves — and in the RISC-V embedded ecosystem, it is a problem that has historically been difficult to solve well.
Remote attestation is not authentication. Authentication answers "is this the device with key K?" Attestation answers "is this the device with key K, running software S, on hardware H, without evidence of tampering?" The additional dimensions matter enormously in deployment contexts where authenticated but compromised devices are a primary threat vector.
The Attestation Architecture
A complete remote attestation system for RISC-V requires three categories of components: hardware primitives on the attesting device, attestation protocols that convey evidence, and verification infrastructure on the relying party side.
Hardware primitives: The attesting device requires a hardware-rooted attestation key that the main application processor cannot access or extract, a mechanism to record boot measurements (PCRs or equivalent), and a signing engine that can produce attestation quotes over those measurements without exposing the attestation key.
Attestation protocols: The evidence conveyed by an attestation quote must be structured such that a verifier can extract the boot measurements, verify the signature against the device's registered public key, and compare measurements against reference values. DICE (Device Identifier Composition Engine) and RATS (Remote Attestation Procedures) are the most relevant standards frameworks for RISC-V attestation.
Verification infrastructure: The relying party needs access to a reference value database containing the expected boot measurements for each firmware version, the public keys or certificate chains for registered devices, and policy logic that maps verification results to access decisions.
DICE: The Foundational Standard
The Device Identifier Composition Engine (DICE) specification from the Trusted Computing Group defines how device identity and attestation keys should be derived across boot layers. DICE is particularly well-suited to RISC-V systems because it does not assume a specific hardware implementation — it defines the cryptographic relationships between identity layers in a way that can be realized through various hardware mechanisms.
In a DICE-based RISC-V attestation architecture, each boot layer derives a unique key by hashing a combination of the layer's own firmware measurement and a "Unique Device Secret" held in the hardware root of trust. The resulting key hierarchy provides both device identity and firmware integrity attestation in a single protocol.
This is important for RISC-V deployments because DICE does not require a dedicated TPM chip. The same cryptographic properties can be achieved through a dedicated security subsystem on a RISC-V SoC, making attestation feasible at IoT price points where adding a discrete TPM is cost-prohibitive.
IETF RATS: The Protocol Framework
The IETF RATS (Remote ATtestation procedureS) working group has defined a framework for remote attestation that generalizes beyond TPM-specific approaches. The RATS architecture introduces standardized roles: the Attester (the device being attested), the Verifier (the service that evaluates attestation evidence), and the Relying Party (the service that uses verification results to make access decisions).
This separation of roles is valuable in enterprise deployments where the verification function may be provided by a specialized service while the relying party is the actual application server or cloud service. For RISC-V device fleets, the RATS model maps naturally to architectures where the zeroRISC attestation service acts as the Verifier and the customer's service acts as the Relying Party.
RATS also standardizes the format of attestation evidence through Entity Attestation Tokens (EATs), which are CBOR-encoded structures suitable for constrained embedded devices. EATs are now supported by the zeroRISC SDK and are the preferred format for new RISC-V attestation implementations.
Attestation in Practice
The typical attestation flow for a RISC-V device connecting to a fleet management service proceeds as follows:
- Device boots through the verified boot sequence, recording firmware measurements at each stage
- At application startup, the device generates an attestation quote: a signed structure containing the boot measurements, a nonce from the relying party (to prevent replay), and device metadata
- The relying party verifies the quote signature against the device's registered attestation key, checks the nonce, and evaluates the measurements against the reference value database
- Based on the verification result, the relying party either grants the device access to the service or initiates a remediation flow
The nonce is critical: without it, a compromised device could replay a previously valid attestation quote. The nonce must be freshly generated by the relying party for each attestation session and must be incorporated into the signed quote.
Reference Values and the Supply Chain
The reference value database — the set of expected firmware measurements against which attestation quotes are compared — is a critical security artifact that is often underestimated in attestation architecture discussions. A reference value database that contains incorrect or stale values will produce false negatives (rejecting legitimate devices) or false positives (accepting compromised devices).
Maintaining accurate reference values requires tight integration between the firmware build pipeline and the attestation service. Every firmware release must produce attestation reference values as a build artifact, and those values must be enrolled in the attestation service before devices can receive the firmware update. The zeroRISC platform includes tooling for automated reference value generation and enrollment as part of the CI/CD pipeline.
Handling Failed Attestations
A complete attestation system must define what happens when a device fails attestation. The options range from blocking all access (maximally secure, potentially operationally disruptive) to allowing read-only access for diagnostics to automatically triggering a firmware recovery flow.
For most deployments, we recommend a tiered response: a device that presents a valid signature but unexpected firmware measurements is treated as potentially compromised and routed to a quarantine environment where it can receive a firmware update but cannot access production data. A device that presents an invalid signature is treated as a hard security failure and blocked entirely.
The zeroRISC attestation service provides configurable policy enforcement for both scenarios, with audit logging for compliance and incident response purposes. Policy rules can be defined per device class, per deployment region, or per firmware version, giving operators fine-grained control over the security-usability tradeoff in their fleet.
For help implementing remote attestation in your RISC-V deployment, contact our engineering team.
