System Level Security Verification of RISC V Based SoCs
summary
RISC-V SoC used in the Hack@DAC contest contains concrete failures: AES key leakage via MMIO (key readable through register interface), a JTAG password stored unprotected plus a lock bit that is not driven on reset causing a 50% unlock on reset, DMA allowing user-mode to access system timers, and boot code stored in writable memory. Tortuga Logic’s Radix layers information-flow tracking into existing simulation tests, Radix information-flow tracing visualizes concrete paths and catches the AES leakage during pre-silicon verification; many bugs were still found by RTL inspection.
AI-written summary · about
chapters (11)
- 0:00Introduction to talk
- 0:42Why system level security matters
- 2:27Requirements for system security
- 5:59Hack@DAC competition insights
- 7:43Block level hardware bugs
- 8:46System integration and software issues
- 12:36Verification methodology gaps
- 14:02Tortuga Logic's Radix solution
- 15:29Detecting AES key leakage
- 17:37Boot code key mismanagement
- 19:22Conclusions and Q&A
related talks
47mA Security RISC? The State of Microarchitectural Attacks on RISC-V
32mSecSi Product Development
18mCPU Security in the Context of RISC-V
06mDemo: RISC-V Dual Lock-step Implementation for Safety and Security Applications
25mRISC-V Zkt: Portable Timing Attack Resistance (via Dynamic Taint Analys...
25mRISC-V System-level Certification from Verification Foundations
24mSecurity through Transparency: Tales from the RP2350 Hacking Challenge
13mUsing RISC V As a Security Processor For DARPA CHIPS And Commercial IoT