Open hardware ecosystem (OpenRISC, OpenTitan): Visual walkthrough

6.5.12 · D2 · Hardware › Advanced & Emerging Architectures › Open hardware ecosystem (OpenRISC, OpenTitan)

Hum ek central claim derive kar rahe hain:

Kisi bhi boot stage mein tamper pakda jaata hai, kyunki trust ek aisi key mein anchored hai jo rewrite nahi ho sakti aur ek aisa hash jo forge nahi ho sakta.

Aao har symbol ko earn karein.

Step 1 — "Booting" actually kya hai (the naked chain)

KYA. Jab ek chip power on hoti hai toh woh aapka app immediately nahi chalati. Woh pehle ek tiny pehla program chalati hai (the Root of Trust), jo ek thoda bada wala load karta hai, jo ek aur bada load karta hai, ... jab tak OS up nahi ho jaata. Har program ko ek boot stage kehte hain. Hum inhe $I_{0}, I_{1}, I_{2}, \dots$ label karte hain jahan $I$ ka matlab hai image — literally us stage ke code ke bytes jo memory mein baithe hain.

KYUN. Pieces ke naam chahiye pehle, tabhi hum unhe protect karne ki baat kar sakte hain. Subscript $i$ bas "konsa stage" hai: $I_{0}$ pehla hai, $I_{1}$ agla, aur aise hi.

PICTURE. Orange boxes ki row dekho. Har stage se agले tak ek "loads" arrow hai. Abhi kuch check nahi ho raha — yeh woh unprotected chain hai jiska ek attacker sapna dekhta hai.

Step 2 — Attacker ka move, aur kyun hume ek fingerprint chahiye

