Secure Initialization of TEEs - Riscure

Secure Initialization of TEEs - Riscure

Secure Initialization of TEEs when secure boot falls short… Cristofaro Mune (@pulsoid) Eloi Sanfelix (@esanfelix) EuskalHack 2017 Who? • Cristofar...

2MB Sizes 0 Downloads 0 Views

Recommend Documents

Vcache initialization error
Jul 23, 2017 - This article presents a timeline of events in the history of x86 DOS operating systems from 1973 to 2016.

TrustZone TEEs
Guarantees confidentiality of data processed within the environment. ○ Ensures the integrity ... all Nexus devices. Wh

River Tees Re-Discovered: Historic Environment - Tees Archaeology
Stone farmhouses, Piercebridge, Darlington and brick townhouse, Yarm, Stockton on Tees. Fig 18. Stockton and Darlington

tees valley economic assessment - Tees Valley Combined Authority
Bishopton, Dalton Piercy, Elton, Elwick, Hart Village, Hilton, Low Coniscliffe & .... £4.1bn – results from Tees Vall

teesside - Tees Archaeology
This is very similar to the layout of Danby Castle on the North York. Moors and Castle Bolton in Wensleydale. During the

Tees Valley Guide.pdf
Nearby is the Wingfield Castle, a restored paddle steamer and the ... Cathedral and Castle World .... The awe-inspiring

The Mesolithic - Tees Archaeology
Evidence for human life in the region before the Mesolithic is rare with only a handful of known stray finds ..... remov

Middlesbrough - Connect Tees Valley
A Grade 2 listed Victorian park covering 30 hectares. It is situated in the centre of the town just off Linthorpe. Road.

Tees Valley - Stockton Council
Dec 11, 2012 - and/or there is a low or medium risk of surface water ... SuDS limited by low permeability of ...... Low

TEES FINANCIAL CLIENT AGREEMENT Client Name - Tees Law
Apr 17, 2017 - The client agreement set out on the following pages gives details of the ... by visiting the FCA's web si

Secure Initialization of TEEs when secure boot falls short…

Cristofaro Mune (@pulsoid) Eloi Sanfelix (@esanfelix)

EuskalHack 2017

Who? • Cristofaro Mune − Embedded Security Consultant (Independent) − Keywords: TEEs, IoT, Embedded SW & HW, Fault Injection − Previous work: WBC, IoT, Embedded Exploitation, Mobile

• Eloi Sanfelix − Principal Security Analyst @Riscure − Keywords: Software security, TEE, RE, Exploiting, SCA/FI, CTF − Previous work: WBC, DRM, PayTV, Smart Cards

What and why… • TEEs Increasingly relevant in security solutions

…Basically everywhere • Research: • Interesting but limited in amount and scope

• Lack of a generic TEE security modeling • Components and Mechanisms • Attack surfaces • Attack vectors

TEEs: Fundamentals

Trusted Execution Environment (TEE) • Aimed at providing a secure environment for execution of security critical tasks: − Payment applications − DRM applications − …

• Separated from Rich execution environment (REE) − Non-secure, untrusted environment

• Support for Trusted Application (TAs): − Separated from each other − Typically implementing one single use case

System overview 1 3

2

source: globalplatform.org

TEE Critical items 1. TEE separations: 1. Separation from the Rich Execution Environment (REE) 2. Separation between TAs and the TEE OS 3. Separation between TAs

We focus on this… …but concepts also apply to these.

Strong cooperation between HW & SW

HW & SW roles

Hardware protecting

Software Software protecting

secrets

A TEE reference frame (runtime) H/W Platform 1 Execution

Memory

I/O

Inter-process (MMU)

HW primitives for separations TEE

REE

TEE Trusted Code Base (TCB): Can remove any protection

2 TEE OS

SDK

Drivers

3

6 TA 5

System TAs

4

ARM TrustZone

Example SoC: CPU

CPU Security State

NS=1

NS=0

Security State propagation ARM TZ core AxPROT[1] indicates if transaction Secure or Non-Secure

AMBA AXI3 bus

DDR

Flash

...

GPU

How is AxPROT[1] determined? • All AXI slaves are memory mapped − Including DDR, HW registers, etc. − Page Table Entries include an NS-bit

• AxPROT[1] depends on CPU and PTE NS bits

CPU NS 0 0 1

PTE NS AxPROT[1] 0 0 1 1 x 1

Example SoC: protection enforcement

Example: Protecting DDR memory

Example: Protecting peripherals

What about other slaves? • AXI slaves in charge of enforcing transaction security

• Can be done with: − Controllers (TZASC, TZPC, etc) − Hardcoded logic in bus matrix

• Controllers MUST be configured by SW

Secure Boot

Why Secure Boot?

BL1.1 BL1.2

Generic Embedded System

BL1.2





CPU

FLASH

DDR BL1.1 SRAM

ROM

OTP

STACK

Debug

− Integrity and confidentiality of flash contents not assured • TEE security is not established!

− Secure Boot provides this assurance

Typical Secure Boot implementation

Internal ROM RSA key Bootloader 1 (BL1) signature

… − Assures integrity (and confidentiality) of flash contents

− Root of trust composed of immutable code and data

SB vulnerability: Samsung Galaxy S4

aboot Header Kernel

Generic Embedded System

CPU

… FLASH aboot SRAM

ROM

Header Kernel

… DDR OTP

STACK

Debug

