1 Security of Embedded Systems… Matthias Schunter, Intel Labs, Ahmad Sadeghi, TU Darmstadt + Teams (F. Brasser, L. Davi, P. Koeberl , S. Schulz, et. al.) © 2015 Intel Corporation
1
Security of Embedded Systems… Matthias Schunter, Intel Labs, Ahmad Sadeghi, TU Darmstadt
+ Teams (F. Brasser, L. Davi, P. Koeberl , S. Schulz, et. al.)
© 2015 Intel Corporation
2
What is an Embedded System?
• “An embedded system is a computer system with a dedicated function within a larger mechanical or electrical system” (Wikipedia)
• Embedded Systems and Smart Grids: • EV Charging Stations
• Smart Meters
• RTU in Substations
• Automotive ECUs
• …
3
What is unique about Embedded Systems?
Impacts the Physical World
Highly Constrained Environment
Power, Performance, Die-Size, Development Cost, UI
Large & New Threat Surface
IoT system needs to be Robust, Survivable, Dependable
Significance of DOS attack
Physical Access to Devices makes Tampering easier
Heterogeneous Devices, Multiple Protocols make it harder to Secure
Crypto Algorithms need to outlive the long Industrial IoT Product Lifetimes
4
This Talk: Platform Security
Outline:
1. Intel and Embedded Systems
2. Introduction to Platform Security
3. Research:
• TrustLite: Lightweight Trusted Execution Environment
• Hafix: Control-flow Integrity Enforcement
7
E2E Compute Scalability: Flexible Intelligence
CORE
Edge Compute Network/Cloud Compute Gateway
Compute Capability
Compute Capability
IoT Solutions from “Things” to the Cloud
8
“Things” to Cloud Architecture Diagram
IVI Platform
Network Gateways
Big Data Analytics
Software Defined Infrastructure
Cloud HPC
Data Platform
Applications
Datacenter | Cloud
Compute Storage Network
Enterprise
API Service Creation, System Policy, Protection, and Management
Device Management
Security
Connectivity
Edge Analytics
IoT Gateway Industrial
Workload Consolidation Solution
Retail Responsive Store Solution
Things
Automotive IVI Solution
Network Security
Network Analytics
Network Applications
Network Function Virtualization
Compute Accelerators I/O
IoT Solutions from “Things” to the Cloud
10
About Information Security
Protect a given embedded system
Security as a process (detect and counter) not a state
100% Security is usually not feasible in practice
Protection against ranges of attacks (not all attacks)
Platform Security:
Capabilities of an system that improve the resiliency against attacks.
3
Remote Attack
Radio Attack
Local Attack
Many Types of Attacks!
Physical Attack
Distance
Outsider
Insider – User
Insider - Admin
Insider - Designer
Attacker Privileges Damage
Exploitability
Life-cycle Phase
...
12
Embedded Systems Security Life-cycles
Design and Validation
Production & Supply
Chain
In the field: Run & Update
Disposal, Re-use
Installation, Configuration,
Update
Boot
Running
Shutdown
Device Life-cycle Operations Life-cycle
13
Life cycle: 1. Start Secure
Starting a System
• Secure Boot: Only start with latest authorized software
• Secure Update: Install newer authorized software
• Secure Fuses: Tamper-proof configuration and versioning
Protection at Rest
• Secure Key-storage: Protecting keys against unauthorized use
• Secure Identities (EPID): Hardware protected device identities
• Disk Security: Protect disk against use by unauthorized system
• Device Recovery: Return a system into a known state
14
Life Cycle: 2. Run Secure
Operating System Support
• Memory Protection / Task Isolation: Contain errors and attacks
• Scalable Crypto: Support fast cryptography • AES-NI • Public Key Acceleration
• Real-time Guarantees
Hardware Security
• Trustworthy Execution: Mandatory HW-enforced Isolation (TyTAN, Intel SGX) • HW Root of Trust • Verifiable TCB
• Debug / Test security: Prevent unauthorized test and debug
• Fabric Security: Prevent harm from untrusted IP Blocks
15
Life cycle: 3. Stay Secure
Mitigation of Specific Run-time Attacks
• Buffer Overflows (Intel NX, ASLR, MPX)
• ROP Attacks (CFI; X-Only)
• Software Side Channel Mitigation
Resistance against Physical Attacks
• Tamper-resistance (e.g. For fuses)
• Side-channel Analysis (power supply)
• Fault Injection (inbound filtering; shielding)
Technology Deeper-dives 1. TyTAN: Hardware-protected TEE for Embedded Systems
2. Hafix: Hardware-based Control Flow Integrity
Trusted Execution Environment (TEE): – Hardware-Isolated Software Execution
– Well-defined Security Guarantees
SGX: Application gains ability to defend its own
secrets – Smallest attack surface (App + processor)
– Malware that subverts OS/VMM, BIOS, Drivers etc. cannot steal
app secrets
Proxy Proxy Proxy
Hardware
VMM
OS
App App App
Scalable TEE within big-core environment
Attack surface today Attack surface with Enclaves
X X
Intel SGX: Reducing the Software TCB
Attack Surface
17
What does an ultra-small device look
like?
16-bit, 32-bit Architectures
~200,000 Transistors
1mW/100MHz
Primary Constraints
Energy. Power x Execution time
(= Joule)
Cost = Silicon area
Security?
Usage Trend: Ultra-small Devices
18
Traditional Embedded Device:
- One Trust Domain - All SW „trusted“
- Any vulnerability compromises whole device
TyTAN Architecture:
- Hardware-protected Lightweight Trusted
Modules (LTM) for security-critical services
- SW failures are isolated
- Existing SW can continue to run (FreeRTOS)
Benefits:
- Dynamically reconfigurable, multi-stakeholder,
attestation, isolation, and real-time.
TyTAN Security Architecture
20
LTM
LTM
Untrusted
Sofware
TyTAN-enabled Hardware
• MPUs available in some microcontrollers (TI, Infineon, etc)
• Motivated by software reliability (fault containment, OS is trusted)
• Physical addressing is typical, MPU enforces region access control at
the level of read/write/exec
What (mode) on which page of memory (object)
• MMIO means MPU can restrict access to peripherals (including itself)
Traditional Memory Protection Units
21
Page
CPU
R
/
W
/
X
• Addition of code region controls makes MPU execution-
aware
• Code regions added as additional dimension in access
control logic
• HW can protect code and data depending on current task
(by whom (subject)?)
Execution-Aware Memory Protection
22
Page
CPU
R
/
W
/
X
If PC on
Page
PC
TyTAN Architecture
CPU EA-MPU PROM I/O
Real Time OS (untrusted)
Task A
Hardware Trusted Untrusted SW
Task B Task C
(Remote)
Attestation
Real-time Isolation
Dynamically
(Re-)Configurability
Multi-Stakeholder
TyTAN
Technology Deeper-dives 1. TyTAN: Hardware-protected TEE for Embedded Systems
2. Hafix: Hardware-based Control Flow Integrity
HAFIX: Hardware-Assisted Flow Integrity Extension, DAC 2015 Lucas Davi, Matthias Hanreich, Debayan Paul, Ahmad-Reza Sadeghi, TU Darmstadt Orlando Arias, Dean Sullivan, Yier Jin, UCF Patrick Koeberl, Intel Labs
26
Background: Buffer Overflows
MEMORY - RAM
DATA CODE
Initialize buffer[8] Get usr_input
COPY (buffer[8], *usr_input)
usr_input[0-3]: usr_input[4-7]:
usr_input[8-11]:
buffer[0-3]: buffer[4-7]:
POINTER:
…
00000000 00000000 00000000
00000000 00000000 8000ABCD
…
Executable binary
AAAAAAAA BBBBBBBB CCCCCCCC
AAAAAAAA BBBBBBBB CCCCCCCC
DATA Memory
readable and writeable
CODE Memory
readable and executable
Mitigation #1: Data Execution Prevention (DEP)
Prevent execution from a writeable memory (data) area
A
C B
D
Memory Access
Violation
Code Injection vs. Code Reuse Attacks
Code Injection – Adding a new node to the CFG
Adversary can execute arbitrary malicious code open a remote console (classical shellcode)
exploit further vulnerabilities in the OS kernel to install a virus or a backdoor
Code Reuse – Adding a new path to the CFG
Adversary is limited to the code nodes that are available
in the CFG
Requires reverse-engineering and static analysis of the
code base of a program
Control-Flow Integrity (CFI) in Hardware
Motivation
Existing CFI schemes are either inefficient or insecure
Dedicated CFI instructions facilitate efficient control-flow checks
On-chip CFI memory to protect CFI data
Contributions
HAFIX: efficient and effective hardware-based CFI implementation for Intel Siskiyou Peak
Fine-grained backward-edge CFI
Restrict function returns to active call sites
Implementation
On Siskyou Peak and SPARC
HAFIX Overview
Application
Source Code CFI Compiler
HAFIX CFI
Checks
Runtime Enforcement
CFIBR label
CFIRET label
CFI Label State
HAFIX
Binary
Compile-Time
CFIJMP
label
Hafix: Instrumented Code Example
Program Code
Function A (0025)
Instruction 1 CFIBR 0025
CALL Function B CFIRET 0025 Instruction 2 CFIDEL 0025; RET
Function B (0099)
Instruction 3 CFIBR 0099
CFIDEL 0099; RET
Function C (0444)
CALL Function X CFIBR 0444
CFIRET 0444 CFIDEL 0444; RET
CFI Label
Memory 0025
0099
Activate Label 0025
Activate Label 0099
Deactivate Label 0099
Label 0444 not active
→ Stop execution
1
3
2
4
Label 0025 active
→ Continue execution
No CFIRET
→ Stop
execution
HAFIX: Hardware-assisted CFI
Mitigation of Run-time Attacks by enforcing of Control-flow Integrity (CFI)
33
A
B
D C
E F
Label_1
Label_2
Label_3
Label_4 Label_3
Label_3
Exit(B) == Label_3
Published: DAC 2014, 2015 (Best Paper)
Prototyped: Performance:
• Overhead in SW 50-100%
• HAFIX Overhead 1-3%
36 36
Mitigating Security / Protocol Attacks
Remember:
Weak ciphers / insecure protocols
Mitigations:
• Never design your own crypto scheme
• Avoid designing new protocols
• Avoid implementing security and crypto components
• Re-use well-established protocols
• Re-use well-validated libraries