A software level analysis of TrustZone OS and Trustlets in Samsung Galaxy Phone

Introduction:
New types of mobile applications based on Trusted Execution Environments (TEE) and most notably ARM TrustZone micro-kernels are emerging which require new types of security assessment tools and techniques.  In this blog post we review an example TrustZone application on a Galaxy S3 phone and demonstrate how to capture communication between the Android application and TrustZone OS using an instrumented version of the Mobicore Android library. We also present a security issue in the Mobicore kernel driver that could allow unauthorised communication between low privileged Android processes and Mobicore enabled kernel drivers such as an IPSEC driver.

Introduction:

New types of mobile applications based on Trusted Execution Environments (TEE) and most notably ARM TrustZone micro-kernels are emerging which require new types of security assessment tools and techniques.  In this blog post we review an example TrustZone application on a Galaxy S3 phone and demonstrate how to capture communication between the Android application and TrustZone OS using an instrumented version of the Mobicore Android library. We also present a security issue in the Mobicore kernel driver that could allow unauthorised communication between low privileged Android processes and Mobicore enabled kernel drivers such as an IPSEC driver.

Mobicore OS :

The Samsung Galaxy S III was the first mobile phone that utilized ARM TrustZone feature to host and run a secure micro-kernel on the application processor. This kernel named Mobicore is isolated from the handset’s Android operating system in the CPU design level. Mobicore is a micro-kernel developed by Giesecke & Devrient GmbH (G&D) which uses TrustZone security extension of ARM processors to create a secure program execution and data storage environment which sits next to the rich operating system (Android, Windows , iOS) of the Mobile phone or tablet. The following figure published by G&D demonstrates Mobicore’s architecture :

Overview of Mobicore (courtesy of G&D)

A TrustZone enabled processor provides “Hardware level Isolation” of the above “Normal World” (NWd) and “Secure World” (SWd) , meaning that the “Secure World” OS (Mobicore) and programs running on top of it are immune against software attacks from the “Normal World” as well as wide range of hardware attacks on the chip. This forms a “trusted execution environment” (TEE) for security critical application such as digital wallets, electronic IDs, Digital Rights Management and etc. The non-critical part of those applications such as the user interface can run in the “Normal World” operating system while the critical code, private encryption keys and sensitive I/O operations such as “PIN code entry by user” are handled by the “Secure World”. By doing so, the application and its sensitive data would be protected against unauthorized access even if the “Normal World” operating system was fully compromised by the attacker, as he wouldn’t be able to gain access to the critical part of the application which is running in the secure world.

Mobicore API:

The security critical applications that run inside Mobicore OS are referred to as trustlets and are developed by third-parties such as banks and content providers. The trustlet software development kit includes library files to develop, test and deploy trustlets as well as Android applications that communicate with relevant trustlets via Mobicore API for Android. Trustlets need to be encrypted, digitally signed and then remotely provisioned by G&D on the target mobile phone(s).  Mobicore API for Android consists of the following 3 components:

1) Mobicore client library located at /system/lib/libMcClient.so:  This is the library file used by Android OS or Dalvik applications to establish communication sessions with trustlets on the secure world

2) Mobicore Daemon located at /system/bin/mcDriverDaemon: This service proxies Mobicore commands and responses between NWd and SWd  via Mobicore device driver

3) Mobicore device driver: Registers /dev/mobicore device and performs ARM Secure Monitor Calls (SMC) to switch the context from NWd to SWd

The source code for the above components can be downloaded from Google Code.  I enabled the verbose debug messages in the kernel driver and recompiled a Samsung S3 kernel image for the purpose of this analysis. Please note that you need to download the relevant kernel source tree and stock ROM for your S3 phone kernel build number which can be found in “Settings->About device”. After compiling the new zImage file, you would need to insert it into a custom ROM and flash your phone. To build the custom ROM I used “Android ROM Kitchen 0.217” which has the option to unpack zImage from the stock ROM, replace it with the newly compiled zImage and pack it again.

By studying the source code of the user API library and observing debug messages from the kernel driver, I figured out the following data flow between the android OS and Mobicore to establish a session and communicate with a trustlet:

1) Android application calls mcOpenDevice() API which cause the Mobicore Daemon (/system/bin/mcDriverDaemon) to open a handle to /dev/mobicore misc device.

2) It then allocates a “Worlds share memory” (WSM) buffer by calling mcMallocWsm() that cause the Mobicore kernel driver to allocate wsm buffer with the requested size and map it to the user space application process. This shared memory buffer would later be used by the android application and trustlet to exchange commands and responses.

3) The mcOpenSession() is called with the UUID of the target trustlet (10 bytes value, for instance : ffffffff000000000003 for PlayReady DRM truslet) and allocate wsm address to establish a session with the target trustlet through the allocated shared memory.

4) Android applications have the option to attach additional memory buffers (up to 6 with maximum size of 1MB each) to the established session by calling mcMap() API. In case of PlayReady DRM trustlet which is used by the Samsung VideoHub application, two additional buffers are attached: one for sending and receiving the parameters and the other for receiving trustlet’s text output.

5) The application copies the command and parameter types to the WSM along with the parameter values in second allocated buffer and then calls mcNotify() API to notify the Mobicore that a pending command is waiting in the WSM to be dispatched to the target trustlet.

6) The mcWaitNotification() API is called with the timeout value which blocks until a response received from the trustlet. If the response was not an error, the application can read trustlets’ returned data, output text and parameter values from WSM and the two additional mapped buffers.

7) At the end of the session the application calls mcUnMap, mcFreeWsm and mcCloseSession .

The Mobicore kernel driver is the only component in the android operating system that interacts directly with Mobicore OS by use of ARM CPU’s SMC instruction and Secure Interrupts . The interrupt number registered by Mobicore kernel driver in Samsung S3 phone is 47 that could be different for other phone or tablet boards. The Mobicore OS uses the same interrupt to notify the kernel driver in android OS when it writes back data.

Analysis of  a Mobicore session:

There are currently 5 trustlets pre-loaded on the European S3 phones as listed below:

shell@android:/ # ls /data/app/mcRegistry

00060308060501020000000000000000.tlbin

02010000080300030000000000000000.tlbin

07010000000000000000000000000000.tlbin

ffffffff000000000000000000000003.tlbin

ffffffff000000000000000000000004.tlbin

ffffffff000000000000000000000005.tlbin

[...]

Original source