Hardware Support for Trustworthy Systems Ted Huffmire 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.

About Me Assistant Professor of CS at NPS Research Computer Architecture, Computer Security Fast and Secure Hardware-Oriented Security

Course Overview Lecture 1: Overview: Hardware-Oriented Security and Security Engineering Lecture 2: Reconfigurable Security Primitives Lecture 3: Apply Primitives to Memory Protection, Design Example Lecture 4: Forward-Looking Problems

Lecture 1 Overview Hardware-Oriented Security Security Engineering

Hardware-Oriented Security Security Engineering

What is Hardware Security? Many of the issues of hardware security are similar to traditional computer security Anything can be hacked, but the attacker has finite resources. Each security technique has tradeoffs.

What is Hardware Security? Foundry Trust Intellectual Property Operational Attacks Developmental Attacks System Assurance

What is Hardware Security? Interfaces Composition Metrics Education

Problems Global Supply Chain of Integrated Circuits System Assurance

Confronting Security at the Hardware Level Opportunities of the hardware level Challenges of the hardware level

A Brief Word About ‘Cyber’ Beware of propaganda Think critically

Security Engineering Hardware-Oriented Security Security Engineering

Security Engineering Defending against skilled attackers is hard Holistic view of entire system Use the scientific method Every security technique has tradeoffs

Security Engineering Assume the enemy will be in your networks Increase the risk and cost for the adversary

Security Engineering Do not rely on security through obscurity Principle of least privilege Minimize system complexity

Security Engineering Reference monitor concept Separation (of duties and system components)

Security Engineering Penetrate & patch vs. inherently trustworthy Platform diversity Checklists and hardening guides

Security Engineering Study past success Secure defaults Backups, recovery, and rollback

Security Engineering Important Considerations Approaches to Security Engineering

Rigorous Design Practices Configuration management of tools/IP Eliminate support for insecure legacy technology Default configuration disables unnecessary services

Rigorous Design Practices Only develop the features needed Debugging messages not in production code Error messages that don’t reveal information

Rigorous Design Practices Secure coding practices Use of formal security analysis and evaluation Covert channel analysis Side channel analysis

Rigorous Design Practices Protocol analysis Robust protocols and authentication schemes Is the implementation faithful to the spec? Manage complexity. Reference monitor concept.

Self-protection Do not expose critical security functions to attack from other circuitry. Examples

Layered Dependencies Security-critical circuitry must not depend on circuitry of lesser trustworthiness In trusted software stack, applications depend on OS libraries, which depend on secure kernel

Lecture 1 Reading Secure Design Reflections on Trusting Trust http://dl.acm.org/citation.cfm?id=358210 The Protection of Information in Computer Systems http://www.acsac.org/secshelf/papers/protection_information.pdf Design Principles for Security (NPS Technical Report) http://www.cisr.us/downloads/techpubs/nps_cs_05_010.pdf

Lecture 1 Reading Secure Design Design and verification of secure systems http://dl.acm.org/citation.cfm?id=806586 Shared Resource Matrix Methodology: An Approach to Identifying Storage and Timing Channels http://dl.acm.org/citation.cfm?id=357374 On the Buzzword ‘Security Policy’ http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=130789

Lecture 1 Reading Hardware-Oriented Security and Trust Trustworthy Hardware: Identifying and Classifying Hardware Trojans http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5604161 Security Engineering http://www.cl.cam.ac.uk/~rja14/book.html Micro-Architectural Cryptanalysis http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4288047 Physical Unclonable Functions for Device Authentication and Secret Key Generation http://dl.acm.org/citation.cfm?id=1278484

Lecture 1 Reading Physical Attacks Temperature Attacks http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4812164 Information Leakage from Optical Emanations http://dl.acm.org/citation.cfm?id=545189 Differential Power Analysis http://www.springerlink.com/content/kx35ub53vtrkh2nx/ Keyboard Acoustic Emanations http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1301311

Lecture 1 Reading trust-HUB.org http://trust-hub.org/ Introduction to Hardware Security and Trust http://springer.com/978-1-4419-8079-3 Towards Hardware-Intrinsic Security http://springer.com/978-3-642-14451-6

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 2 Overview Reconfigurable Security Reconfigurable hardware is widely used due to growing non-recurring engineering (NRE) cost for ASICs

