Building Trusted Path on Untrusted Device Drivers for Mobile Devices Wenhao Li, Mingyang Ma, Jinchen...

Building Trusted Path on Untrusted Device Drivers

for Mobile Devices

Wenhao Li, Mingyang Ma, Jinchen Han, Yubin Xia, Bingyu Zang, Cheng-Kang Chu,

Tieyan Li

SJTU, Fudan and Huawei Technologies.

Motivation

• The population of mobile users grows dramatically

• So is the malware!

Key and Screen Logger Attack

• Key and screen loggers are not rare– Especially when devices are rooted or jailed

break – With root privilege, existing solutions could be

easily bypassed

Device Drivers are vulnerable!• Among these vulnerabilities, many

are due to device drivers

• Device drivers should not be trusted!

The Lack of Trusted Path Problem

• User Input– Key logger: steal user’s

password

• Screen Output– Screen logger: steal user’s credit

No and tamper with data (i.e. change $1,000 to $1)

• The key cause is the lack of a trusted path between– users and their devices– devices and Internet services

Credit No: 3412…343

Pay: $1,000

Password:

Goal of TrustUI

• Provides a trusted path between services and end users– from user input to screen output– from mobile device to cloud services

• Properties TrustUI should have– deployable to existing mobile devices– TCB should be minimal

OUTLINE

• Motivation of TrustUI

• Background and Design Alternatives

• Design and Implementation

• Evaluation

• Conclusion

ARM TrustZone Background

• Widely deployed in mobile devices– First Introduced in ARMv6, 2002– However, few devices utilize this technology

• Technology Detail– Split CPU Mode Execution– Memory and Peripheral Protection– Interrupt Isolation

Split CPU Mode Execution

• Two separated worlds: normal and secure world– secure world can access all states of normal

world but not vice-versa

• A new privileged mode: secure monitor mode– used to switch two worlds– handle security violation

Memory and Peripheral Protection

• Memory region and peripheral could be assigned to secure world accessible only, or both

• DMA protection– memory-to-peripheral DMA is world sensitive,

normal world DMA could not access secure memory

• Interrupt isolation– Normal world, secure world and monitor mode

have their own separated exception vector table– An interrupt can be configured as secure or non-

secure

Threat Model

• In-scope: software-based attacks

• Out-of-scope: physical hardware attacks

• Code running in secure world and monitor mode is trusted while others are untrusted

An Alternative Approach

• Runs rich functionality in parallel with a closed-box secure OS– Only some necessary device drivers and core logics

in secure world

• Limitations– Vendors may refuse to provide device drivers

source code– Device drivers are vulnerable to attacks

OUTLINE

• Motivation of TrustUI

• Background and Design Alternatives

• Design and Implementation

• Evaluation

• Conclusion

TrustUI Design

• A security-oriented split driver model– Reuse existing device drivers without trusting

them

TrustUI Design: Secure Display

Display Driver

Display Backend

Proxy Proxy

Display Device

Display Frontend

Display Lib

Secure Application

LED Indicator

Untrusted Rich OS Secure Kernel

Hardware

Software

Normal World Secure World

Frame Buffer

Unsecure Memory

Secure Memory

Memory

TrustUI Design: Secure Input

Touch Driver

Touch Backend

Proxy Proxy

Display Device

Input Frontend

UI Element Randomization

Secure Application

LED Indicator

Untrusted Rich OS Secure Kernel

Hardware

Software

Normal World Secure World

Frame Buffer

Unsecure Memory

Secure Memory

Memory

Touch Screen

TrustUI Design: Network Delegation

NIC Driver

Network Backend

Proxy Proxy

Network Frontend

SSL Library

Secure Application

Untrusted Rich OS Secure Kernel

Hardware

Software

Normal World Secure World

Unsecure Memory

Secure Memory

Memory

NIC Device

Security Challenges of TrustUI

Security Property Attack Solution

Code Integrity Code Tampering Secure Booting

Availability Denial-of-Service Detect by User

Input Privacy Touch Logger Input Randomization

Display Integrity Frame Buffer Overlay Display Randomization

Frame Buffer Overlay Attack

• Modern display device may have more than one window (frame buffer)

• Screen Hijacking Attack– A malicious display driver can pass a pointer of

frame buffer with low priority to the secure world, and operate on a higher layer frame buffer

Dealing with FB Overlay: LED & color randomization

• Two display layers in secure display– same color as LED and periodically change them– foreground font element: same color as foreground

layer– foreground bitmap element: foreground layer color

rendered on the edge and a watermark in random position

Secure Input: UI Randomization

• Soft Keyboard Randomization– information leakage: input length, touch position

and interval – touch position: regenerate the keyboard layout

after entering a character by adding an offset for each key

– input length and touch interval: generate a random pop-up button on the screen within the keyboard area for the user to click

• Other UI elements– Up to the trusted application developer to decide

TrustUI Implementation

• Implemented in Samsung Exynos 4412 development board– with ARM Cortex-A9 processor

• Run Android Ice Cream Sandwich in normal world– Linux kernel version 3.0.2.

• Source Code has been merged into T6– T6: a TrustZone based trusted kernel for mobile

OUTLINE

• Motivation of TrustUI

• Background and Design Alternatives

• Design and Implementation

• Evaluation

• Conclusion

Security Evaluation

• (left)Touch-logger analysis: touch position and length– (a)(b)(c) got by entering password ‘00000000’– (d) (e) by entering ‘5cfc912f’ and ‘12345678’– (f) by ‘f6b0736c3b’

• (right)Touch-logger analysis: touch interval

Security Evaluation

• Screen-capture attack– method: read device file in /dev/graphics/fb0

and some overlay devices like video playback and camera preview with and without invoking lock_display().

– tool: screencap provided by AOSP– result: only get the out-of-date display

content that are before switching to secure world.

Reduce The Attack Surface• Small "open-box"

• Small TCB– about 10K SLOC

World API Name Description

Secure World API

start_secure app(appid,parameters)

start a secure application in secure world

send_input_data(x,y,z) send the touch input data to secure world

Normal World API

create_shared_buffer(p addr,size)

create a shared non-secure memory buffer

lock_display() disable modification to display controller and framebuffer in normal world

invoke_ns_func(function id,parameters,response)

invoke normal world functions

get_trustui_info() get the display information and input interrupt id from normal world

Conclusion

• TrustUI: a system aiming at providing trusted path for mobile devices– built with cooperative randomization of the

trust path and secure delegation of network interaction

• Enables secure interaction between end users and services based on ARM TrustZone with a small TCB– excluding commodity software stack as well as

drivers for user-interacting devices out of its TCB

Q&A

Source code of T6 available via:

http://www.liwenhaosuper.com/projects/t6

Thank You!