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

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!

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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

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

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.

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

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.

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.

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

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

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.

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.

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

Source code of T6 available via: Thank You! Q&A Source code of T6 available via: http://www.liwenhaosuper.com/projects/t6