Open hardware ecosystem (OpenRISC, OpenTitan): Exercises

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

Level 1 — Recognition

Inhe tum yaad karke aur point karke answer kar sakte ho, koi calculation nahi.

L1.1 — Teen layers ke naam batao

Recall Solution

ISA (software aur hardware ke beech ka spec / contract) — jaise RISC-V ya OpenRISC ORBIS.
Microarchitecture / RTL (actual gate-level implementation) — jaise Ibex ya mor1kx.
Toolchain (compiler, simulator, EDA flow) — jaise GCC, Verilator, OpenROAD.

Ye independent hain: ek chip ek layer par open aur doosri par closed ho sakti hai. RTL layer kahan hoti hai, yeh jaanne ke liye FPGA & RTL Verification dekho.

L1.2 — Root of Trust ek sentence mein

Recall Solution

Root of Trust woh pehla component hota hai jo boot karta hai. Yeh control aage dene se pehle har baad wale stage ko measure (hash) aur verify karta hai, isliye uske upar sab kuch use par implicitly trust karta hai. OpenTitan ek silicon Root of Trust hai; iski CPU core Ibex hai, jo ek RISC-V core hai.

L1.3 — Sahi statement dhundho

Recall Solution

(c) sahi hai. (a) galat hai — OpenTitan RISC-V (Ibex) use karta hai, OpenRISC nahi. (b) galat hai — ek ISA sirf ek specification hai; ek closed core open ISA implement kar sakta hai. Statement (c) bilkul wahi hai jо Kerckhoffs's Principle ko silicon par apply karta hai.

Level 2 — Application

Ab tum parent note ke do formulas mein numbers plug karoge: $Bytes = 4 N$ (fixed-width code size) aur birthday bound $\approx 2^{n /2}$ .

L2.1 — Code size

Recall Solution

$4 N$ kyun? Har OpenRISC instruction fixed $32$ bits $= 4$ bytes ka hota hai, isliye $Bytes = 4 N = 4 \times 18 = 72$ bytes.
Addresses $0$ se shuru hote hain aur $4$ se step karte hain: $k$ -waan instruction ( $0$ se count karte hue) $4 k$ par hota hai. Last hai $k = 17$ , $4 \times 17 = 68 = 0x44$ par.
Agla free byte $72 = 0x48$ hai — $4 N$ se match karta hai. ✔

L2.2 — Formula ko reverse karo

Recall Solution

$0x3C = 60$ . Woh address last instruction hai, isliye $0$ se count karte hue yeh instruction number $60/4 = 15$ hai — yaani 16th instruction. To $N = 16$ . Check: $4 N = 64 = 0x40$ pehla free byte hai, $0x3C$ ke ek word baad. ✔

L2.3 — Collision effort

Recall Solution

Bits kyun aadhe karo? Collisions birthday bound follow karti hain: random $n$ -bit values mein pehli collision $2^{n /2}$ tries ke aas-paas expect ki jaati hai (dekho Cryptographic Hash Functions).
Yahan $n = 224$ hai, isliye effort $\approx 2^{224/2} = 2^{112}$ images.
Yeh astronomically bada hai, isliye same measurement ke saath ek alag image forge karna infeasible hai. ✔

Level 3 — Analysis

Yahan tumhe kyun ek mechanism kaam karta hai ya nahi, iske baare mein reason karna hai.

L3.1 — Hash-only boot

Recall Solution

Attack: $I_{i}$ ko ek malicious $I_{i}^{'}$ se replace karo aur stored hash ko $H (I_{i}^{'})$ se overwrite karo. Boot par recomputed hash (bhi-replace-hue) stored value se match karta hai, isliye yeh pass ho jaata hai. Missing property: yeh scheme integrity prove karta hai (image corrupt nahi hui) lekin authenticity nahi (image vendor ki taraf se aayi). Ek signature $σ_{i}$ $m_{i}$ ko vendor ki private key se bind karta hai, jo attacker ke paas nahi hai, isliye forged pair verification fail karta hai. Dekho Secure Boot & Chain of Trust.

L3.2 — Trust kahan bottom out karta hai?

Recall Solution

$p k$ one-time-programmable fuses mein burn hoti hai (dekho One-Time-Programmable Fuses (eFuse)). Ye fuses physically ek baar transition karti hain (ek metal link blow hoti hai) aur rewrite nahi ki ja sakti — wapas jaane ka koi electrical path nahi hai. Isliye attacker apni khud ki public key swap nahi kar sakta. Trust ek immutable physical fact mein bottom out karta hai, software mein nahi jo patch ki ja sake. Yahi chain of trust ka "anchor" hai.

L3.3 — Chain padhna

Recall Solution

