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

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

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

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  {Module 1,rw,Range 1 } | {Module 2,rw,Range 2 }; Policy  (Access)*; Module 1 Range 1 Compartment 1 rw Module 2 Range 2 Compartment 2 rw

Policy Compiler 1. Policy FTLS: – Access  {Module 1,rw,Range 1 } | {Module 2,rw,Range 2 }; – Policy  (Access)*; 2. Regular Expression: – ({Module 1,rw,Range 1 } | {Module 2,rw,Range 2 })* 3. Minimized DFA: 4. Verilog HDL: – case({module_id,op,r1,r2}) 9 ’ b011110: //Module 1,rw,Range 1 – state=s0; 9 ’ b101101: //Module 2,rw,Range 2 – state=s0; default: – state=s1; //reject – endcase init 0 {M 1,rw,R 1 }, {M 2,rw,R 2 }

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

Methodology Constructed several isolation policies – Varied the number of ranges Used Quartus to synthesize Measured: – Area (Logic Cells) – Setup Time – Cycle Time Range State T su TcTc

Synthesis Results

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

A Higher Level Language Input – High; – Module 1  TS; – Module 2  U; – Range 1  U; – Range 2  U; Output – Trigger 1  {M 1,w,R 1 }; – Trigger 2  {M 1,w,R 2 }; – Access 0  {M 1,r,R 1 } |{M 1,r,R 2 }|{M 2,rw,R 1 }|{M 2,rw,R 2 }; – Access 1  {M 1,rw,R 1 } |{M 1,r,R 2 }|{M 2,w,R 1 }|{M 2,rw,R 2 }; – Access 12  {M 1,rw,R 1 }|{M 1,rw,R 2 }|{M 2,w,R 1 }|{M 2,w,R 2 }; – Access 2  {M 1,r,R 1 }|{M 1,rw,R 2 }|{M 2,w,R 1 }|{M 2,w,R 2 }; – Access 21  {M 1,rw,R 1 }|{M 1,rw,R 2 }|{M 2,w,R 1 }|{M 2,w,R 2 }; – Path1  (  |Trigger 1 Access 1 * (  |Trigger 2 Access 12 *)); – Path2  (  |Trigger 2 Access 2 * (  |Trigger 1 Access 21 *)); – Policy  Access 0 * (  |Path 1 |Path 2 );

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 OPB ublaze 1 Ref Monitor/Arbiter Shared External Memory AES Core RS232 Ethernet

Security Policy Range 0  [0x ,0x4140ffff]; (Debug) Range 1  [0x ,0x ]; (AES1) Range 2  [0x ,0x28000fff]; (AES2) Range 3  [0x ,0x ]; (DRAM1) Range 4  [0x ,0x24ffffff]; (DRAM2) Range 5  [0x ,0x4060ffff]; (RS-232) Range 6  [0x40c00000,0x40c0ffff]; (Ethernet) Range 7  [0x ,0x ]; (Ctrl_Word 1 ) Range 8  [0x ,0x f]; (Ctrl_Word 2 ) Range 9  [0x ,0x ]; (Ctrl_Word AES )

Security Policy Access 0  {M 1,rw,R 5 }|{M 2,rw,R 6 }|{M 1,rw,R 3 } |{M 2,rw,R 4 }|{M 1,rw,R 0 }|{M 2,rw,R 0 }; Access 1  Access 0 |{M 1,rw,R 1 }|{M 1,rw,R 9 }; Access 2  Access 0 |{M 2,rw,R 1 }|{M 2,rw,R 9 }; Trigger 0  {M 1,w,R 7 }; Trigger 1  {M 1,w,R 8 }; Trigger 2  {M 2,w,R 7 }; Trigger 3  {M 2,w,R 8 }; Expr 1  Access 0 |Trigger 3 Access 2 *Trigger 4 ; Expr 2  Access 1 |Trigger 2 Expr 1 *Trigger 1 ; Expr 3  Expr 1 *Trigger 1 Expr 2 *; Policy  Expr 1 *|Expr 1 *Trigger 3 Access 2 * |Expr 3 Trigger 2 Expr 1 *Trigger 3 Access 2 * |Expr 3 Trigger 2 Expr 1 *|Expr 3 |  ;

Security Policy DFA

User Interface 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. s ce537f5e 5a567cc9 966d e 6a118a e64e a 503f1d35

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 [Journal Version] Managing Security in FPGA- Based Embedded Systems