Field Programmable Gate Arrays Design of high-performance systems ASIC chips have been used traditionally Need something in between CPU and ASIC

Field Programmable Gate Arrays Raises interesting security questions Set of security primitives Examples of FPGA systems

Reconfigurable Hardware FPGA Chip Reference Monitor Crypto Core CPU Core AES μP SDRAM (off-chip) DRAM In addition to snooping the memory bus and direct connection to AES core, need to worry about Pins too.

Tradeoffs Software vs. Hardware CPU ASIC FPGA General-Purpose Application-Specific Software vs. Hardware ASIC performance comes at a high NRE cost Design, Verification Fabrication, Packaging, Test Security

Motivation Ideal: Performance approaching ASIC, cost approaching CPU Problem: Embedded systems designers need security primitives Opportunities: Spatial mapping of apps to device Build primitives in reconfigurable hardware

Outline Motivation and Background Security Primitives for FPGAs Logical isolation Interconnect tracing Secure communication architecture Configuration scrubbing In order to understand my strategy for making FPGAs secure, I first need to explain some low-level details about FPGAs that I will exploit in my primitives as well as some details about providing protection in embedded systems

Motivation and Background Security Primitives for FPGAs Logical isolation Interconnect tracing Secure communication architecture Configuration scrubbing In order to understand my strategy for making FPGAs secure, I first need to explain some low-level details about FPGAs that I will exploit in my primitives as well as some details about providing protection in embedded systems

Protection on Embedded Systems Reconfigurable Protection DRAM app1 app2 app3 Reference Monitor Separation Kernels DRAM app1 app3 app2 kernel Separate Processors DRAM gate keeper app1 app3 app2 Physical Software Spatial Temporal

FPGA Systems CLBs are islands of logic in a sea of interconnect. SDRAM (off-chip) DRAM FPGA chip μP SRAM Block BRAM FPGA Fabric CLBs are islands of logic in a sea of interconnect.

FPGA Applications FPGA App1 Mem App2 I am going to show you how apps are mapped onto the fabric.

FPGA Fabric Switchbox CLB A B Out 0 0 0 0 1 0 1 0 0 1 1 1 0 0 0 0 1 0 1 0 0 1 1 1 The switchbox shown is inefficient. There is a science of routing architecture. Wilton switchboxes use fewer transistors while providing an optimal level of routing flexibility.

Mixed Trust Cores Multiple cores on one chip Cores are provided by third parties Sophisticated software tools developed by third parties Developing trusted tool chains is beyond the scope. Developing trusted cores is beyond the scope.

Mixed Trust Cores Entanglement

Mixed Trust Tool Chains There are many tools out there. Since most computer scientists are not experts at HDL design, tools are needed to translate algorithms into circuits. HDL design is tricky. Many proposals for tools for high-performance computing applications that run on hybrid CPU/FPGA systems in which FPGAs handle the most intensive tasks (10%-90% rule). How do we profile an FPGA application?

Logical Isolation Motivation Security Primitives for FPGAs Interconnect tracing Secure communication architecture Configuration scrubbing

Moats Goal: Physical isolation of cores Opportunity: Divide computation spatially Exploit spatial nature of FPGAs to provide isolation

Moats Reference Monitor CPU Core AES Crypto Core FPGA Chip SDRAM (off-chip) DRAM In addition to snooping the memory bus and direct connection to AES core, need to worry about Pins too.

Moats

Methodology Tradeoff between area and performance Use VPR to synthesize 20 largest MCNC benchmark circuits on different routing configurations