KYA. Ek attacker ek acchi image $I_{1}$ ki jagah ek malicious $I_{1}^{'}$ rakh deta hai (prime mark $^{'}$ ka matlab bas "tampered version" hai). Agar koi bytes check nahi karta, chip khushi se $I_{1}^{'}$ chala deti hai.

KYUN. Ise pakadne ke liye hume koi tarika chahiye yeh poochne ka ki "kya yeh wahi image hai jo mujhe expect thi?" — sasta tarika, bina har stage ki full copy store kiye. Yeh exactly wahi hai jo ek hash function deta hai.

PICTURE. Red box hai $I_{1}^{'}$ jo $I_{1}$ ki jagah slip kar raha hai. Question mark woh check hai jo humne abhi banaya nahi.

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

KYA. OpenTitan ek stage ka fingerprint compute karta hai use chalane se pehle. Hum ise measurement kehte hain:

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

$I_{i}$ — raw bytes jo andar ja rahe hain.
$H$ — fingerprinting machine.
$m_{i}$ — 256-bit fingerprint jo bahar aa raha hai.

KYUN hash aur, maan lo, simply byte-by-byte stored copy se compare nahi? Kyunki tiny RoT ke andar har future stage ki full copy store karna impossible hai — RoT chota hota hai. 32-byte fingerprint tiny hota hai phir bhi ek multi-kilobyte image ko uniquely pin down kar deta hai. Woh size collapse hi reason hai ki $H$ yahan sahi tool hai aur plain memory-compare nahi.

PICTURE. Do images same $H$ machine se funnel hokar do alag fingerprints mein jaati hain. Notice karo $I_{1}$ aur tampered $I_{1}^{'}$ alag $m$ values produce karte hain — woh difference hi hai jo hum detect karenge.

Step 4 — Kyun fingerprint akela ENOUGH nahi hai

KYA. Maano hum "correct" $m_{1}$ store karte hain aur compare karte hain. Problem: jo attacker $I_{1}$ ki jagah $I_{1}^{'}$ rakh sakta hai woh stored $m_{1}$ ko bhi $m_{1}^{'} = H (I_{1}^{'})$ se overwrite kar sakta hai. Ab sab kuch "match" karta hai — lekin sab attacker ka hai.

KYUN. Hash integrity prove karta hai ("yeh bytes corrupt nahi hue") lekin NOT authenticity ("yeh bytes real vendor se aaye"). Hume ek lock chahiye jo sirf vendor khol sake.

PICTURE. Attacker dono image aur uska fingerprint replace karta hai (do red arrows). Naive compare fool ho jaata hai — use ek matching pair dikhta hai.

Step 5 — Signature: ek lock jo sirf vendor band kar sakta hai

KYA. Vendor ek secret private key $s k$ rakhta hai. Shipping se pehle, woh measurement par signing machine chalate hain ek signature $σ_{i}$ banane ke liye (Greek letter sigma, "s" for signature):

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

Chip matching public key $p k$ rakhti hai aur check karti hai:

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

$s k$ — private key, vendor ko kabhi nahi chhodta.
$p k$ — public key, chip mein bake kiya hua, publish karna safe hai.
$σ_{i}$ — signature: proof ki jisne bhi banaya usne $s k$ hold kiya tha.
$Verify$ — true tabhi return karta hai jab $σ_{i}$ genuinely isi $m_{i}$ ko $p k$ ke under sign karta ho.

KYUN signature aur sirf secret hash nahi? Public-key signatures ke magic ki wajah se: aap $p k$ se verify kar sakte ho lekin $s k$ ke bina valid $σ$ create nahi kar sakte. Attacker ke paas $p k$ hai (woh public hai) phir bhi woh signature forge nahi kar sakta. Woh asymmetry exactly woh "lock jo sirf vendor band kar sake" hai jo hume Step 4 mein chahiye tha.

PICTURE. Vendor ka side (green) $s k$ se sign karta hai; chip ka side (blue) $p k$ se verify karta hai. Beech mein attacker sab kuch dekh sakta hai lekin unke $m_{1}^{'}$ ke liye valid $σ$ produce nahi kar sakta.

Step 6 — Trust anchor karna: woh fuse jo rewrite nahi ho sakta

KYA. Ek sawaal bacha hai: $p k$ kahan rehta hai taaki attacker woh bhi swap na kar sake? Jawab: one-time-programmable fuses mein. Ek fuse ek tiny wire hai jo manufacture ke time deliberately ek baar deliberately blow ki jaati hai; ek blown fuse kabhi un-blown nahi ho sakti.

KYUN. Har "check" chain ko kisi aisi cheez mein bottom out karna hoga jise attacker change nahi kar sakta. Agar $p k$ normal rewritable flash mein hota, attacker apna khud ka $p k^{'}$ install kar deta aur apni key se sign kar deta. $p k$ (ya uska hash) ko eFuses mein burn karna ise impossible bana deta hai: physics, software nahi, ise protect karta hai.

PICTURE. Blue key symbol ek hatched "fuse" block ke andar baith hai. Ek red arrow labelled "cannot rewrite" uspe bounce karta hai. Yeh woh immovable anchor hai.

Step 7 — Chain banana: har stage agले ki guarantee deta hai

KYA. Ab mechanism ko stack karo. Fused key stage $I_{0}$ (RoT firmware) ko verify karti hai. Jab $I_{0}$ trusted ho jaata hai, woh $I_{1}$ verify karta hai; $I_{1}$ $I_{2}$ verify karta hai; aur aise hi:

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

jahan $\Rightarrow$ ka matlab hai "signature verify karta hai, phir control hand off karta hai."

KYUN. Har link sirf tabhi follow kiya jaata hai jab uska signature check out ho. Koi bhi single link todo aur chain halt ho jaati hai — chip unverified code chalane se mana kar deti hai boot karne ki bajay. Yahi chain of trust hai.

PICTURE. Ek green chain: har link apne measurement $m_{i}$ aur signature $σ_{i}$ se labelled. Ek tampered link red ho jaata hai aur chain visibly snap ho jaati hai — uske baad kuch nahi chalta.

Step 8 — Degenerate cases (koi gap mat chhodna)

KYA & KYUN. Ek derivation tabhi complete hai jab har corner covered ho. Chaar corners:

Case	Kya hota hai	Kyun chain phir bhi hold karti hai
Tampered image, forged $σ$	attacker ke paas $s k$ nahi	$Verify$ false return karta hai → boot halt
*Tampered image, old valid* $σ$ (replay)**	attacker genuinely-signed purana stage reuse karta hai	version counters / anti-rollback fuses stale measurement reject karte hain
Empty / zero image $I_{i} = \emptyset$	$H (\emptyset)$ ek fixed known value hai	uska signature verify nahi karega jab tak vendor ne "empty" sign na kiya ho, toh halt
$p k$ fuse un-blown (blank chip)	abhi koi anchor nahi	provisioning pehle secure boot se pehle $p k$ burn karta hai; ek blank device factory state mein hai, trusted nahi

PICTURE. Chaar mini-panels, har case ke liye ek, har ek ya toh red "HALT" ya green "OK" pe khatam hota hai taaki aap dekh sako ki koi scenario unhandled nahi hai.

Ek-picture summary

Upar sab kuch ek single diagram mein compress kiya: bytes → hash → measurement → signature-verify fused key ke against → hand off, ek chain ke roop mein repeat, attacker exactly signature step par blocked.

Recall Feynman retelling — aise batao jaise kisi dost ko bataoge

Jab chip on hoti hai, pehle ek tiny trusted program jaagta hai. Agla program chalane se pehle, woh us program ke bytes leta hai aur unhe ek fingerprinting machine (ek hash) se squish karta hai ek short 32-byte tag banane ke liye — woh measurement. Lekin fingerprint akela kaafi nahi, kyunki ek clever attacker program aur uska fingerprint dono swap kar sakta hai. Toh real manufacturer, ek secret key use karke joh aur kisi ke paas nahi, pehle se har fingerprint sign karta hai. Chip sirf us key ka public half carry karti hai — ek fuse mein bake kiya hua jo kabhi rewrite nahi ho sakta — aur signature check karne ke liye use karti hai. Attacker public key dekh sakta hai aur kuch bhi hash kar sakta hai, lekin signature forge nahi kar sakta, toh koi bhi tampered stage check fail kar deti hai aur chip boot karne se mana kar deti hai. Kyunki har stage agले par tabhi trust karti hai jab yeh check pass ho, trust ek unbreakable chain mein flow karta hai, ek fuse mein anchored. Woh fused, immovable anchor hi reason hai ise Trust ka Root kyun kehte hain — aur isi liye poora circuit design publish karna (RTL) safe hai: secret key mein hai, wires hide karne mein nahi.

Recall Quick self-test

Secure boot ke liye hash akela kyun enough nahi hai? ::: Hash integrity deta hai lekin authenticity nahi; jo attacker image change kar sakta hai woh uska stored hash bhi change kar sakta hai. Signature (vendor ki private key ki zarurat hoti hai) woh authenticity add karta hai jo hash mein nahi. Chain of trust kahan bottom out hoti hai, aur kyun wahan? ::: Public key mein jo one-time-programmable fuses mein burn ki gayi hai — kyunki verification ko kisi aisi cheez mein khatam hona chahiye jo attacker physically rewrite nahi kar sakta. SHA-256 collision forge karne mein kitni tries lagti hain, aur kya yeh safe hai? ::: Lagbhag $2^{128} \approx 3.4 \times 1 0^{38}$ — computationally infeasible, toh collision-based attacks practice mein closed hain.

Related: ← parent topic par wapas · RISC-V ISA · FPGA & RTL Verification