Hardware-assisted Security:So Close yet So Far

Ahmad-Reza Sadeghi, Ferdinand Brasser

Technische Universität Darmstadt &

Intel Collaborative Research Institute for Secure Computing

Collaborators

N. Asokan, Aalto University Finland

Luca Davi, Christopher Liebchen, TU Darmstadt, Germany

Per Larsen, Steven Crane, Andrei Homescu, UCI, USA

Gene Tsudik, Michael Franz, UCI, USA

Thorsten Holz, Bochum University, Germany

Yier Jin, Dean Sullivan, Orlando Arias, UCF, USA

Patrick Koeberl, Matthias Schunter, Intel Labs

And ARM, Gieseke & Devrient, IBM, Huawei, NXP

ConclusionFantastic

Sad

Total Disaster

Very Sad

Complicated?

Why Hardware-assisted Security?

Hardware

Software Stack

Operating System

App 1 App 2 App 4App 3

Peripherals CPU I/OHardware

SoftwareStack

Memory

Goal: Self-Contained Security

Operating System

App 1 App 2 App 4App 3

Hardware

SoftwareStack

Peripherals CPU I/OMemory

• Platform boot integrity

• Secure storage

• Device identification

• Isolated execution

• Device authentication capabilities

• Establishing Trusted Execution Environment

Historical Overview

Cambridge CAP

1970 1980 1990 2000 2010

Reference monitor

Protection rings

VAX/VMS

Java security architecture

Hardware-assisted secure boot

Trusted Platform Module (TPM)

Late launch/TXT

Computer securityMobile securitySmart card security

Mobile hardware security architectures

TI M-ShieldARM TrustZone

Mobile OS security architectures

Mobile Trusted Module (MTM)

Simple smart cards

Java Card platform

TPM 2.0

Intel SGX

GP TEE standards

On-board Credentials

PUFs

App 4

I/O

Dedicated Security Devices (Smartcards)

Operating System

App 1 App 2 App 4App 3

Hardware

SoftwareStack

Peripherals CPU Memory

Peripherals CPU I/OMemory

App 4

I/O

Integrated Security Devices

Operating System

App 1 App 2 App 3

TPMHardware

SoftwareStack

Peripherals CPU Memory

Operating System

App 4App 1 App 2 App 3

e.g., Code-reuse Attacks

IBM Integrity Measurement Architecture (IMA) [Sadeghi et al, ACMSTC 2006]

TPM-Based Trusted Computing

• Remote (binary) attestation is static• Does not reflect code’s behavior

• Property-based Attestation [Stüble et al, NSPW 2004]

• Does not detect runtime attacks• Control FLow Attestation [Davi et al, CCS 2016 & DAC 2017]

Measure software

state

Trust Anchor (e.g., TPM)

Challenge

Authentic Report

ProverVerifier

ARM TrustZone

Operating System

App 1 App 2 App 4App 3

Hardware

SoftwareStack

Peripherals CPU I/OMemory

Operating System

App 1 App 2 App 3

Secure World

Applet 1

Applet 2

Applet 3

Operating System

Trustlet1

Trustlet2

Trustlet3

Operating System

Android• Full-Disk Encryption (FDE)• Samsung KNOX

• Secure-I/O, Attestation• Real-time Kernel

Protection (TIMA)

iOS• Device Encryption• Touch ID, Apple Pay

DRM • Netflix• Spotify• Widevine

• Subsidy Lock• IMEI Protection

IMEI: International Mobile Equipment Identifier• Onboard credential [NOKIA]• Mobicore [G&D]

Attacks on TrustZone

Breaking Android Full Disc Encryption [laginimaineb from Project Zero, 2016]

Reflections on trusting TrustZone [Dan Rosenberg, BlackHat US, 2014]

Attacking your Trusted Core [Di Shen, BlackHat US, 2015]

Android Kernel

App

Normal World

Breaking Android Full Disk Encryption

Media-server

Secure World

QSEE Kernel

Message Handler

KeyMaster Trustlet

Hardware TZ Extension

[laginimaineb from Project Zero, 2016]

QSEE-COM

Driver RWXSection

QSEE-HMAC

// inject

.code 16

// get key buff

SUB R3,R3,#0x10

// copy to NW

MOV R2,#0x0

Loop:

LDR R0,[R3,R2]

STR R0,[R1,R2]

ADD R2,R2,#0x4

MOV R0,#0x30

SUB R0,R2,R0

BLT loop

// ret success

MOV R0,#0

BX LR

Media-server

Provides User Services (e.g., FDE)Compromise Media Server System App

Grants Direct Access to QSEE Kernel Driver

