Hardware Support for Trustworthy Systems

Hardware Support for Trustworthy Systems Ted Huffmire ACACES 2012 Fiuggi, Italy

Disclaimer • The views presented in this course are those of the speaker and do not necessarily reflect the views of the United States Department of Defense.

Lecture 3 Overview • Apply primitives to memory protection • Design Example

Memory Protection • Apply primitives to memory protection • Design Example

Memory Protection • Goal: Allow cores to share memory securely • Opportunity: Leverage the benefits of hardware • A reconfigurable reference monitor enforces a policy that specifies the legal sharing of memory

DRAM DRAM Reference Monitor DRAM DRAM DRAM DRAM Reference Monitor CPU Core DRAM DRAM DRAM DRAM DRAM DRAM AES AES Crypto Core X CPU Core X SDRAM (off-chip) FPGA Chip Memory Protection

Memory Protection • Goal: Allow cores to share memory securely • Opportunity: Leverage the benefits of hardware • A reconfigurable reference monitor enforces a policy that specifies the legal sharing of memory

A Memory Protection Language • All modules on chip must obey a memory access policy • Memory protection policies are expressed in the language • Compiler translates the policy to a circuit

Formal Top Level Specification (FTLS) • A precise language of legal accesses • Subjects (Modules) • Access Rights • Objects (Memory Ranges) • Fixed (Stateless) Models • Transitional (Stateful) Models

Compartment 1 Compartment 2 Module1 Module2 rw rw Range1 Range2 Isolation Example • A fixed (stateless) model • Each core is restricted to a fixed range (or set of ranges) of memory • Each range can only be assigned to one core • Access{Module1,rw,Range1} | {Module2,rw,Range2}; • Policy(Access)*;

init {M1,rw,R1}, {M2,rw,R2} 0 Policy Compiler • 1. Policy FTLS: • Access{Module1,rw,Range1} | {Module2,rw,Range2}; • Policy(Access)*; • 2. Regular Expression: • ({Module1,rw,Range1} | {Module2,rw,Range2})* • 3. Minimized DFA: • 4. Verilog HDL: • case({module_id,op,r1,r2}) • 9’b011110: //Module1,rw,Range1 • state=s0; • 9’b101101: //Module2,rw,Range2 • state=s0; • default: • state=s1; //reject • endcase

Policy Compiler Design Flow Policy Compiler Design Flow

Enforcement Module • Parallel search

What we have done • Automated design flow from FTLS to synthesized circuit • Language has a well-defined grammar • Powerful enough to express a variety of policies that we have compiled and tested

Tsu Range Tc State Methodology • Constructed several isolation policies • Varied the number of ranges • Used Quartus to synthesize • Measured: • Area (Logic Cells) • Setup Time • Cycle Time

Synthesis Results

init M1 M2 R1: r_ r_ R2: __ _w {M1,r,R1} {M1,r,R1} M1 M2 R1: r_ __ R2: __ r_ Possible Storage Channel Step 2: Module1 changes the state by reading Range1 Step 1: Module2 can read Range1 Step 4: Module1 changes the state by reading Range1 Step 3: Module2 can no longer read Range1

A Higher Level Language • Input • High; • Module1TS; • Module2U; • Range1U; • Range2U; • Output • Trigger1{M1,w,R1}; • Trigger2{M1,w,R2}; • Access0{M1,r,R1} |{M1,r,R2}|{M2,rw,R1}|{M2,rw,R2}; • Access1{M1,rw,R1} |{M1,r,R2}|{M2,w,R1}|{M2,rw,R2}; • Access12{M1,rw,R1}|{M1,rw,R2}|{M2,w,R1}|{M2,w,R2}; • Access2{M1,r,R1}|{M1,rw,R2}|{M2,w,R1}|{M2,w,R2}; • Access21{M1,rw,R1}|{M1,rw,R2}|{M2,w,R1}|{M2,w,R2}; • Path1 (|Trigger1 Access1* ( |Trigger2 Access12*)); • Path2 (|Trigger2 Access2* ( |Trigger1 Access21*)); • PolicyAccess0* (|Path1|Path2);

Design Example • Apply primitives to memory protection • Design example

Goals of Design Example • Evaluate security primitives for reconfigurable hardware • Build a real system with multiple cores • Design a security policy for the system • Efficient memory system performance • Programmatic interface to system

System Overview ublaze 1 ublaze 1 Ref Monitor/Arbiter OPB Shared External Memory AES Core Ethernet RS232

Security Policy • Range0[0x41400000,0x4140ffff]; (Debug) • Range1[0x28000000,0x28000777]; (AES1) • Range2[0x28000800,0x28000fff]; (AES2) • Range3[0x24000000,0x24777777]; (DRAM1) • Range4[0x24800000,0x24ffffff]; (DRAM2) • Range5[0x40600000,0x4060ffff]; (RS-232) • Range6[0x40c00000,0x40c0ffff]; (Ethernet) • Range7[0x28000004,0x28000007]; (Ctrl_Word1) • Range8[0x28000008,0x2800000f]; (Ctrl_Word2) • Range9[0x28000000,0x28000003]; (Ctrl_WordAES)

Security Policy • Access0{M1,rw,R5}|{M2,rw,R6}|{M1,rw,R3} • |{M2,rw,R4}|{M1,rw,R0}|{M2,rw,R0}; • Access1Access0|{M1,rw,R1}|{M1,rw,R9}; • Access2Access0|{M2,rw,R1}|{M2,rw,R9}; • Trigger0{M1,w,R7}; • Trigger1{M1,w,R8}; • Trigger2{M2,w,R7}; • Trigger3{M2,w,R8}; • Expr1Access0|Trigger3Access2*Trigger4; • Expr2Access1|Trigger2Expr1*Trigger1; • Expr3Expr1*Trigger1Expr2*; • PolicyExpr1*|Expr1*Trigger3Access2* • |Expr3Trigger2Expr1*Trigger3Access2* • |Expr3Trigger2Expr1*|Expr3|;

Security Policy DFA

User Interface s 5 8 16 16 0 0 0 0 ce537f5e 5a567cc9 966d9259 0336763e 6a118a87 4519e64e 9963798a 503f1d35 • Currently using Hyperterminal to connect to AES core via serial connection • Tested using 128 bit key & data manually parsed into 32 bit lines and sent via hyperterminal.

User Interface • Progress • Implemented User Interface was implemented in C++. • SERIAL OR ETHERNET? [1-SERIAL][2-ETHERNET] • ENCRYPT OR DECRYPT? [1-ENCRYPT][2-DECRYPT] • INPUT FILENAME: • KEY FILENAME: • OUTPUT SENT TO OUTPUT.TXT

Conclusions • Fabric of computing is changing • FPGAs are growing in importance • Efficient security primitives are possible to build in reconfigurable hardware

Future Work • Multi-Core Security • Our methods can also be applied to the non-reconfigurable domain • Modern FPGAs have multiple CPUs on one chip • Reference monitor can be hard-wired

Lecture 3 Reading • [Conference Version] Policy-Driven Memory Protection for Reconfigurable Hardware • http://dl.acm.org/citation.cfm?id=2163301 • [Journal Version] Managing Security in FPGA-Based Embedded Systems • http://dx.doi.org/10.1016/j.cose.2008.05.002

Hardware Support for Trustworthy Systems