1. 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.
This work is done with guys in SJTU, Fudan and Huawei

2. Motivation The population of mobile users grows dramatically
Firstly let's talk about the motivation, the population of mobile users and the number of mobile devices grow dramatically in recent years, as shown in the left figure. However, this is also true for the mobile malware.
The population of mobile users grows dramatically
So is the malware!

3. 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
Of all the malware, there is a special kind called key and screen logger malware that log users' input and screen data, which is quite common in reality and even many companies develop and sell this kind of malware. The key and screen logger attack can be trivial, as many mobile users want their devices rooted or jailed break. Once a malicious malware gets the root privilege, existing solutions could be easily bypassed.

4. Device Drivers are vulnerable!
Among these vulnerabilities, many are due to device drivers
Device drivers should not be trusted!
Moreover, among these key and screen logger vulnerabilities, many are due to the misconfiguration of device drivers, this situation is worse in Android ecosystem, as Android phone manufacturers are under the pressure of competition to move quickly on their new models, customizing Android, especially device drivers, to fit their hardware. As shown in the three figures, recently researchers found that attackers can easily steal mobile touch and display data by a malware without requiring any special permission and this vulnerability exists in several mobile products of different vendors.

5. 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:
With the key and screen logger malware, attackers could steal user's input data such as password and even capture and tamper with sensitive display data such as payment amount, which may cause a great loss to users. The key reason for the existence of these attacks is the lack of a trusted path between users and their devices as well as devices and Internel services.

6. 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
The goal of TrustUI is to provide a trusted path between services and end users while preserving data confidentiality with a minimal TCB and is deployable to existing mobile devices.

7. OUTLINE Motivation of TrustUI Background and Design Alternatives
Design and Implementation
Evaluation
Conclusion

8. 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
ARM TrustZone technology was introduced more than a decade ago and is now widely deployed in mobile devices, yet still few devices utilize this technology nowadays. The feature of TrustZone could be divided into three parts: xxx,xxx,and xxx.

9. 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
TrustZone introduces two separated worlds: normal world and secure world, both worlds contain legacy CPU mode separation. By default, secure world can access all states of normal world but not vice-versa. Besides, a new privileges mode called secure monitor mode is introduced, which is usually used to switch between the two worlds and handle security violation.

10. 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
Memory region and peripheral could be assigned to secure world accessible only or by both. Direct Memory Access is also included in its protection scope and normal world DMA could not access secure memory. Moreover, every interrupt could be configured to be used by normal world or secure world.

11. 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
We consider software-based attacks while physical hardware attacks are out-of-scope. Code running in secure world and monitor mode is trusted while others are untrusted.

12. 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
a strawman's approach to providing a trusted path is to deploy two separated OSes running in different worlds, a rich functionality OS such as Android runs in normal world while a closed-box secure OS, which includes some necessary device drivers and core logics, runs in the secure world and the secure OS handles the sensitive UI interaction. However, it has some limitations: some vendors may refuse to provide device drivers source code. Secondly, as I mentioned earlier, device drivers are vulnerable to attacks and should not be trusted.

13. OUTLINE Motivation of TrustUI Background and Design Alternatives
Design and Implementation
Evaluation
Conclusion

14. TrustUI Design A security-oriented split driver model
Reuse existing device drivers without trusting them
TrustUI adopts a security-oriented split driver model so as to reuse existing device drivers without trusting them. A device driver is splitted into frontend and backend. The backend part is the unmodified driver code while the frontend is the secure wrapper of it. The two parts communicate through two world proxies using shared memory and the secure world exclusively uses a LED indicator peripheral to indicate the security status of current execution environment. Note that the secure kernel isolates itself from normal world by reserving a region of secure memory.

15. TrustUI Design: Secure Display
Normal World
Secure World
Untrusted Rich OS
Secure Kernel
Proxy
Proxy
Secure Application
Display Backend
Display Lib
Display Frontend
Display Driver
Firstly let's see how secure display is implemented. After boot-up, the OS runs in normal world and except the LED indicator, most of devices are used by the untrusted OS. When an application needs to have a secure display, it will invoke a secure monitor call instruction and switch to secure world. Then it configures the display device and frame buffer region as secure world accessible only. After that, the LED indicator is turned on indicating that a secure display environment is ready. At last the display frontend driver gets the display configuration information from untrusted OS and starts to display sensitive data.
Software
Hardware
Display Device
Frame Buffer
Unsecure Memory
Secure Memory
LED Indicator
Memory

