1 / 12

Implementing Memory Protection Primitives on Reconfigurable Hardware

Brett Brotherton Nick Callegari Ted Huffmire. Implementing Memory Protection Primitives on Reconfigurable Hardware. Project Goals. Evaluate security primitives for reconfigurable hardware Build a real system with multiple cores Design a security policy for the system

melissa-french
Download Presentation

Implementing Memory Protection Primitives on Reconfigurable Hardware

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. Brett Brotherton Nick Callegari Ted Huffmire Implementing Memory Protection Primitives on Reconfigurable Hardware

  2. Project Goals • 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

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

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

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

  6. Security Policy DFA

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

  8. Performance Results • One cycle latency increase for reference monitor • 25.75 vs 26.75 cycles • Area overhead very small • 116 LUTs (1% increase) • Clock speed increase • 65 to 73 MHz

  9. Impact of Moats • Moats tested for size 0, 1, 2, 6 • Best case: 0 and 6 • only a 4% decrease in clock frequency • Area overhead minimal

  10. 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. • GOAL • Incorporate a User Interface to allow the user to select a data file and key file and receive the corresponding result over multiple communication platforms to test multi-core design and Reference Monitor. s 5 8 16 16 0 0 0 0 ce537f5e 5a567cc9 966d9259 0336763e 6a118a87 4519e64e 9963798a 503f1d35

  11. User Interface • Progress • Implemented User Interface in C++ to allow more functionality and user friendliness. • SERIAL OR ETHERNET? [1-SERIAL][2-ETHERNET] • ENCRYPT OR DECRYPT? [1-ENCRYPT][2-DECRYPT] • INPUT FILENAME: • KEY FILENAME: • OUTPUT SENT TO OUTPUT.TXT

  12. Demo • Demo

More Related