Open hardware ecosystem (OpenRISC, OpenTitan): Visual walkthrough

We are deriving one central claim:

A tamper on any boot stage is caught, because trust is anchored in a key that cannot be rewritten and a hash that cannot be forged.

Let us earn every symbol.

Step 1 — What "booting" even is (the naked chain)

WHAT. When a chip powers on it does not run your app immediately. It runs a tiny first program (the Root of Trust), which loads a slightly bigger one, which loads a bigger one, ... until the OS is up. Each program is called a boot stage. We label them $I_{0}, I_{1}, I_{2}, \dots$ where $I$ stands for image — literally the bytes of that stage's code sitting in memory.

WHY. We need names for the pieces before we can talk about protecting them. The subscript $i$ is just "which stage": $I_{0}$ is first, $I_{1}$ next, and so on.

PICTURE. Look at the row of orange boxes. An arrow "loads" points from each stage to the next. Right now nothing is checked — this is the unprotected chain an attacker dreams of.

Step 2 — The attacker's move, and why we need a fingerprint

WHAT. An attacker swaps a good image $I_{1}$ for a malicious one $I_{1}^{'}$ (the prime mark $^{'}$ just means "the tampered version"). If nothing checks the bytes, the chip happily runs $I_{1}^{'}$ .

WHY. To catch this we need a way to ask "is this the image I expected?" — cheaply, without storing a full copy of every stage. That is exactly what a hash function gives us.

PICTURE. The red box is $I_{1}^{'}$ sneaking into the slot where $I_{1}$ belonged. The question mark is the check we have not built yet.

Step 3 — The measurement $m_{i} = H (I_{i})$ , term by term

WHAT. OpenTitan computes the fingerprint of a stage before running it. We call this the measurement:

$measurement of stage i m_{i} = hash function H (the image bytes I_{i})$

$I_{i}$ — the raw bytes going in.
$H$ — the fingerprinting machine.
$m_{i}$ — the 256-bit fingerprint coming out.

WHY a hash and not, say, just comparing byte-by-byte to a stored copy? Because storing a full copy of every future stage inside the tiny RoT is impossible — the RoT is small. A 32-byte fingerprint is tiny yet uniquely pins down a multi-kilobyte image. That size collapse is the reason $H$ is the right tool here and a plain memory-compare is not.

PICTURE. Two images funnel through the same $H$ machine into two different fingerprints. Notice $I_{1}$ and the tampered $I_{1}^{'}$ produce different $m$ values — that difference is what we will detect.

Step 4 — Why a fingerprint alone is NOT enough

WHAT. Suppose we store the "correct" $m_{1}$ and compare. Problem: the attacker who can swap $I_{1}$ for $I_{1}^{'}$ can also overwrite the stored $m_{1}$ with $m_{1}^{'} = H (I_{1}^{'})$ . Now everything "matches" — but it is all the attacker's.

WHY. A hash proves integrity ("these bytes weren't corrupted") but NOT authenticity ("these bytes came from the real vendor"). We are missing a lock only the vendor can open.

PICTURE. The attacker replaces both the image and its fingerprint (two red arrows). The naive compare is fooled — it sees a matching pair.

Step 5 — The signature: a lock only the vendor can shut

WHAT. The vendor holds a secret private key $s k$ . Before shipping, they run a signing machine on the measurement to make a signature $σ_{i}$ (Greek letter sigma, "s" for signature):

$σ_{i} = Sign_{s k} (m_{i})$

The chip holds the matching public key $p k$ and checks:

$Verify_{p k} (σ_{i}, m_{i}) = true$

$s k$ — private key, never leaves the vendor.
$p k$ — public key, baked into the chip, safe to publish.
$σ_{i}$ — the signature: proof that whoever made it held $s k$ .
$Verify$ — returns true only if $σ_{i}$ genuinely signs this $m_{i}$ under $p k$ .

WHY a signature and not just a secret hash? Because of the magic of public-key signatures: you can verify with $p k$ but you cannot create a valid $σ$ without $s k$ . The attacker has $p k$ (it's public) yet still cannot forge a signature. That asymmetry is exactly the "lock only the vendor can shut" we needed in Step 4.

PICTURE. The vendor's side (green) signs with $s k$ ; the chip's side (blue) verifies with $p k$ . The attacker in the middle can see everything but can't produce a valid $σ$ for their $m_{1}^{'}$ .

Step 6 — Anchoring trust: the fuse that can't be rewritten

WHAT. One question remains: where does $p k$ live so the attacker can't swap that too? Answer: in one-time-programmable fuses. A fuse is a tiny wire deliberately blown once at manufacture; a blown fuse can never be un-blown.

WHY. Every "check" chain must bottom out in something the attacker cannot change. If $p k$ sat in normal rewritable flash, the attacker would install their own $p k^{'}$ and sign with their own key. Burning $p k$ (or a hash of it) into eFuses makes that impossible: physics, not software, protects it.

PICTURE. The blue key symbol sits inside a hatched "fuse" block. A red arrow labelled "cannot rewrite" bounces off it. This is the immovable anchor.

Step 7 — Chaining it: each stage vouches for the next

WHAT. Now stack the mechanism. The fused key verifies stage $I_{0}$ (the RoT firmware). Once $I_{0}$ is trusted, it verifies $I_{1}$ ; $I_{1}$ verifies $I_{2}$ ; and so on:

$p k_{fuse} \Rightarrow I_{0} \Rightarrow I_{1} \Rightarrow I_{2} \Rightarrow \dots$

where $\Rightarrow$ means "verifies the signature of, then hands off control to."

WHY. Each link is only followed after its signature checks out. Break any single link and the chain halts — the chip refuses to boot rather than run unverified code. This is the chain of trust.

PICTURE. A green chain: each link labelled with its measurement $m_{i}$ and signature $σ_{i}$ . One tampered link turns red and the chain visibly snaps — nothing past it runs.

Step 8 — The degenerate cases (never leave a gap)

WHAT & WHY. A derivation is only complete if every corner is covered. Four corners:

Case	What happens	Why the chain still holds
Tampered image, forged $σ$	attacker lacks $s k$	$Verify$ returns false → boot halts
*Tampered image, old valid* $σ$ (replay)**	attacker reuses a genuinely-signed old stage	version counters / anti-rollback fuses reject the stale measurement
Empty / zero image $I_{i} = \emptyset$	$H (\emptyset)$ is a fixed known value	its signature won't verify unless the vendor signed "empty", so it halts
$p k$ fuse un-blown (blank chip)	no anchor yet	provisioning burns $p k$ before first secure boot; a blank device is in a factory state, not a trusted one

PICTURE. Four mini-panels, one per case, each ending in either a red "HALT" or a green "OK" so you can see there is no scenario left unhandled.

The one-picture summary

Everything above compressed into a single diagram: bytes → hash → measurement → signature-verify against a fused key → hand off, repeated as a chain, with the attacker blocked at exactly the signature step.

Recall Feynman retelling — say it like you'd tell a friend

When the chip turns on, a tiny trusted program wakes up first. Before it runs the next program, it takes that program's bytes and squishes them through a fingerprinting machine (a hash) to get a short 32-byte tag — the measurement. But a fingerprint alone isn't enough, because a clever attacker could swap the program and its fingerprint. So the real manufacturer, using a secret key nobody else has, pre-signs each fingerprint. The chip only carries the public half of that key — baked into a fuse that can never be rewritten — and uses it to check the signature. The attacker can see the public key and can hash anything, but cannot forge the signature, so any tampered stage fails the check and the chip refuses to boot. Because each stage only trusts the next after this check passes, trust flows in an unbreakable chain, anchored in a fuse. That fused, immovable anchor is why it's called the Root of Trust — and why publishing the whole circuit design (the RTL) is safe: the secret is in the key, not in hiding the wires.

Recall Quick self-test

Why isn't a hash alone enough for secure boot? ::: A hash gives integrity but not authenticity; an attacker who can change the image can also change its stored hash. The signature (needing the vendor's private key) adds the authenticity the hash lacks. Where does the chain of trust bottom out, and why there? ::: In the public key burned into one-time-programmable fuses — because verification must end in something the attacker physically cannot rewrite. How many tries to forge a SHA-256 collision, and is that safe? ::: About $2^{128} \approx 3.4 \times 1 0^{38}$ — computationally infeasible, so collision-based attacks are closed in practice.

Related: ← back to the parent topic · RISC-V ISA · FPGA & RTL Verification