16. TrustUI Design: Secure Input
Normal World
Secure World
Untrusted Rich OS
Secure Kernel
Proxy
Proxy
Secure Application
Touch Backend
UI Element Randomization
Input Frontend
Touch Driver
To secure the input data, TrustUI reads the touch data directly from the touch backend driver in untrusted OS and deploys a UI Element Randomization module in secure world. Since attackers in normal world could not read secure display information, they could not get any useful information as long as the secure sensitive UI element information is not leaked out.
Software
Hardware
Touch Screen
Unsecure Memory
Secure Memory
Frame Buffer
LED Indicator
Display Device
Memory

17. TrustUI Design: Network Delegation
Normal World
Secure World
Secure Kernel
Untrusted Rich OS
Proxy
Proxy
Secure Application
Network Backend
SSL Library
Network Frontend
NIC Driver
A trusted path from device to remote service is established by add an SSL library in secure world and delegating every network calls to normal world untrusted rich OS.
Software
Hardware
NIC Device
Unsecure Memory
Secure Memory
Memory

18. 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
Given the above TrustUI design, there are several security challenges that are needed to be addressed. The first one is code tampering attack, attackers may tamper with the secure kernel image which is stored in the external storage. This is prevented by using secure boot (at each boot stage, the loaded image signature is checked before executed). Denial-of-Service and phishing attack could be detected by checking the LED indicator. Touch Logger and Frame Buffer Overlay attack will be discussed in the following.

19. 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
Modern display device has more than one window, each could correspond to a different frame buffer with different priority. 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 to overwrite the data user eventually sees (known as screen hijacking attack).

20. 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
To solve FB overlay attack, we apply LED and color randomization scheme. A screen display contains a foreground and background layer, each with a different color, and the LED indicator will display these two colors in turn consecutively. The background layer elements include bitmap image, pure pixel color while the foreground layer elements include bitmap image, button image and text font. The foreground font element has the same color as foreground layer and foreground bitmap contains a foreground color rendered on the edge and a watermark in random position.

21. 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
UI elements randomization is applied to prevent attackers from getting any useful semantic information. Since the secure kernel reads touch input data directly from untrusted device driver, attackers may also learn this information. Actually, the information attackers could get includes input length, touch position and interval. We provide a soft keyboard and apply obfuscation using keyboard randomization to randomize them by adding an offset for each key each time a key is hit and randomly generating a pop-up button on the screen for user to click before continuing. Other UI elements randomization are up to the TA developers to make a tradeoff between security and user experience.

22. TrustUI Implementation
Implemented in Samsung Exynos development board
with ARM Cortex-A9 processor
Run Android Ice Cream Sandwich in normal world
Linux kernel version
Source Code has been merged into T6
T6: a TrustZone based trusted kernel for mobile
TrustUI is implemented in Samsung Exynos 4412 development board, which is equipped with ARM cortex-A9 processor and the implementation code is merged into T6, a TrustZone based trusted kernel for mobile that is ported from MIT Xv6. The reason why TrustUI is not implemented in the real mobile phone is that most of phones have a secure boot checking that preventing us from using TrustZone unless we get some help from the device vendors.

23. OUTLINE Motivation of TrustUI Background and Design Alternatives
Design and Implementation
Evaluation
Conclusion

24. Security Evaluation
(left)Touch-logger analysis: touch position and length
(a)(b)(c) got by entering password ‘ ’
(d) (e) by entering ‘5cfc912f’ and ‘ ’
(f) by ‘f6b0736c3b’
(right)Touch-logger analysis: touch interval
We construct a touch logger attack and log the information when using the secure soft keyboard. The left figure is the heap map we draw. (a)(b)(c) are got by entering password 8 zeroes. (d)(e) are got when entering different keys. We could hardly get any useful information from these map. The right figure shows the touch interval map. The blue ones are normal touches while the red ones are injected touches and there is no much difference between the interval time graph.

25. 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.
We also construct a screen-capture attack by reading device file in Linux fb device files. The attack could not succeed in our experience.

26. 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
The attack surface is greatly reduced and this table shows the APIs provided by TrustUI. The TCB is about 10K source lines of code.

27. 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

28. Source code of T6 available via:
Thank You!
Q&A
Source code of T6 available via: