Exercises — Open hardware ecosystem (OpenRISC, OpenTitan)

• ISA (the spec / contract between software and hardware) — e.g. RISC-V or OpenRISC ORBIS.
• Microarchitecture / RTL (the actual gate-level implementation) — e.g. Ibex or mor1kx.
• Toolchain (compiler, simulator, EDA flow) — e.g. GCC, Verilator, OpenROAD.

They are independent: a chip can be open at one layer and closed at another. See FPGA & RTL Verification for where the RTL layer lives.

A Root of Trust is the first component to boot. It measures (hashes) and verifies each later stage before handing off control, so everything above it trusts it implicitly. OpenTitan is a silicon Root of Trust; its CPU core is Ibex, a RISC-V core.

(c) is true. (a) is false — OpenTitan uses RISC-V (Ibex), not OpenRISC. (b) is false — an ISA is only a specification; a closed core can implement an open ISA. Statement (c) is exactly Kerckhoffs's Principle applied to silicon.

• Why $4N$? Every OpenRISC instruction is fixed at $32$ bits $=4$ bytes, so $\text{Bytes}=4N=4\times 18=\boxed{72}$ bytes.
• Addresses start at $0$ and step by $4$: the $k$-th instruction (counting from $0$) sits at $4k$. The last is $k=17$, at $4\times 17=68=\text{0x44}$.
• The next free byte is $72=\text{0x48}$ — matching $4N$. ✔

$\text{0x3C}=60$. That address is the last instruction, so it is instruction number $60/4=15$ counting from $0$ — i.e. the 16th instruction. So $N=16$. Check: $4N=64=\text{0x40}$ is the first free byte, one word past $\text{0x3C}$. ✔

• Why halve the bits? Collisions follow the birthday bound: among random $n$-bit values the first collision is expected near $2^{n/2}$ tries (see Cryptographic Hash Functions).
• Here $n=224$, so effort $\approx 2^{224/2}=2^{112}$ images.
• That is astronomically large, so forging a different image with the same measurement is infeasible. ✔

Attack: replace $I_i$ with a malicious $I_i^{\prime }$ and overwrite the stored hash with $H(I_i^{\prime })$. On boot the recomputed hash matches the (also-replaced) stored value, so it passes. Missing property: the scheme proves integrity (image not corrupted) but not authenticity (image came from the vendor). A signature ${\sigma }_i$ binds $m_i$ to the vendor's private key, which the attacker does not hold, so the forged pair fails verification. See Secure Boot & Chain of Trust.

$pk$ is burned into one-time-programmable fuses (see One-Time-Programmable Fuses (eFuse)). These fuses physically transition once (a metal link is blown) and cannot be rewritten — there is no electrical path back. So the attacker cannot swap in their own public key. Trust bottoms out in an immutable physical fact, not in software that could be patched. This is the "anchor" of the chain of trust.

They never run. Each stage only hands control forward after verifying the next stage's measurement. A failure at stage $2$ halts the hand-off, so stages $3$ and $4$ are never even measured, let alone executed. The chain is only as strong as its first broken link — that is the whole point of a chain of trust.

(i) Secrecy buys little: attackers reverse-engineer chips anyway via decapsulation and electron microscopy — the circuit is already readable to a determined adversary, so hiding it mostly stops defenders from auditing. (ii) What actually secures it: the secret keys in fuses, per Kerckhoffs's Principle — security must rest on keys, not on secrecy of design. Publishing the RTL turns the whole world into reviewers, so bugs are found before they're exploited (auditability). Obscurity is a speed bump; transparency is a fire alarm.

Remove any one and the chain breaks: no hash → can't detect edits; no signature → hash is forgeable (L3.1); no fuse → key is swappable (L3.2); no immutable first code → attacker runs their own verifier first.

1. Ecosystem & formal analysis: Ibex is small and has been formally analysed, exactly what a Root of Trust needs, and it rides the large modern RISC-V toolchain and verification community (FPGA & RTL Verification).
2. Proven integration: Ibex is already the core of OpenTitan, a shipping open silicon RoT — you inherit its secure-boot, key-storage and crypto-accelerator surroundings rather than rebuilding them. (OpenRISC predates RISC-V and is a fine general CPU, but the RoT tooling has coalesced around Ibex/RISC-V.)

Move 1 — fails at the hash. The stored measurement is $m_3=H(I_3)$. The malicious image hashes to something else, so $H(I_3^{\prime })\ne m_3$ and the integrity check rejects it before any signature step.

Move 2 — fails at the signature. Now the recomputed hash matches the (also-swapped) $m_3$, so integrity passes. But the signature ${\sigma }_3$ was made over the original $m_3$ with the vendor's private key. Verifying the new $m_3$ against $pk$ fails, because the attacker cannot produce a valid signature without the private key (authenticity holds — this is exactly L3.1).

Move 3 — infeasible. A collision would let the malicious image share the same measurement, so the old signature would still verify. But SHA-256 is $256$-bit, and by the birthday bound the expected number of attempts is $\approx 2^{256/2}=2^{128}\approx 3.4\times 10^{38},$ which is computationally impossible. So this door is closed.

Move 4 — fails at the fuses. The public key lives in one-time-programmable fuses that physically cannot be rewritten (L3.2). The attacker cannot install their own key, so their self-signed images never verify against the real anchor.

Conclusion: every path is blocked — the design has no weak layer. Integrity (hash), authenticity (signature), and an immutable anchor (fuses) together give complete coverage. That is why secure boot works, and why the design being open does not help the attacker at all — nothing here relied on secrecy of the circuit.

Which formula gives OpenRISC code size? ::: $\text{Bytes}=4N$ (fixed 32-bit instructions). Which formula gives collision effort for an $n$-bit hash? ::: $\approx 2^{n/2}$ (birthday bound). What single physical fact anchors the whole chain of trust? ::: The public key burned into one-time-programmable fuses.