RWXSection

Hook dispatcher, redirect to shell-code

// inject

.code 16

// get key buff

SUB R3,R3,#0x10

// copy to NW

MOV R2,#0x0

Loop:

LDR R0,[R3,R2]

STR R0,[R1,R2]

ADD R2,R2,#0x4

MOV R0,#0x30

SUB R0,R2,R0

BLT loop

// ret success

MOV R0,#0

BX LR

QSEE: Qualcomm Secure Execution Environment

Intel Software Guard Extensions (SGX)

Operating System

App 1 App 2 App 4App 3

Hardware

SoftwareStack

Peripherals CPU I/OMemory

Enclave 4Enclave 3Enclave 2Enclave 1

Code-reuse Attacks

Side-Channel Attacks(not in SGX Adv. Model)

Runtime Attacks and Defenses

1997

2001

2005

2007

2008

2009

2010

2011/2012

2013

2014

ret2libcSolar Designer

Advanced ret2libcNergal

Borrowed Code Chunk ExploitationKrahmer

ROP on x86Shacham (CCS)

ROP on SPARCBuchanan et al (CCS)

ROP on Atmel AVRFrancillon et al (CCS)

ROP RootkitsHund et al (USENIX)

ROP on PowerPCFX Lindner (BlackHat)

ROP on ARM/iOSMiller et al (BlackHat)

ROP without ReturnsCheckoway et al (CCS)

Practical ROPZovi (RSA Conference)

Pwn2Own (iOS/IE)Iozzo et al / Nils

JIT-ROPSnow et al (IEEE S&P)

Blind ROPBittau et al (IEEE S&P)

Out-Of-ControlGöktas et al (IEEE S&P)

Stitching GadgetsDavi et al (USENIX)

ROP is DangerousCarlini et al (USENIX)

Flushing AttacksSchuster et al (RAID)

Real-World Exploits

SELECTED

Main Defenses against Code Reuse

1. Code Randomization

2. Control-Flow Integrity (CFI)

2002

2005

2006

2010

2011

2012

2013

Program ShepherdingKiriansky et al. (USENIX Sec.)

Control-Flow Integrity (CFI) Abadi et al. (CCS 2005)

Branch RegulationKayaalp et al (ISCA)

Mobile CFIDavi et al. (NDSS)

ROPeckerCheng et al. (NDSS)

Modular CFINiu et al. (PLDI)

RockJITNiu et al. (CCS)

SAFEDISPATCHJang et al. (NDSS)

Hardware CFIDavi et al. (DAC)

Forward-Edge CFITice et al. (USENIX Sec.)

SELECTED

XFIAbadi et al. (OSDI)

Architectural Support for CFIBudiu et al. (ASID)

Control-Flow RestrictorPewny et al (ACSAC)

kBouncerPappas et al. (USENIX Sec.)

bin-CFIZhang et al. (USENIX Sec.)

CCFIRZhang et al. (IEEE S&P)

CFI and Data SandboxingZeng et al (CCS)

Control-Flow LockingBletch et al. (ACSAC)

ROPdefenderDavi et al. (AsiaCCS)

2014

2015

Protecting VtablesBounov et al. (NDSS)

HAFIX++Sullivan et al. (DAC)

VtrustZhang et al. (NDSS)2016

HyperSafeWang et al. (IEEE S&P)

EMETMicrosoft

PathArmorVeen et al. (CCS)

CCFIMashtizadeh et al. (CCS)

HAFIXArias et al. (DAC)

Per-input CFINiu et al. (CCS)

Control-Flow GuardMicrosoft

CETIntel

CFI Defense Literature

HAFIX: Hardware-Assisted Flow Integrity ExtensionDesign Automation Conference (DAC 2015)

Orlando Arias, Lucas Davi, Matthias Hanreich, Yier Jin, Patrick Koeberl, Debayan Paul, Ahmad-Reza Sadeghi, Dean Sullivan

Why CFI Processor Support?

CFI Processor Support based on Instruction set architecture (ISA) extensions

Dedicated CFI instructions

Avoids offline training phase

Instant attack detection

CFI control state: Binding CFI data to CFI state and instructions

Strategy Without Tactics: Policy-Agnostic Hardware-Enhanced Control-Flow Integrity

Design Automation Conference (DAC 2016)Dean Sullivan, Orlando Arias, Lucas Davi, Per Larsen,

Ahmad-Reza Sadeghi, Yier Jin

HAFIX++

Objectives

Backward-Edge and Forward-Edge CFI

Stateful, CFI policy agnostic

No burden on developer No code annotations/changes

