March 6, 2020
In the first part of this series I explained the TrustZone technology and the basic of Trusted Execution environments. I also mentioned that there are various TEE implementations out there. Trustonic’s Kinibi TEE and Qualcomm’s QTEE are the two major TEE implementations used in the Android ecosystem that make use of the Arm TrustZone technology. Trustonic’s Kinibi TEE implementation was primarily designed for devices with the Exynos chipset, mainly used in European and Asian markets. Qualcomm-based Samsung devices run QTEE but also support the execution of Kinibi.
In this part, I will use the Kinibi TEE implementation as an example to explain how TEE’s work under the hood and how Trusted Applications (TAs) in the Secure World (SWd) communicate with apps in the Normal World (NWd).
Here’s a rough overview of the main Kinibi components:
RTM: The Run-Time Manager (RTM) handles memory management, task loading, and exception handling [ref]. It is also able to pass messages between the two worlds.
MTK: The Kinibi Microkernel runs in S-EL1, and provides isolation between tasks, inter-process communication, and performs preemptive scheduling of TAs.
Kinibi Client API: “Client Applications” (CA) make use of the Kinibi Mobicore Client API to load and interact with TAs. CA access this API via the libMcClient.so library, which provides APIs to request handles to sessions and relay notifications between the NWd and SWd via a shared memory buffer visible from both worlds [ref]. The MobiCore Client API works by relaying requests from CAs to the MobiCore daemon running with high permissions in the NWd. This Daemon relays the request up to the MobiCore driver in NWd EL1. This driver then communicates with the TEE RTM via the MobiCore Interface (MCI).
McLib: The Mobicore Library (McLib) is used by TAs and drivers in the TEE and consists of the a proprietary Internal API and a Global Platform (GP) Internal API. Trusted Applications can use the TLAPI to call McLib functions, while Trusted Drivers have access to a richer set of stubs provided by the DRAPI.
Cryptographic operations and algorithms: Kinibi provides a number of cryptographic services to REE, including a secure random number generator, data encryption services, secure key creation and destruction, as well as the provision of basic cryptographic algorithms such as cryptographic hashes, generation and verification of MACs and digital signatures [ref].
Secure Objects: Kinibi provides REE applications with the ability to access “Secure Objects”, which contain data in encrypted and integrity-protected form. Once encrypted, the data can be stored in insecure locations, such as on disk in the normal world. The key to decrypt the secure object is derived from the device master key and is uniquely derived for every TA. Additionally, the keys for secure objects never leave the TEE. This means that a secure object can only ever be decrypted on the device that generated it, inside the TA that created it, and when the user has logged in. The services to create and manage secure objects are provided by the Kinibi Trusted Storage API [ref].