Upload
rosaline-whitehead
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
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!