ARM TrustZone on Android
from the perspective of an app developer
TrustZone is a hardware-based security feature built into every modern ARM processor. Using TrustZone, you have hardware support for creating a separated secure environment to place and use in your private assets. Considering market share of ARM processors on Android, you would expect it to be used widely by Android app developers. However, it is currently not for several reasons.
Why is TrustZone not reachable for application developers?
Not that TrustZone (TZ) would not be used at all. It is widely used by device manufacturers and system developers. Both Samsung and Huawei, the biggest producers of Android devices, develop their Trusted Execution Environment (TEE) atop of TZ. Android uses its secure operating system (OS) atop of TZ for cryptographic and security operations. On any ARM-based Android device, the TZ is present and likely used. The problem is that third-party developers have no or very limited direct access to it. One can use security-oriented APIs provided by Google, some of which are making use of the TEE. However, the developer cannot create his/her secure app, nor can he/she use the present TEE itself in any direct way. To use TZ, trusted OS need to be built (or bought) and installed on the device. Then the secure monitor must be implemented and used to communicate with this trusted OS. Imagine trying to install your trusted OS on an Android device. Neither is it something which an app developer would want to do nor something Google seems to want to allow.
There seems to be currently only systematic approach to allow third-party developer direct access if adopted and deployed — TZ-based TEE accessible through unified API provided by Global Platform (more on that later).
TrustZone details
“Arm TrustZone technology is a System on Chip (SoC) and CPU system-wide approach to security. TrustZone is hardware-based security built into SoCs by semiconductor chip designers who want to provide secure endpoints and a device root of trust. The family of TrustZone technologies can be integrated into any Arm Cortex-A and the latest Cortex-M23 and Cortex-M33 based systems, from the smallest of microcontrollers, with TrustZone for Cortex-M processors, to high-performance applications processors, with TrustZone technology for Cortex-A processors.” (Official ARM website)
The core of TrustZone’s approach is the concept of secure and non-secure worlds that are hardware separated, with non-secure software blocked from accessing secure resources (e.g., memory regions with a secret key) directly. Within the processor, software either resides in the secure world or the non-secure one; a switch between these two worlds is accomplished via software component referred to as the security monitor.
Any part of the system can be designed to be a part of the secure world. By creating a security subsystem, assets can be protected from software attacks by other applications running on a target system and some common hardware attacks.
The partitioning of the two worlds is achieved by hardware logic present in the bus fabric, peripherals, and processors. Each physical processor core has two virtual cores: one considered secure and the other non-secure and a robust mechanism is provided to context switch between them (Secure Monitor exception).
Usage
“Typical use cases include the protection of authentication mechanisms, cryptography, key material and Digital rights management (DRM). Applications that run in the secure world are called Trusted Apps.”
(Official ARM website).
Trusted apps should be kept as small as possible to lower the probability of introduction of security flaws and also to execute and finish fast. Usually, they are written in the C language, while rich-world apps are developed using a wide variety of tools, providing feature-rich software for consumers. Inside the secure world, one can (for instance):
• Store keys, hashes, and data
• Generate pseudo-random numbers
• Do basic cryptographic operations
• Set up trusted boot
• Use digital signatures
We can do more complex operations inside the secure world as well, however, the point of 2-world approach is to keep trusted apps small and secure. When designing trusted software, it is essential to decide when the feature is too big or too dangerous (or not so important) to be kept inside a secure world. Storing private RSA keys? Sure. Sending already signed document through the internet using Android resolver to choose whether it will be sent through e-mail or messaging app? That should be done in the rich OS. The balance between securing as much as we can and keeping the rest of the trusted app simple and secure is the key.
Actual situation on the market
Samsung uses its TEE to provide custom security tools, including Samsung Pay.
Android provides tools for secure development and internally uses its own TEE. The developers do not interact with those TEE’s directly, and it is not a bad thing. Having TEE, where you perform critical operations with cryptography, secure payments, and digital signatures imply you need to have control over it. Letting third-party developers to introduce their apps (which will probably contain security flaws) inside your trusted world would compromise the security of the system.
The opposite situation would be to let developers implement their separated TEE and put their trusted apps inside. In the past, the ARM provided specifications for building and using TEE with TZ itself. For years now, API is provided by Global Platform (GP). The API “defines the communication between applications running in a rich operating environment and the applications residing in the Trusted Execution Environment (TEE)”
(GP websites).
GP provides more APIs focused on TEE. TEE Internal API Specification “defines a set of C APIs for the development of Trusted Applications (TAs) running inside a Trusted Execution Environment (TEE)” (GP websites).
Developers would then build their TEE with trusted OS and secure monitor, that would be compliant with these, and other APIs provided by the GP or use available implementations like SierraTEE or OP-TEE.
Problems
While, in theory, considerable approach, that makes sense when developing a whole device, OS, or software for open OS, trying to introduce your own TEE to an Android device failed to be widely used because of several reasons. To build in custom TEE inside Android device, developers would have to modify the core operating system excessively. Android is an open platform, to some degree, but not for third-party app developers, who would like to tinker with the system itself. Android is mostly built as a “walled garden.” Although device developers can modify the system, apps are installed only from PlayStore. You can install apps from another source, but it is prohibited by default and considered dangerous practice. Even so, you can not pack whole TZ-based (hardware) TEE full of trusted software inside a simple Android application package (APK). To install this TEE, a user would have to do it manually, most likely by rooting their device first with a resulting decrease in the protection offered by the system.
Such an approach is not something desired by a regular developer for applications intended for ordinary users. Instead, one wants to distribute their software inside the standard package via PlayStore. Unfortunately, true hardware TZ TEE cannot be achieved under this setup.
Possible solution
The device developers can modify the system and introduce their TZ based TEE; application developers do not have this option. Even if they would have, situation, where there are several TEEs running on a single device and each one using TrustZone-enabled processor directly, would lead to performance issues and logistic problems. And the user would have to trust each developer to build their TEEs responsibly.
The ideal solution would lie somewhere in between. Device manufacturers would use their TEE, Android would use its internal one. And there would be third, open, GP API compliant TEE available to app developers in Android. In case Google would provide such TEE using TrustZone technology, app developers could make their trusted apps and communicate with them in a standardized, open way.
Trusty
While there is no sign of this happening any soon, Google started their new Android Open Source project called Trusty back in 2016.
“Trusty TEE consists of:
• An operating system (the Trusty OS) that runs on a processor intended to provide a TEE
• Drivers for the Android kernel (Linux) to facilitate communication with applications running under the Trusty OS
• A set of libraries for Android systems software to facilitate communication with trusted applications executed within the Trusty OS using the kernel drivers”
(Android source websites)
However, there is not a single mention of compliance with GlobalPlatform specifications nor about the TrustZone itself. The page did not change since the beginning of the project, and there are only minor to none signs of recent development. While Trusty itself is far from our ideal solution, it could be a big step towards it.
Workaround solution?
Well, packing “real” (i.e., TrustZone hardware) TEE inside a native Android app is by all means impossible task. However, we could get the partial functionality of the real TEE by implementing “virtual TEE,” that would be GP API compliant.
Moreover, there is such a project currently in development called Open-TEE. From their website:
“The goal of the Open-TEE open source project is to implement a “virtual TEE” compliant with the recent GlobalPlatform TEE specifications.
Our primary motivation for the virtual TEE is to use it as a tool for developers of Trusted Applications and researchers interested in using TEEs or building new protocols and systems on top of it. Although hardware-based TEEs are ubiquitous in smartphones and tablets ordinary developers and researchers do not have access to it. While the emerging GlobalPlatform specifications may change this situation in the future, a fully functional virtual TEE can help developers and researchers right away.” (Open-TEE websites on GitHub)
Developers could have TEE to try to build their apps onto. If the TEE is GP API compliant, such apps could be easily ported to use eventual GP compliant hardware TEE from Google. Open-TEE can run on certain Android devices already. However, only versions 5.0–5.1.1 are supported at the time being (Summer 2018).
There has been no commit since August 2016 to Open-TEE repository. To be practically usable for Android app developers, someone needs to continue the Android fork, adapt to the newer Android versions and finish the Open-TEE implementation.
Conclusion
While TrustZone as a significant hardware-based security tool is widely used in actual Android devices, it is not yet available to third-party app developers. There is hope for security-oriented Android app developers in the form of Open-TEE, Trusty, or possible future TEE made by Google and available to everyone, but there is no “real” TEE which can be deployed across devices from different vendors and Android versions. We can discuss whether there should be one and how it should look like (e.g., like GlobalPlatform TEE API compliant one), though talking itself about it will not do much help. Asking Google for it, or helping the Open-TEE project could.
While virtual TEE lacks most of the benefits of the “real” TEE, it could help developers to prepare for “real” one and even develop some working software.
Side note
We did not delve into TEE implementations made by System on Chip (SoC) manufacturers, like QSEE (Qualcomm’s TEE) or Tegra TEE. While those are available and used by device developers and manufacturers, they are (again) not available to third-party developers and commonly are not GP API compliant. Therefore, even if they were available, developers would have to write the app for many different TEE APIs to achieve good market coverage. Again, this is a good viable option for device developers (who know which SoC they are putting inside their devices), but not for app developers.
References
https://www.samsung.com/global/galaxy/what-is/trust-zone/ What is TrustZone and how does Samsung Knox use it? Official Samsung websites
https://globalplatform.org/specs-library/tee-client-api-specification/ TEE Client API Specification v1.0 | GPD_SPE_007, GlobalPlatform Technology Document Library.
https://en.wikipedia.org/wiki/Closed_platform Closed platform, a Wikipedia article.
https://source.android.com/security/trusty/ Trusty, Google AOS (Android Open Source) project, based on kernel 3.18 branch, no sight of activity since 2016 on the official page.
https://open-tee.github.io/, https://github.com/Open-TEE/opentee-android OpenTEE Open Source project. Still active, on Android supports version 5.0–5.1.1 only.