TEE & SE
What is a HSM?
While hardware security modules can refer to many different implementations of key-storage where a Linux kernel compromise can’t reveal them, such as TEE, StrongBox explicitly refers to devices such as embedded Secure Elements (eSE). Supported devices running Android 9 (API level 28) or higher can have a StrongBox Keymaster, an implementation of the Keymaster or Keymint HAL that resides in a hardware security module-like secure element. HSM can be:
- TEE (Trusted Execution Environment)
- eSE (embedded Secure Element)
There are three main implementations of the
Trusted Execution Environment (TEE)
A trusted execution environment (TEE) is a secure area of a main processor. Today’s TEEs are based entirely on the concept of hardware-supported isolation, utilizing TrustZone technology. TrustZone creates two worlds: Secure world and non-secure world that exist simultaneously in parallel. The secure world runs its own Trusted OS (TOS) and Trusted Applications (TAs) at different privilege levels.
Android developers with their TEE implementation:
- Qualcomm TEE solution, also known as Qualcomm Secure Execution Environment (QSEE), is used in devices like Pixel, Nexus, LG, Sony, OnePlus, etc.
- Huawei - TrustedCore, limited sources
- Samsung TEEGRIS - based on GlobalPlatform API
- Trusty TEE - free TEE by Google
Existing TEEs
Several kinds of TEEs can be found on the market, but they can be divided into two categories given below.
- the TEEs used on desktop platforms, such as Intel SGX. As desktops are not the main subject of this article, these implementations will not be detailed.
- the TEEs used on mobile platforms, such as TrustZone, SEP, Titan M and others.
The last category can be subdivided in several implementation choices:
| | | |—|—| |
|Virtual processor implementation, such as ARM TrustZone, where CPU and hardware resources are shared between a Secure and a Non-Secure state| |
|On-Soc processor implementation, such as Apple SEP, where two CPUs, one Secure and one Non-Secure, share hardware resources| |
|External Coprocessor implementation, such as Google Titan M, located outside of the SoC, and unable to access hardware resources within the SoC| Source
ARM TrustZone Software Architecture
TrustZone is a system-wide hardware isolation achieved by separating the CPU into the Normal World and the Secure World. The Normal World contains and executes the main operating system, also called the Rich OS (e.g. Android, GNU/Linux, etc.), which the user primarily interacts with and which performs all the non-sensitive tasks. This operating system is distrusted by design, therefore all data communicated from the Normal World should be thoroughly checked before being used. In parallel exists the Secure World, which runs trusted code and stores/processes sensitive data.
To get a better granularity in the permissions management, ARM uses different Exception Levels going from EL0 to EL3 (EL0 being the least privileged and EL3 the most). An overview of the use of these exception levels is given in the figure above. ARM provides all the necessary tools to vendors for them to build their own TrustZone implementation.
Secure Element (SE)
A Secure Element (SE) is a separate microchip with its own CPU, storage, RAM, etc., designed specifically for security-relevant purposes. SEs are resistant to a wider variety of attacks, both logical and physical, such as side-channel attacks. Examples of SEs include SIM cards and credit card chips.
Android Ready SE Alliance
Google has partnered with secure element manufacturers to promote hardware-backed security in the Android ecosystem. Notable implementations include:
- Google - Titan M chip, since the Google Pixel 3
- Samsung - Samsung Knox
Android Keystore
The Android Keystore is a built-in system for securely storing and managing cryptographic keys on Android devices. It helps protect keys from theft by making them difficult to extract from the device or access by unauthorized apps. Key generation within the secure environment (TEE or SE) ensures strong protection for sensitive cryptographic keys.
Android offers a hardware-backed Keystore that provides key generation, import and export of asymmetric keys, import of raw symmetric keys, asymmetric encryption and decryption with appropriate padding modes, and more.
Keymaster
Android 6.0 introduced a hardware-backed crypto services API, Keystore, which provided digital signing and verification operations, as well as the generation and import of asymmetric signing key pairs. This API expanded its capabilities to include symmetric cryptographic primitives, AES and HMAC, and an access control system for hardware-backed keys. Keystore also added a usage control scheme and an access control scheme to limit key usage and mitigate security risks.
In Android 7.0, Keymaster 2 added support for key attestation and version binding, ensuring that keys are not used on devices that have been upgraded. In Android 8.0, Keymaster 3 transitioned from the old-style C-structure HAL to the C++ HAL interface, modifying argument types and extending the attestation feature to support ID attestation.
In Android 9, updates included support for embedded Secure Elements, secure key import, 3DES encryption, and version binding for independent updates.
- Keymaster 1-3: Hardware-backed keys = the key resides in the TEE.
- StrongBox Keymaster (Keymaster 4): Keys stored in a Secure Element, providing enhanced security against physical and side-channel attacks
Key Material Protection
The Android Keystore system protects key material from unauthorized use in two ways. First, it reduces the risk of unauthorized use of key material from outside the Android device by preventing the extraction of the key material from application processes and from the Android device as a whole. Second, the keystore system reduces the risk of unauthorized use of key material within the Android device by making apps specify the authorized uses of their keys and then enforcing those restrictions outside of the apps’ processes.
TrustZone Vulnerability
A vulnerability was found where communication between the secure and non secure worlds was intercepted. This bug, reproduced on a Samsung S5, is interesting as it enables arbitrary code execution in the most privileged mode of the processor: the monitor mode (EL3).
This vulnerability allows an attacker to get arbitrary code execution at runtime in monitor (EL3). This could be used to backdoor the Normal World as well as the Secure World, but could also be used to instrument or put a debugger into the Secure World (at monitor or secure OS level) in order to find new vulnerabilities in the TrustZone OS (TEE-OS).