Woh kabhi nahi chalte. Har stage control aage sirf tab deta hai jab next stage ka measurement verify ho jaaye. Stage $2$ par failure hand-off rok deta hai, isliye stages $3$ aur $4$ kabhi measure bhi nahi hote, execute hone ki baat to door. Chain sirf apni pehli tooti hui link jitni mazboot hoti hai — chain of trust ka poora yehi point hai.

Level 4 — Synthesis

Open-hardware philosophy ko concrete mechanisms ke saath combine karo.

L4.1 — Sceptic ko steel-man karo

Recall Solution

(i) Secrecy kam kaam aati hai: attackers waise bhi chips ko decapsulation aur electron microscopy se reverse-engineer kar lete hain — circuit ek determined adversary ke liye already readable hai, isliye use chupaana zyaatar defenders ko audit karne se rokta hai. (ii) Ise actually secure kya karta hai: fuses mein secret keys, per Kerckhoffs's Principle — security design ki secrecy par nahi, keys par honi chahiye. RTL publish karna poori duniya ko reviewers bana deta hai, isliye bugs exploit hone se pehle milte hain (auditability). Obscurity ek speed bump hai; transparency ek fire alarm hai.

L4.2 — Ek minimal RoT design karo

Recall Solution

Ingredient	Kaun si property supply karta hai
Collision-resistant hash $H$	integrity — image mein koi bhi change detect karta hai
Signature scheme ( $p k$ se Verify)	authenticity — prove karta hai ki vendor ne banaya
$p k$ OTP fuses mein	immutable trust anchor — attacker key swap nahi kar sakta
First-to-boot, immutable ROM code	ensure karta hai ki yahi verifier pehle chale

Koi bhi ek hatao aur chain toot jaati hai: no hash → edits detect nahi ho sakti; no signature → hash forgeable hai (L3.1); no fuse → key swappable hai (L3.2); no immutable first code → attacker pehle apna khud ka verifier chalata hai.

L4.3 — Do open cores, ek decision

Recall Solution

Ecosystem & formal analysis: Ibex chhota hai aur formally analysed hai, bilkul wahi jo ek Root of Trust ko chahiye, aur yeh bade modern RISC-V toolchain aur verification community (FPGA & RTL Verification) ka faayda uthata hai.
Proven integration: Ibex already OpenTitan ka core hai, jo ek shipping open silicon RoT hai — tum uske secure-boot, key-storage aur crypto-accelerator surroundings inherit karte ho, unhe rebuild nahi karna padta. (OpenRISC RISC-V se pehle aaya hai aur ek fine general CPU hai, lekin RoT tooling Ibex/RISC-V ke around coalesce ho gayi hai.)

Level 5 — Mastery

Ek lamba problem jo is page ke har idea ko chain karta hai.

L5.1 — End-to-end attack analysis

Recall Solution

Move 1 — hash par fail. Stored measurement $m_{3} = H (I_{3})$ hai. Malicious image kuch aur hash karta hai, isliye $H (I_{3}^{'}) \neq = m_{3}$ aur integrity check kisi bhi signature step se pehle reject kar deta hai.

Move 2 — signature par fail. Ab recomputed hash (bhi-swapped) $m_{3}$ se match karta hai, isliye integrity pass ho jaati hai. Lekin signature $σ_{3}$ vendor ki private key se original $m_{3}$ par banaya gaya tha. Nayi $m_{3}$ ko $p k$ ke against verify karna fail hota hai, kyunki attacker private key ke bina valid signature produce nahi kar sakta (authenticity holds — yeh exactly L3.1 hai).

Move 3 — infeasible. Ek collision malicious image ko same measurement share karne deti, isliye purana signature phir bhi verify karta. Lekin SHA-256 $256$ -bit hai, aur birthday bound se expected number of attempts hai $\approx 2^{256/2} = 2^{128} \approx 3.4 \times 1 0^{38},$ jo computationally impossible hai. Isliye yeh darwaza band hai.

Move 4 — fuses par fail. Public key one-time-programmable fuses mein rehti hai jo physically rewrite nahi ki ja sakti (L3.2). Attacker apni khud ki key install nahi kar sakta, isliye unke self-signed images real anchor ke against kabhi verify nahi hote.

Conclusion: har raasta block hai — design mein koi weak layer nahi hai. Integrity (hash), authenticity (signature), aur ek immutable anchor (fuses) milke complete coverage dete hain. Yahi wajah hai ki secure boot kaam karta hai, aur isliye design ka open hona attacker ki koi madad nahi karta — yahan kuch bhi circuit ki secrecy par depend nahi karta.

Recall Quick self-check

OpenRISC code size kaun sa formula deta hai? ::: $Bytes = 4 N$ (fixed 32-bit instructions). $n$ -bit hash ke liye collision effort kaun sa formula deta hai? ::: $\approx 2^{n /2}$ (birthday bound). Poori chain of trust ko anchor karne wala ek physical fact kya hai? ::: Public key jo one-time-programmable fuses mein burn hoti hai.