Effective Utilization 100% A Dead areas for moats (Depends on # Cores) B Inflation due to restricted routing (~10%) C Useful logic with no inflation (unrestricted routing) UEff=C/(A+B+C)

Moat Tradeoffs Moat Size = 6 Moat Size = 2 Moat Size = 1 Dead Space Useful Logic Moat Size = 6 Inflation Dead Space Inflation Useful Logic Moat Size = 2 Dead Space Inflation Useful Logic Moat Size = 1

Effective Utilization

Interconnect Tracing Motivation Security Primitives for FPGAs Logical isolation Interconnect tracing Secure communication architecture Configuration scrubbing Segue: Now that cores are isolated, we need to let them talk to each other.

Drawbridges Goal: Ensure that only specified communication is established between cores Opportunity: Spatial isolation Specify legal connections Statically verify these connections

Interconnect Tracing Reference Monitor CPU Core AES Crypto Core X FPGA Chip Reference Monitor Crypto Core CPU Core AES μP SDRAM (off-chip) DRAM X In addition to snooping the memory bus and direct connection to AES core, need to worry about Pins too.

Jbits Interface Jbits is a java software interface from Xilinx It provides abstract methods for Reading bitstreams Modifying bitstreams Creating bitstreams Allows us to obtain the information we need to trace the routes from the actual bitstream Explain the purpose what Jbits was designed for Partial reconfiguration Creation and modification of bitstreams Run time parameterizable cores Jroute Signal router How do we use it

How Route Tracer Works Initialization Parse Input file to get all modules, pins, and connections Obtain list of search pins for incoming and outgoing connections Trace all connections from input pins Trace all connections leaving modules Reverse Trace to ensure that there are no invalid connections entering the modules

Route Tracing Algorithm RouteTree trace(pin, module) { add pin to routeTree for all sinks of wire this pin is on { if sink is connected to pin if sink has already been search return if sink is in another module check if connection is valid add sink to list of searched pins trace(sink, module) } Explain that this is simplified version and that will talk more about how it actually works in the next slide Talk about termination because of sink already being searched Talk about termination at module boundary and why we can terminate there

Route Tracing SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB First talk about pins, and wires and segments Then talk about searching for sources and sinks then go through example SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB

Example Input file #C source destination width # denotes a comment C B25 MB1 1 C C36 MB1 1 C MB1 J30 1 C B25 MB2 1 C MB1 MB2 32 C MB2 MB1 32 C B25 MB3 1 C MB3 C9 1 C C8 MB3 1 C B25 MB4 1 C MB4 MB3 32 C MB3 MB4 32 # denotes a comment # first declare the device type #D device D XC2V6000 FF1517 #N moudules pins connections N 4 5 12 #M modulename xmin xmax # ymin ymax M MB1 11 35 57 80 M MB2 11 35 13 35 M MB3 54 78 57 80 M MB4 54 78 13 35 #P pinname in/out P B25 rst #Reset P C36 in #rs_232_rx_pin P J30 out #rs_232_tx_pin P C8 in #rs_232_rx2_pin P C9 out #rs_232_tx2_pin 1 .Device 2. number of modules connections and pins 3. Modules talk about what the coordinates are 4. Pins ( these are the I/0 pins used on the device) explain why rst has a special type of connection 5. Connections – can go module to module or pin to module and can have different widths

Output from Route Tracer . Found Valid connection:MB1 to MB2 CLB.S6BEG5[57][33] . [CLB.S6END5[51][33]] . . CLB.S6BEG5[51][33] . . . [CLB.S6END5[45][33]] . . . . CLB.S6BEG3[45][33] . . . . . [CLB.S6END3[39][33]] . . . . . . CLB.S2BEG3[39][33] . . . . . . . [CLB.S2END3[37][33]] . . . . . . . . CLB.S2BEG1[37][33] . . . . . . . . . [CLB.S2END_S1[34][33]] Found Valid connection:MB3 to MB4 CLB.OMUX0[58][58] . CLB.LV12[58][58] . . [CLB.LV18[28][58]] Found Valid connection:MB3 to C9 Design Successfully verified! Explain how route tree displaying can be turned off and on Explain how multiple connections from one source can happen and how they are only counted once Explain what happens if we have an invalid connection Talk about false positives

Partial Reconfiguration Route Tracing SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB Input Pin SM CLB SM CLB SM CLB SM CLB Output Pin SM CLB SM CLB SM CLB SM CLB Revisit the previous example Now lets say area in center is area that we are using for partial reconfiguration Then explain how we can store connection information for these connections This is our partially reconfigurable area SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB SM CLB

Moats 1.0 Example four-core design, moat size = 2

Moats 2.0 Subset of connections that must be traced

Secure Communication Architecture Motivation Security Primitives for FPGAs Logical isolation Interconnect tracing Secure communication architecture Configuration scrubbing Segue: Interconnect tracing addresses one way that cores communicate. Now we need to address another way that cores communicate: via a shared bus.

Secure Communication Architecture Goal: Secure communication between cores on shared bus Opportunity: Programmability of FPGAs Shared memory bus with time division access

Communication Architecture Mn Mn Arbiter BRAM Block . . .

Communication Architecture FPGA Chip Arbiter/Reference Monitor Crypto Core CPU Core AES μP SDRAM (off-chip) DRAM In addition to snooping the memory bus and direct connection to AES core, need to worry about Pins too.

Configuration Scrubbing Motivation Security Primitives for FPGAs Logical isolation Interconnect tracing Secure communication architecture Configuration scrubbing Segue: Now that we have isolation and controlled sharing primitives for cores that are static, we need to address the case where an FPGA can dynamically change its configuration.

Configuration Scrubbing Goal: Allow FPGA to change its configuration securely at run-time Opportunity: Use partial reconfiguration to properly erase prior core’s logic Use ICAP interface with an embedded core Bitstream decryption is prohibited when using partial reconfiguration

Scrubbing Example AES Crypto Core CPU Core CPU Core FPGA Chip SDRAM (off-chip) DRAM FPGA Chip CPU Core μP AES Crypto Core CPU Core μP

Lecture 2 Reading [Conference Version] Moats and Drawbridges: An Isolation Primitive for Reconfigurable Hardware Based Systems http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4223233 [Journal Version] Security Primitives for Reconfigurable Hardware-Based Systems http://dl.acm.org/citation.cfm?id=1754391

Lecture 2 Reading Reconfigurable Hardware Security Trusted Design in FPGAs http://dl.acm.org/citation.cfm?id=1278483 Security on FPGAs: State-of-the-Art Implementations and Attacks http://dl.acm.org/citation.cfm?id=1015052 Security for Volatile FPGAs http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-763.pdf

Lecture 2 Reading Reconfigurable Hardware Security Reconfigurable Computing: The Theory and Practice of FPGA-Based Computing http://store.elsevier.com/Reconfigurable-Computing/Scott-Hauck/isbn-9780123705228/ FPGA-Based Single Chip Cryptographic Solution http://mil-embedded.com/pdfs/NSA.Mar07.pdf http://www.xilinx.com/applications/security/index.htm Of Gates and Wires http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1303100

Lecture 2 Reading Handbook of FPGA Design Security http://springer.com/978-90-481-9156-7 Security Trends for FPGAs http://springer.com/978-94-007-1337-6

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 Now that we have isolation and controlled sharing primitives (that even support dynamic reconfiguration), we need to address the problem that cores need to talk to memory.

Memory Protection Apply primitives to memory protection Design Example Now that we have isolation and controlled sharing primitives (that even support dynamic reconfiguration), we need to address the problem that cores need to talk to memory.

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 Reference Monitor CPU Core Reference Monitor AES FPGA Chip Reference Monitor Reference Monitor Crypto Core CPU Core AES SDRAM (off-chip) DRAM X In addition to snooping the memory bus and direct connection to AES core, need to worry about Pins too. 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{Module1,rw,Range1} | {Module2,rw,Range2}; Policy(Access)*; Module1 Range1 Compartment 1 rw Module2 Range2 Compartment 2 rw

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 default: state=s1; //reject endcase init {M1,rw,R1}, {M2,rw,R2}

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 Tsu Tc

Synthesis Results

Possible Storage Channel init Step 2: Module1 changes the state by reading Range1 M1 M2 R1: r_ r_ R2: __ _w Step 1: Module2 can read Range1 {M1,r,R1} {M1,r,R1} R2: __ r_ M1 M2 R1: r_ __ 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 Now that we have isolation and controlled sharing primitives (that even support dynamic reconfiguration), we need to address the problem that cores need to talk to memory.

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

Shared External Memory System Overview ublaze 1 ublaze 1 Ref Monitor/Arbiter OPB Shared External Memory AES Core RS232 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} 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 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 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 4 Overview Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Trustworthy System Development Maximize Performance Minimize Cost Integrate security mechanisms

Example Systems Tagged Architectures Banking Smart Phones Embedded Systems Medical Devices Cars

Example Systems Discussion Points What is the threat model for an ATM? What is the threat model for a phone? What is the threat model for a pacemaker? What is the threat model for a car?

CAD Tools and IP Cords Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Trustworthy Tools and IP Stripped-down alternative design flow

Trustworthy Tools and IP Discussion Points: Can we trust the output of CAD tools? Can we trust the function of IP cores? How can we improve the CAD tools? How can we improve the IP cores? Is it feasible to develop from scratch? What about the software?

Security Usability Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Security Usability Design tools and techniques Technicians End users Manage Complexity 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);

