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
Memory Protection
CPU Core
Reference
Monitor
Reference
Monitor
AES
AES
Crypto Core
X
CPU Core
X
SDRAM (off-chip)
FPGA Chip
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{Module1,rw,Range1} | {Module2,rw,Range2};
Policy(Access)*;
Compartment 1
Module1
rw
Range1
Compartment 2
Module2
rw
Range2
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
init
– endcase
0
{M1,rw,R1},
{M2,rw,R2}
Policy Compiler Design Flow
Policy Compiler Design Flow
Enforcement Module
ModuleID Op
(2)
• Parallel search
(rw)
Address
(0x8E7B018)
Enforcement Module
Parallel Search
Range
Range ID Match?
0000 1000 1110 0111 1011 0000 0000 1XXX
1
0
0000 1000 1110 0111 1011 0000 0001 10XX
2
1
...
...
N
0001 0101 1111 0000 0001 1010 1111 XXXX
Access Descriptor
0
{0,1,0,...,0}
Module ID Op Range ID Bit Vector
init
{M1,rw,R1},
{M1,r,R3},
{M2,rw,R2},
{M2,r,R3},
{M3,rw,R3}
1
{M3,z,R3}
{M1,w,R4}
DFA
Logic
0
{M1,rw,R1},
{M1,r,R3},
{M2,rw,R2},
{M3,rw,R3}
{Legal ,Illegal}
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
Tsu
Range
Tc
State
Synthesis Results
Circuit Area vs. Number of Ranges
Cycle Time vs. Number of Ranges
8
7
Cycle Time (ns)
2500
2000
1500
1000
500
6
5
4
3
2
1
0
0
100
200
300
400
500
600
0
700
0
100
200
Number of Ranges
45
40
35
30
25
20
15
10
5
0
0
300
400
Number of Ranges
Setup Time vs Number of Ranges
Setup Time (ns)
Number of Logic Cells
3000
100
200
300
400
Number of Ranges
500
600
700
500
600
700
Possible Storage Channel
init
Step 2: Module1 changes the
state by reading Range1
{M1,r,R1}
Step 3: Module2 can no longer
read Range1
M1 M2
R1: r_ r_
R2: __ _w
Step 1: Module2 can read
Range1
{M1,r,R1}
M1 M2
R1: r_ __
R2: __ r_
Step 4: Module1 changes the
state by reading 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
RS232
AES Core
Ethernet
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
• 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
5
8
16
16
0
0
0
0
ce537f5e
5a567cc9
966d9259
0336763e
6a118a87
4519e64e
9963798a
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 nonreconfigurable 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 FPGABased Embedded Systems
• http://dx.doi.org/10.1016/j.cose.2008.05.002