Hardware Support for Trustworthy Systems

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.

Foundry Trust Intellectual Property Operational Attacks Developmental Attacks System Assurance

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

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

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

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
The Protection of Information in Computer Systems Design Principles for Security (NPS Technical Report)

Lecture 1 Reading Secure Design
Design and verification of secure systems Shared Resource Matrix Methodology: An Approach to Identifying Storage and Timing Channels On the Buzzword ‘Security Policy’

Lecture 1 Reading Hardware-Oriented Security and Trust
Trustworthy Hardware: Identifying and Classifying Hardware Trojans Security Engineering Micro-Architectural Cryptanalysis Physical Unclonable Functions for Device Authentication and Secret Key Generation

Lecture 1 Reading Physical Attacks Temperature Attacks
Information Leakage from Optical Emanations Differential Power Analysis Keyboard Acoustic Emanations

Lecture 1 Reading trust-HUB.org
Introduction to Hardware Security and Trust Towards Hardware-Intrinsic Security

Ted Huffmire ACACES 2012 Fiuggi, Italy

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

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 #M modulename xmin xmax # ymin ymax M MB M MB M MB M MB #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 [Journal Version] Security Primitives for Reconfigurable Hardware-Based Systems

Lecture 2 Reading Reconfigurable Hardware Security
Trusted Design in FPGAs Security on FPGAs: State-of-the-Art Implementations and Attacks Security for Volatile FPGAs

Lecture 2 Reading Reconfigurable Hardware Security
Reconfigurable Computing: The Theory and Practice of FPGA-Based Computing FPGA-Based Single Chip Cryptographic Solution Of Gates and Wires

Lecture 2 Reading Handbook of FPGA Design Security
Security Trends for FPGAs

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[0x ,0x ]; (AES1) Range2[0x ,0x28000fff]; (AES2) Range3[0x ,0x ]; (DRAM1) Range4[0x ,0x24ffffff]; (DRAM2) Range5[0x ,0x4060ffff]; (RS-232) Range6[0x40c00000,0x40c0ffff]; (Ethernet) Range7[0x ,0x ]; (Ctrl_Word1) Range8[0x ,0x f]; (Ctrl_Word2) Range9[0x ,0x ]; (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 e 6a118a87 4519e64e a 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 [Journal Version] Managing Security in FPGA-Based Embedded Systems

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

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

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

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

Tools IP Cores CPU Core μP AES Crypto Core

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

Trusted Packaging, Assembly, and Delivery Testing

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

Design theft and bitstream decryption Analysis of failure modes Antenna attack

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

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

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

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 Complete Information Flow Tracking from the Gates Up Crafting a Usable Microkernel, Processor, and I/O System with Strict and Provable Information Flow Security

Lecture 4 Reading Banking
The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography Why Cryptosystems Fail Chip and PIN is Broken

Lecture 4 Reading Embedded Systems Security
Security in Embedded Systems: Design Challenges Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses Experimental Security Analysis of a Modern Automobile TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones

Lecture 4 Reading Cryptography and Security: From Theory to Applications

Hardware Support for Trustworthy Systems

Similar presentations

Presentation on theme: "Hardware Support for Trustworthy Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Hardware Support for Trustworthy Systems

Similar presentations

Presentation on theme: "Hardware Support for Trustworthy Systems"— Presentation transcript:

Similar presentations

About project

Feedback