Implementing Secure Bootloaders on RISC-V

The Boot Security Challenge

RISC-V is gaining traction in safety-critical and industrial applications. As an open ISA, it offers unprecedented flexibility — but also requires careful implementation of the secure boot chain from first principles.

Unlike ARM or x86 platforms that ship with immutable boot ROMs, most RISC-V SoCs leave the early boot stages fully programmable. This is both a feature (full control) and a liability (single point of trust).

Root of Trust: The Hardware Foundation

The secure boot chain begins with an immutable Root of Trust (RoT). In a typical RISC-V configuration, this lives in a one-time-programmable (OTP) region of the SoC:

# Minimal RoT entry — RISC-V assembler
.section .boot_rom
.globl _start
_start:
    # Initialize SHA-512 hardware accelerator
    li      a0, SHA512_INIT
    csrrw   a0, SHA512_CTRL, a0
    
    # Load public key from OTP
    li      a0, OTP_BASE
    li      a1, 64
    ecall   OTP_READ
    
    # Verify stage-1 signature
    ecall   VERIFY_SIGNATURE
    bnez    a0, halt
    jmp     STAGE_1_LOAD
    
halt:
    wfi                     # Wait for interrupt — dead

The key property here is immutability — the RoT code never changes after manufacturing.

Layered Verification

A practical RISC-V secure boot implements three verification stages:

┌─────────────────────────────────────┐
│  RoT (OTP) — verified by hardware   │
│      ↓ verifies                      │
│  Stage 1 — flash-resident bootloader │
│      ↓ verifies                      │
│  Stage 2 — firmware updater          │
│      ↓ verifies                      │
│  Application — OS/kernel             │
└─────────────────────────────────────┘

Each stage verifies the cryptographic signature of the next before transferring control.

Cryptographic Choices for Constrained Environments

RISC-V microcontrollers (e.g., RV32ECore) have severe constraints:

Algorithm	Code size	Verify time (RV32)	Security
Ed25519	4.2 KB	~8 ms	128-bit
ECDSA P-256	6.8 KB	~15 ms	128-bit
RSA-2048	8.1 KB	~45 ms	112-bit
SHA-256 + HMAC	1.2 KB	~2 ms	128-bit

Ed25519 is the recommended trade-off on constrained RISC-V hardware: small code footprint, fast verification, and no need for a hardware random number generator (deterministic).

Fallback and Recovery

No security chain is complete without a recovery path. If verification fails at any stage, the system must allow signed recovery without breaking security guarantees:

typedef struct {
    uint32_t magic;          // 0xA5F1R5C0
    uint32_t version;        // monotonic counter
    uint8_t  signature[64];  // Ed25519
    uint32_t payload_crc32;
    uint8_t  payload[0];     // variable length
} RecoveryHeader;

bool try_recovery(void) {
    // Check if recovery trigger asserted (button or GPIO)
    if (!gpio_read(PIN_RECOVERY)) return false;
    
    RecoveryHeader *hdr = (RecoveryHeader*)RECOVERY_BASE;
    if (hdr->magic != 0xA5F1R5C0) return false;
    if (hdr->version <= last_valid_version) return false;
    
    return ed25519_verify(pub_key, hdr, sizeof(*hdr), hdr->signature);
}

The recovery image must be signed with the same key or a designated recovery key stored in a separate OTP region.

Conclusion

Secure boot on RISC-V requires careful partitioning of trust, efficient cryptographic primitives, and a failsafe recovery mechanism. By layering verification stages and choosing algorithms suited to constrained hardware, you can achieve hardware-grade security guarantees on an open platform.