1 / 29

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.

mandel
Download Presentation

Hardware Support for Trustworthy Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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.

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

  4. Memory Protection • Apply primitives to memory protection • Design Example

  5. 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

  6. 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

  7. 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

  8. 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

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

  10. 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)*;

  11. 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

  12. Policy Compiler Design Flow Policy Compiler Design Flow

  13. Enforcement Module • Parallel search

  14. 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

  15. 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

  16. Synthesis Results

  17. 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

  18. 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);

  19. Design Example • Apply primitives to memory protection • Design example

  20. 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

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

  22. 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)

  23. 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|;

  24. Security Policy DFA

  25. 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.

  26. 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

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

  28. 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

  29. 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

More Related