Secure Design Methodology and The Tree of Trust

Transcription

1 Secure Design Methodology and The Tree of Trust Secure Embedded Systems Group ECE Department Virginia Tech The new Cool: Reverse Engineering... Microsoft Zune ( Under the Hood ( 2 1

2 ... in a complete curriculum. Learn hacking tricks.. ( and write papers on it ( 3 It's fun to break things.. but this presentation is about making things. How to handle 'secrets' in a design? Systematic side-channel-resistant design? Jumping forward, we will conclude: Secure design of systems needs a methodology. Ad-hoc security is doomed to fail. Perfect security does not exist (zero-power design doesn't exist either) Low-risk security does exist (low-power design does exist) 4 2

3 The starting point: Root of Trust A secret in a box by itself is useless (useless like a key without a matching door-lock) So a secure system contains at least two parts: distrusted environment secure system security policy authentication integrity confidentiality non-repudiation availability root-of-trust The part that always works as expected (or so you think!) 5 Design Step: Secure partitioning distrusted environment secure system distrusted subsystem secure subsystem 6 3

4 What drives secure partitioning? Minimize footprint of the root-of-trust Reduce the physical size of the root-of-trust Make the root-of-trust dynamic and short-lived Minimize the risk for side-channel-attacks A side-channel-attack is an interface into the root-of-trust around the security policy distrusted environment secure system side-channel-attack 7 Side Channel Attaxonomy Abstraction Level Attacker Proximity Countermeasure Example Math Off-line Algorithm Cryptanalysis Interpreter Connected Protected Partition Software Tampering [vanoorschot] Time Constant-time Cache [Osvik] Branch Prediction [Aciimez] Power Close-range Constant-power Masked-power DPA [Oswald/Mangard] + Higher-order EM Aluminium foil DPA [De Mulder] Implementation Physical Shielding Faults [Joye] Semi-Invasive [Skorobogatov] 8 4

5 Example 1: Cache timing attack MEMORY (20 cycle/acces) data in round keys CACHE (1 cycle/acces) sbox shift rows mix columns add roundkey data out (last round) Execution time dependency due to cache conflicts Software Solution: constant-time crypto (hard) 9 Example 1: Cache timing attack Timing Side-Channel Root-of-Trust Top-level Policy MEMORY (20 cycle/acces) data in round keys CACHE (1 cycle/acces) sbox shift rows mix columns (last round) add roundkey data out Execution time dependency due to cache conflicts Software Solution: constant-time crypto (hard) 10 5

6 Moving Sbox into Hardware SBOX regs (16 byte + 4 byte rkey) register file instruction fetch/ decode DCACHE sbox (AES32) ALU ICACHE 128 Hardware Sbox with ASIP interface CPU AES driver code RAM 11 Moving Sbox into Hardware SBOX regs (16 byte + 4 byte rkey) register file instruction fetch/ decode Cache miss rate per encryption sbox (AES32) 128 Hardware Sbox with ASIP interface Constant Execution Timing ALU CPU DCACHE ICACHE AES driver code RAM Software Sbox: 159 Dcache 138 Icache Hardware Sbox 0 Dcache 52 Icache StrongARM arch 1K I, 1K D cache, 16 byte/line direct Timing Side-channel fixed, but others remain

7 The Tree of Trust distrusted environment secure system Interpreter Side-channels non-critical software crypto software Timing Side-channels non-critical hardware/ software crypto hardware Power Side-channels non-critical circuit crypto circuit Physical Tamper-resistance 13 Where does it end? A hacker's view

8 Where does it end? A designer's view It doesn't - the tree of trust solves a turtle problem Deploy countermeasures systematically and analyze vulnerabilities at each level Software-only is insufficient (eg. Fairplay itunes) Hardware-only is insufficient (eg. Hardware keys in DVD, Xbox, HDCP) Working in our favor are: Moore's law Distribution of trust across the tree 15 The Tree of Trust distrusted environment secure system Deploy Countermeasures non-critical software non-critical hardware/ software crypto software crypto hardware Distributed, dynamic secrets non-critical circuit crypto circuit 16 8

9 Example #2: Chain-of-trust D/A & Amplify Side-channel: Probe and extract DRM-free high-quality music Download copy-righted multimedia into player Decode Decrypt (DRM) Flash Memory 17 Chain-of-trust for Video Messaging CF-card FPGA-unique encryption Display SW Trivium Key incorrect authentication incomplete chain-of-trust correct authentication complete chain-of-trust SAM key Trivium Stream Cipher VGA FPGA Program Memory [Simpson, Yu, Schaumont] 18 9

10 Chain-of-trust for Video Messaging FPGA-unique encryption CF-card Display SW Trivium Key SAM key Trivium Stream Cipher VGA FPGA Program Memory 19 Chain-of-trust for Video Messaging CF-card FPGA-unique encryption Display SW Trivium Key Compact Flash Data Baseline Config FPGA bitstream decryption (keys) SAM key Trivium Stream Cipher VGA FPGA Program Memory 20 10

11 Chain-of-trust for Video Messaging CF-card FPGA-unique encryption Display SW SAM key Trivium Key Trivium Stream Cipher VGA Compact Flash Data Secure SW & Data Download Baseline Config Configure VGA Display SAM decryption (PUF) FPGA Program Memory 21 Chain-of-trust for Video Messaging CF-card FPGA-unique encryption Display SW Trivium Key Compact Flash Data Baseline Config SAM key Trivium Stream Cipher VGA Secure SW & Data Download Configure VGA Display FPGA Program Memory Load Encrypted Display Video Trivium Stream Cipher (key) 22 11

12 Conclusions Secure design of systems needs a methodology. Ad-hoc security is doomed to fail. The Tree-of-Trust advocates stepwise partitioning of an system to achieve trustworthy operation Perfect security does not exist (zero-power design doesn't exist either) Low-risk security does exist (low-power design does exist) 23 12