Security Usability Discussion Points What do we expect from engineers? What do we expect from technicians? What do we expect from end users? How does that guide our efforts?

Hardware Trust of FPGA Fabric Forward-Looking Problems CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Hardware Trust Compromise of FPGA fabric FPGA Fabric SDRAM (off-chip) FPGA chip μP SRAM Block BRAM FPGA Fabric

Hardware Trust Discussion Points Is it viable to attack the fabric itself? Can a compromise be detected? Can we use a compromised FPGA fabric? What about radiation?

Languages Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Languages Enhancements to HDLs case({module_id,op,r1,r2}) endcase 9’b011110: //Module1,rw,Range1 state=s0; 9’b101101: //Module2,rw,Range2 default: state=s1; //reject endcase

Languages Discussion Points Are HDL security enhancements useful? What is the impact on the designer? Does it slow down the compiler? Does it slow down the design itself?

Configuration Management Forward-Looking Problems CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Configuration Management Tools IP Cores CPU Core μP AES Crypto Core

Configuration Management Discussion Points Is it useful to put CAD tools under CM? Is it useful to put IP cores under CM? What about licenses, patches, etc.?

Securing the Supply Chain Forward-Looking Problems CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Securing the Supply Chain Trusted Packaging, Assembly, and Delivery Testing