1. aboot copies header, then kernel 2. Signature is verified and kernel booted if OK. Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot

Any problems?

Untrusted  Arbitrary memory corruption

Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot

So what?

aboot Header Kernel

Generic Embedded System

Header

CPU

… FLASH

DDR Kernel aboot SRAM

ROM

OTP

STACK

Debug

− aboot smashes its own code with attacker-supplied code!

− Alternatively, attacker could target return address on stack Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot

SB vulnerability: AMLogic S905 SoC

Untrusted data used to determine whether signature check is enabled!

Source: http://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html

Beyond Secure Boot • Secure Boot makes sure code is authentic − You still need to set up the REE and TEE!

• In particular: − Initialize separations (TZASC, TZPC, … ) − Load TEE OS into Secure World − Initialize other SoC components

The TEE needs to be securely initialized before running any REE code!

“Time”:

TEE initialization

TEE initialization • TEE initialization is based on Secure Boot.

• TEE initialization must also protect, load, verify, initialize and configure the TEE. • Then demote to REE.

A TEE reference frame (full) 7

Root of Trust

H/W Platform 1 Execution

Memory

I/O

Inter-process (MMU)

Boot stages

8

HW primitives for separations TEE

REE

TEE Trusted Code Base (TCB): Can remove any protection

2 TEE OS

SDK

Drivers

3

6 TA 5

System TAs

4

Some definitions • Demotion point: − The point (in time & code) in a boot process, where ALL the privileges for configuring a TEE are given up − …and REE is started.

• Critical path(s): − The set of all the code paths that can be executed before the Demotion point − Parts of the TEE attack surface

How it works: Old Samsung phone Critical paths

Restricted

iROM

SECKEY

External

BL1

Signed/encrypted

BL2

Signed Signed

TZSW

PBL

Android

Signed

Load + Exec Exec Load

Demotion to REE

REE execution

Just “Secure Boot”? • The following must be executed before Demotion point

• For each TEE-related boot stage: − Identify WHERE to load the stage in memory − Protect memory from REE -

E.G. configure TZASC

− Load and Verify. − Run any stage initialization code

• Configure (…more to come…) − Other IPs − Other Protection Controllers

ARM Trusted Firmware • Reference implementation for trusted TEE initialization − ARMv8-A architecture − ATF v1.3 now released -

Security improvements over v1.2

• Customizations needed: − Highly dependent on memory layout (and design) − Examples: -

Configuration of TZASC and TZPC 

-

…or equivalent controllers

Initialization routines for BL31 and BL32

Example: ARM Trusted Firmware

Range checks • One of TEE security foundations − Is it Secure or Non-Secure Memory?

How difficult can it be?

Real world example

https://atredispartners.blogspot.com.mt/2014/08/here-be-dragons-vulnerabilities-in.html

• TEE ranges can be dynamic (and scattered) − Hardcoded values may be difficult to handle

• Logical mistakes may happen….

Range checks not so easy… • Multiple memories: − Not everything is DDR

• Layout can be dynamic: − Example: Video Memory

• Proper check location and API design are fundamental • System-level consistency of view is needed for proper enforcement: − Across every SW runtime component − Across the whole SoC HW.

“Space” dimension:

Not just the ARM CPU

Remember?

Potential attack surface • SoC much more than the ARM CPU • DMA engines − Crypto accelerators − PCI/PCIe devices

• Other processing engines − Audio/Video CPUs − Modem and WiFi controllers − Power management MCUs

Any IP with access to the bus MUST be considered!

Buses, masters and slaves • Most masters are also slaves − DMA transactions configured through the bus − Auxiliary CPUs expose APIs through the bus − …

• Need to take care of configuration − Secure bus masters should not be driven by non-secure processing engines − Firmware running on secure bus masters should be authenticated and secured!

Example: HW crypto engine

REE Apps

Encrypted content

REE OS

TAs TEE OS

Non-secure

Secure

REE Code/Data

HW AES Engine

“Decrypt from A to B”

DDR TEE Code/Data Secure DDR Decrypted content

What if… ?

REE Apps

REE OS

TAs TEE OS

Non-secure

Secure

“Decrypt from A to B” HW AES Engine

Encrypted content

REE Code/Data DDR TEE Code/Data Secure DDR

Securing peripherals • Some use cases might require isolating peripherals − Secure display to show mobile payment data − Secure touch sensor for PIN entry − Secure fingerprint sensor

• But some peripherals need to be available to both worlds  Runtime configuration required

State transitions must be carefully considered

“Time and Space”:

TEE Warm Boot

Warm Boot • Simply put: Boot after “Suspend-To-RAM” − Typically requested from REE

• Only some parts of the SoC are powered down: − DDR in self-refresh mode − Some limited parts always-on for restore

• Restore/reuse saved execution contexts − E.g: Entry points

What if… • Contexts are not fully stored in TEE memory?

• Protection controllers are shutdown as well? • Contexts are stored in non-DDR memory? − E.G. some on-chip SRAM

• Remaining execution cores are non-secure? − Do they have access to memory storing contexts?

Conclusion

Conclusion • TEE security can be complex: − Full HW & SW cooperation continuously required

• TEE initialization is critical

• HW can also be an attacker… • More accurate TEE security model needed: − Properly frame attacks, discussions and design choices

• Holistic view required

TEE is an environment… …not “just” a feature.

Thank you!! Cristofaro Mune (@pulsoid) [email protected]

Eloi Sanfelix (@esanfelix) [email protected]