Transcript Device Driver Safety Through a Reference Validation Mechanism

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
Credit No: 3412…343
Pay: $1,000
Password:
– 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
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
Normal World
Secure World
Secure Kernel
Untrusted Rich OS
Proxy
Proxy
Display Backend
Secure
Application
Display Lib
Display Frontend
Display Driver
Software
Hardware
Display
Device
Frame
Buffer
Unsecure
Memory
Secure
Memory
Memory
LED
Indicator
TrustUI Design: Secure Input
Normal World
Secure World
Secure Kernel
Untrusted Rich OS
Proxy
Secure
Application
Proxy
UI Element
Randomization
Touch Backend
Input Frontend
Touch Driver
Software
Hardware
Touch
Screen
Unsecure
Memory
Secure
Memory
Memory
Frame
Buffer
LED
Indicator
Display
Device
TrustUI Design: Network Delegation
Normal World
Secure World
Secure Kernel
Untrusted Rich OS
Proxy
Proxy
Network Backend
SSL Library
Network Frontend
NIC Driver
Software
Hardware
NIC
Device
Secure
Application
Unsecure
Memory
Secure
Memory
Memory
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"
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
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
Normal
World API
• Small TCB
– about 10K SLOC
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
Thank You!
Q&A
Source code of T6 available via:
http://www.liwenhaosuper.com/projects/t6