Securing the Supply Chain Discussion Points Is malicious packaging useful to attacker? Do we need trusted assembly facilities? What about bad capacitors and resistors? Can tests detect compromised parts? Are tests destructive? What is the cost? What tests need to be developed?

Physical Attacks on FPGAs Forward-Looking Problems CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Physical Attacks on FPGAs Design theft and bitstream decryption Analysis of failure modes Antenna attack

Physical Attacks on FPGAs Discussion Points How to protect bitstream from DPA? Does an FPGA fail secure? Is a configurable antenna useful? How to detect a short-circuit?

Dynamic Security Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Dynamic Security Partial reconfiguration

Dynamic Security Discussion Points Can you change the policy? How often does the policy change? Who changes the policy? Can you return to an earlier policy? Can you change to a less restrictive policy? Are policies static or generated dynamically? How many policies are there?

Split Manufacturing Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Split Manufacturing 2-D 3-D

Split Manufacturing Discussion Points Can we trust the result of split manufacturing? Could this approach harm security? What are the challenges of 2D? What are the challenges of 3D? Is it worth it? When is it worth it? Why not use trusted foundry always? Can we do everything from scratch?

Concluding Remarks Forward-Looking Problems Concluding Remarks CAD Tools and IP Cores Security Usability Hardware Trust of FPGA Fabric Languages Configuration Management Securing the Supply Chain Physical Attacks on FPGAs Dynamic Security Split Manufacturing Concluding Remarks

Concluding Remarks Security as High Priority in Design Practices Tools and Cores Attacks Protection Mechanisms Analysis of Cores, Tools, and Mechanisms Electronic System Level (ESL) Design Holistic View of Entire System & Lifecycle Abstractions to Manage Complexity Multiple Complementary Techniques Multi-Core Systems

Lecture 4 Reading Tagged Architectures Secure Program Execution via Dynamic Information Flow Tracking http://portal.acm.org/citation.cfm?id=1024404 Complete Information Flow Tracking from the Gates Up http://dl.acm.org/citation.cfm?id=1508258 Crafting a Usable Microkernel, Processor, and I/O System with Strict and Provable Information Flow Security http://dl.acm.org/citation.cfm?id=2000087

Lecture 4 Reading Banking The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography http://simonsingh.net/books/the-code-book/ Why Cryptosystems Fail http://www.cl.cam.ac.uk/~rja14/Papers/wcf.pdf Chip and PIN is Broken http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf

Lecture 4 Reading Embedded Systems Security Security in Embedded Systems: Design Challenges http://dl.acm.org/citation.cfm?id=1015049 Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses http://www.secure-medicine.org/icd-study/icd-study.pdf Experimental Security Analysis of a Modern Automobile http://www.autosec.org/pubs/cars-oakland2010.pdf TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones http://www.usenix.org/event/osdi10/tech/full_papers/Enck.pdf

Lecture 4 Reading Cryptography and Security: From Theory to Applications http://springer.com/978-3-642-14451-6