Security Hardware protectionOn-Chip Memory for CFI DataNo unintended sequences

High performance < 3% overhead

Enabling technology All applications can use CFI featuresSupport of Multitasking

Compatibility to legacy code CFI and non-CFI code on same platform

cfibr Issued at call site setup backward edge

cfiret Issue at return site check backward edge

cfilsr Issued at call site setup call target

cfiprj Issued at jump site setup jump target

cfichk Issued at call/jmp target check forward edge

Label State Stack (LSS)

Label State Register (LSR)

HAFIX++ ISA Extensions

• Backward edge• Shadow stack detects return-address manipulation

• Shadow stack protected, cannot be accessed by attacker

• New register ssp for the shadow stack

• Conventional move instructions cannot be used in shadow stack

• New instructions to operate on shadow stack

• Forward edge• New instruction for indirect call/jump targets: branchend

• Any indirect call/jump can target any valid indirect branch target

• Could be combined with fine-grained compiler-based CFI (LLVM CFI)

Control-flow Enforcement Technology [Intel 2016]

BE-Support

FE-Support

Shared library &

MultitaskingGranularity Overhead

XFIBudiu et al, ASID 2006

Coarse 3.75%

HAFIXDavi et al., DAC 2015 Coarse 2%

LandHerehttp://langalois.com

Coarse N/A

HCFIChristoulakis et al.,

CODASPY 2016

Fine 1%

Intel CETIntel Tech Review Coarse N/A

HAFIX++Sullivan et al., DAC 2016

Fine 1.75%

Architectural dependent optimizations

Hardware-Based Solutions

Leakage: Use-case SGX

Controlled-Channel Attack on SGX

Enclave 1 Enclave 2 App 1 App 2 App 3

CPU

OS

EPCRAM

EPC: Enclave Page Cache PT: Page Tables PF: Page-Fault

PTPT PF Handler

IRQ

[Xu et al., IEEE S&P’15]

Granularity: page 4K, good for big data structures

Cache Attacks on SGX

Enclave 1 Enclave 2 App 1 App 2 App 3

CPU

EPCRAM

EPC: Enclave Page Cache

Cache

ob

serv

e

uses

CPU caches shared between enclaves and untrusted software

enabling cache side-channel attacks

Cache Attacks on SGX, Cont.

Enclave 1 Enclave 2 App 1 App 2 App 3

CPU

EPCRAM

EPC: Enclave Page CacheSMT: Simultaneous Multithreading

Level 3

CPU CoreLevel 2

Level 1 Branch Pred.SMTSMT

OS[Lee et al., arXiv:1611.06952],

Branch shadowing

[Moghimi et al., arXiv:1703.06986]

[Götzfried et al., EuroSec’17]

[Schwarz et al., arXiv:1702.08719]

[Brasser et al., arXiv:1702.07521]

SGX Side-Channel Attacks Comparison

Attack Type

Observed Cache

Interrupting Victim

Cache Eviction Measurement

Attacker Code

AttackedVictim

Lee et al. Branch Shadowing

BTB / LBR

YesExecution

TimingOS

RSA & SVM classifier

Moghimi et al. Prime + Probe

L1(D) Yes Access timing OS AES

Götzfried et al. Prime + Probe

L1(D) No PCM OS AES

Brasser et al.Prime + Probe

L1(D) No PCM OSRSA &

Genome Sequencing

Schwarz et al. Prime + Probe

L3 NoCounting Thread

Enclave AES

Our Attack

SMTSMT

L1

OS

Pro

cess

1

Pro

cess

2

Vic

tim

Pro

cess

n

Att

acke

r

Pro

cess

m

Pro

cess

m

+1

SMTSMT

L1AP

IC

Core 0 Core n

HandlerHandler Handler Handler

PCM

Pro

be Prime

PMC: Performance Monitoring Counter (e.g., executed cycles, cache hit/misses, …)

Attack Use-Cases

• Extracting 2048-bit RSA decryption key

• Extracting genome sequences processed in an enclave

Current Countermeasures

• System level defenses • Prevent side-channels requiring frequent interruption of enclaves

• Randomization

• Application level defenses• Side-channel resilient programming (hide accessed memory location)

• Obfuscation techniques • ORAM, Flushing

• New Hardware Design • Sanctum, Bastille, cache partitioning, etc.

Conclusion

• Hardware-assisted security simply not benefiting users• Still target of attacks exploiting vulnerabilities of legacy systems

• Side channel effect is kind of more drastic than though

• Current add-on defenses not practical or effective

• Directions• New business models

• Automated use of Trusted Computing solutions

• Artificial Intelligence in Hardware

• New fast and dense memory technology