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

5

Background: Intel and IoT

6

State of the Art: Systems on a Chip

6

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

9

Embedded Systems Security An Introduction on Platform Security

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

Demonstrators

Xilinx Virtex-6 FPGA

Source: M. Miettinen, TU Darmstadt

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

Improvide Attack: Return-oriented Programming

n mm o r ien ted Pro g ra ing r u t Re

28

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%

Questions?

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

37 37

Mitigating Configuration Problems

Remember: Weak defaults

Mitigations:

• Ensure that system only works if the configuration is secure

• Disallow weak choice of parameters

• No insecure default configuration

• No default / hardcoded keys or passwords