Threat Modeling for RISC-V: Identifying Silicon-Level Risks

Threat modeling is the practice of systematically identifying what can go wrong in a system before it goes wrong. For software systems, this discipline is reasonably well-established. For hardware, and particularly for silicon-level security in RISC-V processors, the practice is less mature and the stakes are higher: hardware vulnerabilities cannot be patched with a software update.

A RISC-V threat model must operate across multiple abstraction layers simultaneously. Threats at the physical layer (probing attacks, fault injection, side-channel extraction) interact with threats at the architectural layer (privilege escalation, memory safety violations) and the firmware layer (supply chain compromise, update attacks). A complete threat model must address all three layers and their interactions.

Defining the Security Perimeter

Before enumerating threats, a threat model must define what it is protecting. For a RISC-V embedded system, the critical assets typically include:

• Device identity keys: Private keys that establish the device's identity for attestation and authentication
• Data-at-rest: Sensitive data stored on the device that must not be accessible if the device is lost or stolen
• Firmware integrity: Assurance that the code running on the device is the code that was authorized to run
• Operational availability: The ability of the device to perform its intended function
• Isolation boundaries: The separation between different trust domains (e.g., security subsystem vs. application processor)

Physical Attack Surface

RISC-V embedded systems are often deployed in environments where an adversary may have physical access to the device. This opens attack vectors that do not exist for cloud-hosted systems:

Probing and fault injection: An attacker with physical access and appropriate equipment can probe memory buses, inject voltage glitches to cause single-bit errors in security-critical decisions, or use electromagnetic fault injection to corrupt instruction execution. These attacks have been demonstrated against commercial secure elements and ARM TrustZone implementations.

Cold boot attacks: For devices with DRAM, an attacker who can quickly cool the memory and transplant it to another device may be able to recover key material that was resident in memory before shutdown.

Debug interface exposure: JTAG and other debug interfaces, if not properly secured, provide direct memory access to a running system. RISC-V implementations vary in how robustly they protect debug interfaces; some implementations allow debug access with minimal authentication at the hardware level.

Side-channel attacks: Power analysis and electromagnetic emissions from cryptographic operations can leak secret key material even from systems with no software vulnerabilities. Differential power analysis (DPA) and simple power analysis (SPA) attacks are practical against hardware without dedicated countermeasures, including many RISC-V implementations where cryptographic operations run on the main core without side-channel mitigations.

Architectural Attack Surface

RISC-V's physical memory protection (PMP) mechanism is a critical security boundary, but it is only as strong as its configuration. Common architectural vulnerabilities include:

PMP misconfiguration: A misconfigured PMP that grants the application processor write access to security-critical memory regions undermines the entire isolation architecture. PMP configurations must be verified as part of the trusted boot process.

Privilege escalation via ISA extensions: RISC-V's modular ISA allows custom extensions that may introduce unexpected privilege escalation paths. Any custom extension that touches the machine-mode security architecture requires careful threat analysis.

Timer and interrupt attacks: Race conditions between security-critical operations and interrupt handlers are a known attack surface in RISC-V systems where the security subsystem shares interrupt infrastructure with the application processor.

Speculative execution side channels: High-performance RISC-V implementations with out-of-order execution and branch prediction are subject to speculative execution attacks analogous to Spectre and Meltdown on x86. While these attacks are generally harder to exploit on embedded RISC-V targets than on server processors, they deserve analysis in the threat model for any RISC-V implementation with a cache and speculative execution.

Supply Chain Threats

Supply chain attacks against embedded systems are increasingly sophisticated and increasingly common. For RISC-V platforms, the relevant threats include:

• Hardware trojans inserted at the foundry or packaging stage
• Counterfeit chips inserted into the supply chain after manufacturing
• Compromised bootloader or firmware inserted by a contract manufacturer
• Modified development tools that introduce backdoors in compiled code

Defending against hardware trojans at the silicon level requires a combination of design-for-test approaches that make unauthorized circuitry harder to hide, and post-silicon testing protocols that can detect anomalous circuit behavior.

Countering counterfeit chips requires strong device authentication: a chip that cannot prove its identity with a hardware-rooted attestation cannot be verified as genuine. This is one of the strongest arguments for implementing attestation infrastructure even for products that do not have obvious remote attestation use cases — the same attestation mechanism that enables runtime fleet verification also enables supply chain authenticity verification.

Adversary Capability Assumptions

A useful threat model calibrates its countermeasures to realistic adversary capabilities rather than defending against all possible attacks at all cost levels. The three adversary tiers most relevant to RISC-V embedded systems are:

Script kiddie / opportunistic attacker: Uses publicly available tools, has no physical access, targets known vulnerabilities. Countermeasure: timely firmware updates and verified boot that prevents known-vulnerable firmware from running.

Motivated adversary with physical access: Has physical access to one or more devices, can purchase lab equipment costing tens of thousands of dollars, and is targeting a specific product line. Countermeasure: fault injection countermeasures, debug interface authentication, and tamper detection.

Nation-state / advanced persistent threat: Unlimited resources, potential supply chain access, ability to run multi-year campaigns. Countermeasure: formal verification of security primitives, hardware security certification (FIPS, Common Criteria EAL), and air-gapped provisioning infrastructure.

Most commercial embedded products need to defend against the first two tiers. Products in defense, critical infrastructure, and healthcare should additionally address the third tier.

Threat Prioritization

A threat model is only useful if it leads to prioritized countermeasures. The zeroRISC threat prioritization framework uses three axes: likelihood (how likely is this attack given the deployment context?), impact (what is the worst-case outcome if this attack succeeds?), and detectability (how hard is this attack to detect or attribute?). High-likelihood, high-impact, low-detectability threats receive the highest priority.

For most RISC-V embedded deployments, the top-priority threat category is firmware supply chain compromise: it is relatively easy to execute, the impact is severe (full device control), and it may be undetectable without verified boot infrastructure. This is why we recommend starting with verified boot before addressing more exotic attack vectors.

The second-priority category for most deployments is debug interface exposure: JTAG attacks on devices in the field have been documented across many product categories, and remediation is straightforward if addressed at the hardware design stage but difficult to retrofit.

For a detailed threat modeling workshop tailored to your specific RISC-V deployment context, contact our security team. We work through each threat category systematically, map it to your specific deployment constraints, and produce a prioritized countermeasure roadmap that guides your security investment.