Cycle Jerry Backer (1) , David Hly (2) and Ramesh Karri (1) - PowerPoint PPT Presentation

SoC Security Through the Life Cycle Jerry Backer (1) , David Hély (2) and Ramesh Karri (1) Polytechnic School of Engineering, New York University Université Grenoble Alpes, LCIS, Valence 1

Agenda  Introduction – SoC lifecycle – Test and Debug – Motivations  Focus on Debug Security – Debug and SoC – Debug Threats – A secure Debug mechanism  Leveraging Test and Debug features for System Security – Software threats – Test based countermeasure – Debug based countermeasure Conclusions and Perspectives  2

Syste System On Chip: T m On Chip: The he Stak Stakeholder eholders • System on Chip Architect • Specify the system • Components designers • Design on purpose components • System Integrator • Integrates the components • Fabrication Engineers • Manufacture the IC • Test the IC • Package the IC • Personalization Engineers • Configure the IC to the customers • OS Providers • 3 rd Party SW developers J. Backer, D. Hely and R. Karri 3

System System On Chi On Chip: T p: Test and est and Debug De bug All need dedicated access to the system in order to: • Test the SoC: Check Fabrication has been properly carried out • Debug the system (either hardware or software) Extra Hardware is added to offer to the SoC stakeholders extra observability/controllability of the internal system What about Security ? 4

 SoC Integration SoC Inte SoC Integration tion  SoC Integration Main 8051 DMAC CPU μCont Mem OTP AES Cont. 5

 SoC Integration SoC Inte SoC Integration tion  SoC Integration • Test/Debug Layer: IP cores configured with internal scan chains, wrapped for test, and connected via a test access mechanism (TAM) bus 3PIP Internal Logic 6

 SoC Integration SoC SoC Inte Integration tion  SoC Integration • Test/Debug Layer: IP cores configured with internal scan chains, wrapped for test, and connected via a test access mechanism (TAM) bus internal scan cells 7

 SoC Integration SoC Inte SoC Integration tion  SoC Integration • Test/Debug Layer: IP cores configured with internal scan chains, wrapped for test, and connected via a test access mechanism (TAM) bus WSO WBR WIR WBY WSC WBR WSI 8

 SoC Integration SoC Inte SoC Integration tion  SoC Integration • Test/Debug Layer: IP cores configured with internal scan chains, wrapped for test, and connected via a test access mechanism (TAM) bus WSO WBR • Wrapper Boundary Register (WBR) • Wrapper Serial Control (WSC) • Wrapper Serial Input (WSI) o selectWIR • Wrapper Serial Output (WSO o shiftWR • Wrapper Bypass Register (WBY) o captureWR • Wrapper Instruction Register (WIR) o updateWR WIR WBY WSC WBR WSI 9

 SoC Integration SoC Inte SoC Integration tion  SoC Integration • Test/Debug Layer: IP cores configured with internal scan chains, wrapped for test, and connected via a test access mechanism (TAM) bus Test Interface WSI WBR WSO WBR WSI WBR WSI WSO WSO OTP Main CPU 8051 μCont WSC WSC WSC TAM Bus 10

 SoC Integration  SoC Integration • Functional Layer: IP cores interconnected to meet functional specifications. Connections done via system bus, network-on-chip (NoC), sideband and coherence interfaces Main 8051 DMAC CPU μCont System bus Mem OTP AES Cont. 11

 Scan-based Side Channel Attack Test Lay est Layer er Attac Attack  Scan-based side-channel attack via test layer • Goal: Use internal scan cells to leak assets such as encryption keys • Case study: AES core [1][2] 1. Put SoC in normal mode 2. Use functional input ports to set AES plaintext 3. Run AES for one round 4. Switch SoC to test mode 5. Shift out round output via test output port (e.g. WSO port) 6. Analyze output* 7. Repeat until key is obtain * Differential analysis by tracing bit flips between plaintexts and ciphertexts  12

Motivations  Securing Test and Debug Mecanisms: – How to keep high observability and controllability for test and debug while guaranteeing a high level of security for the SoC assets?  Leveraging Test and Debug hardware for mission mode security: – How to reuse the unused test and debug hardware in mission mode to provide new security services? 13

Agenda  Introduction – SoC lifecycle – Test and Debug – Motivations  Focus on Debug Security – Debug and SoC – Debug Threats – A secure Debug mechanism  Leveraging Debug features for System Security – Software threats – Test based countermeasure – Debug based countermeasure Conclusions and Perspectives  14

Debug Instrumentation of Systems-on-Chip Who uses the SoC DfD infrastructure? 15

Debug Instrumentation of Systems-on-Chip System Fabric • SoC DfD infrastructure Signal filter (SF) o SF WiFi LCD Trace bus o DSP Debug bus o μP μP SF JTAG Joint test Access Group (JTAG) o SF SF SF SF Debug Bus Trace Bus 16

Debug Instrumentation of Systems-on-Chip Who uses the SoC DfD infrastructure? Post-silicon validation • SoC integrator/debugger • Original equipment manufacturer (OEM) • Outsourced Semiconductor test and assembly (OSAT) 17

Debug Instrumentation of Systems-on-Chip Who uses the SoC DfD infrastructure? Post-silicon In-field validation • SoC integrator • OEM • O.S. vendor • 3 rd party software developer 18

Debug Instrumentation of Systems-on-Chip Who uses the SoC DfD infrastructure? Post-silicon In-field retirement validation • SoC integrator • OEM 19

Debug Instrumentation of Systems-on-Chip Who uses the SoC DfD infrastructure? Post-silicon retirement In-field validation • SoC • SoC integrator • SoC integrator/debug • OEM integrator ger • OS vendor • OEM • OEM • 3 rd party software • OSAT developer Security implication: rogue debugger can use DfD to illegally leak SoC assets 20

Threat Model SoC Assets and Asset Owners SoC Assets • Cryptographic keys • Unique ID • Configuration/calibration data • Premium content • Proprietary firmware 21

Threat Model SoC Assets and Asset Owners SoC Assets Asset Owners • IP vendors • Cryptographic keys • SoC integrator • Unique ID • OEM • Configuration/calibration data • O.S. vendor • Premium content • 3 rd party software vendors • Proprietary firmware 22

Threat Model SoC Assets and Asset Owners SoC Assets Asset Owners • IP vendors • Cryptographic keys • SoC integrator • Unique ID • OEM • Configuration/calibration data • O.S. vendor • Premium content • 3 rd party software vendors • Proprietary firmware • SoC security requirement: specific assets are confidential to asset owners • DfD traces expose assets to all debuggers • Rogue debuggers leverage traces to leak SoC assets 23

Threat Model trace-based debug compressed traces firmware disassembly Extract asset decompress 010111011001… MOV r0, #10 MOV r0, #10 100100100110… MOV r1, #3 MOV r1, #3 SoC 0110110110110… ADD r0, r0, r1 ADD r0, r0, r1 1110110100100… Objective: Leak confidential SoC assets such as cryptographic keys and proprietary firmware 24

Threat Model trace-based debug compressed traces firmware disassembly Extract asset decompress 010111011001… MOV r0, #10 MOV r0, #10 100100100110… MOV r1, #3 MOV r1, #3 SoC 0110110110110… ADD r0, r0, r1 ADD r0, r0, r1 1110110100100… • Objective: Leak confidential SoC assets such as cryptographic keys and proprietary firmware • Assumptions 1. Only SoC integrator is trusted 2. Rogue debugger has insider knowledge of SoC design 25

Threat Model trace-based debug compressed traces firmware disassembly Extract asset decompress 010111011001… MOV r0, #10 MOV r0, #10 100100100110… MOV r1, #3 MOV r1, #3 SoC 0110110110110… ADD r0, r0, r1 ADD r0, r0, r1 1110110100100… • Objective: Leak confidential SoC assets such as cryptographic keys and proprietary firmware • Assumptions 1. Only SoC integrator is trusted 2. Rogue debugger has insider knowledge of SoC design 3. No collusion among rogue debuggers • Attack: Configure DfD for trace-base debugging o Decompress debug traces to reconstruct firmware/execution o flow Extract asset from decompressed traces o 26

Existing Security Mechanisms JTAG • Permanent JTAG Lock JTAG • JTAG authentication Encrypt(Trace, Key) • Trace encryption 0x00000000 – 0x000FFF : restricted • Restricted memory segments 0xFFFFE100 – 0xFFFFE4FF : restricted 27

Proposed Secure DfD Infrastructure • Requirements 1. Enforce confidentiality policy of SoC assets 2. Maintain debug observability 3. Limit area, power costs 1. Have no impact on debugging time 2. Have no impact on SoC horizontal design flow and supply chain 28

Proposed Secure DfD Infrastructure 0001 0001 0x0000 … 0100 JTAG = debugger 1000 ID DfD funnel debugger ID Asset filtering Secure asset tagging Debugger authentication • Secure asset tagging Tag size = # debuggers o • Debugger authentication Debugger ID = tag size o No confidentiality requirement for debugger ID o • Asset filtering 29