Question bank — Open hardware ecosystem (OpenRISC, OpenTitan)

False. An ISA is only a specification (the software–hardware contract, like the rules of chess); a fully proprietary, closed core can implement an open ISA, so ISA-openness never guarantees silicon-openness.

False. Only the design is published; the per-device secret keys live in fuses burned at manufacture, never in the RTL — this is exactly the "keys secret, design open" split from Kerckhoffs's Principle.

False. Attackers reverse-engineer chips anyway (decap plus electron microscopy), so secrecy buys almost nothing; publishing lets defenders audit for backdoors, so transparency is a fire alarm while obscurity is only a speed bump.

False. They are two different, incompatible ISAs — OpenRISC/ORBIS came first (~2000), RISC-V (Berkeley, ~2010) later, and their binaries are not interchangeable; OpenTitan actually uses RISC-V (Ibex), not OpenRISC.

False. A hash proves integrity (the image wasn't altered) but not authenticity; an attacker who swaps both image and its stored hash defeats it, which is why a signature binding the hash to a vendor-only private key is required.

False. Such an SoC is typically open only at the ISA layer; its microarchitecture, RTL and layout are usually proprietary — openness is per-layer (ISA / RTL / toolchain), and most commercial parts open only the first.

True. Because every instruction is a fixed 32 bits, the fetch unit sets $P{C}_{\text{next}}=PC+4$ unconditionally, so no decode is needed just to find the next instruction's start (unlike variable-length x86).

False. Everything above the Root of Trust trusts it implicitly, so a hidden backdoor there invalidates all higher layers — and you cannot verify the absence of a backdoor in a design you can't read; auditability is the whole point.

The error is "kept secret" — OpenTitan's RTL is published. Its security rests on secret keys in fuses and on collision-resistant hashing, not on hiding the design (Kerckhoffs's Principle).

The error is the exponent. Collision-finding follows the birthday bound $\approx 2^{n/2}=2^{128}$ for $n=256$, not $2^{256}$ — still infeasible, but the correct reasoning is half the bit-length.

The error is "rewritable flash." The anchoring key sits in one-time-programmable fuses precisely so an attacker cannot rewrite it and substitute their own trust anchor.

The error is the core name. OpenTitan's CPU is Ibex, a small RISC-V core; mor1kx is the flagship OpenRISC core — different ISA family entirely.

The second clause is wrong. OpenRISC is fixed-width: every instruction is exactly 4 bytes, so all six are 4 bytes and there is no variable-length shrinking as in x86; $6\times 4=24$ holds only because the width is uniform.

The error conflates ISA-openness with RTL-openness. You can fabricate Ibex royalty-free because Ibex's RTL is open-licensed — the openness of the ISA alone would not grant you any implementation to build.

The error is "can't apply." The law operates on the design source (RTL), which is text like software; publishing RTL lets many reviewers find flaws before fabrication, so the principle transfers directly.

Because everything booted afterward trusts the RoT unconditionally, an undetected backdoor there compromises the entire system, and you cannot audit for it in a black box — so for the most trust-bearing part, transparency is a necessity, not a luxury.

Storing every future image is impossible (they get updated after manufacture and are far too large for fused storage), so instead the chip stores only a small vendor public key and verifies each new image's signature against it — trust is anchored in a key, not in a copy.

With every instruction the same size, the address of the next one is a constant addition ($PC+4$), needing no decode of the current instruction; variable-length designs must partly decode an instruction just to learn where the next begins.

Because the RTL is freely licensed and published, the design survives even if its originating company folds — anyone can keep maintaining, re-fabricating or forking it, so it is not tied to one vendor's lifespan.

An attacker seeking any two images with the same hash exploits pairwise matches among many trials, so the expected first collision appears at about $1.18\cdot 2^{n/2}$ candidates — far fewer than the $2^n$ needed to hit one specific target hash.

The ISA only specifies behaviour (what instructions mean), not the implementation; a backdoor lives in the microarchitecture/RTL and layout, so you must have the RTL and layout open — not just the spec — to audit the silicon.

Yes by the formula ($2^{1/2}\approx 1.4$), meaning ~1–2 tries — which correctly signals that tiny hashes are useless: security depends on $n$ being large (256), so the birthday bound becomes astronomically big.

The Root of Trust refuses to hand off control to stage $i$, so the boot halts (or falls back to recovery) rather than running unverified code — the chain is only as long as the last successfully verified link.

Yes — the three layers are independent, so you might have an open compiler/simulator targeting a completely proprietary core; openness of one layer says nothing about the others.

Yes. Because RISC-V is only a specification, a vendor can implement it with secret RTL and layout; the software runs fine (the ISA contract is honoured) while the silicon remains a black box.

They can't on a properly built device — the key sits in one-time-programmable fuses that physically cannot be rewritten after burning, so the trust anchor is immutable; this is the boundary condition that makes the whole chain rest on hardware, not software.

No — the measurement $m_i=H(I_i)$ would be identical for both, so the signature check would pass for the malicious image too; this is exactly why collision-resistance of the hash is a hard requirement, not a nicety.