Five things you need to know about TEE

The Android phones we usually refer to are not only the Android system, but also the TEE system which is closely related to security. Of course, in addition to these two systems, there will be other systems. Here I will only explain how TEE and Android coexist. First, I will introduce to you how to deploy these two systems, and then explain the communication mechanism of the two systems from the perspective of SMC scheduling, communication method and library. Finally, I will briefly explain the GP standard of TEE API.

1.TEE and Android architecture

First, let's take a look at how the Android system and TEE system coexist from an overall perspective. Figure 1 shows the coexistence architecture of TEE and Android system:

Figure 1 Coexistence of TEE and Android system

The non-secure side on the left side of the above picture is the familiar Android system, which we usually call REE. The secure side on the right side is the TEE system. There are many TEE systems on the market, such as Qualcomm's QSEE, Trustonic, and the open source OPTEE.

EL0, EL1, and EL3 in the figure are the exception levels in the ARM architecture, of which EL0 and EL1 must be implemented. It can be roughly considered that EL0 is the application layer and EL1 is the system kernel layer. The most important thing is that TEE-related drivers need to be deployed in EL1 on the REE side. The REE side finally communicates with the EL3 mentioned later through this driver to complete some functions. EL2 mainly provides support for virtualization, so EL2 will be ignored in this article. EL3 is a relatively important part, which provides function switching between the REE side (Non-secure) and the secure side (Secure). It can also be seen from the figure that only EL3 spans the REE side and the secure side, thus providing a communication interface for the two systems. For example, our commonly used fingerprint function and payment function require the interaction between the REE side and the secure side. In the following content, I will give you a detailed explanation of the communication between the two systems.

It is mentioned in the Trustzone white paper provided by ARM that in order to make the system more robust, it is recommended that the Monitor mode in EL3 disable interrupts during execution.

2.SMC

Here I would like to emphasize that the TEE system and the Android system are two completely independent systems, and the two systems run independently. However, in actual use, the two systems need to communicate. For example, when we lock the screen of our mobile phone or use fingerprint to unlock it, the Android system and the TEE system need to work together to complete it. The communication is completed through the SMC instruction, which is essentially to trigger an SMC interrupt (as shown in the red box in Figure 2 below), so that Android or TEE jumps to Monitor mode (Monitor/Firmware in the figure below), and the SMC interrupt processing is similar to the context switch in the system.

Figure 2 Environment switching

At this point, everyone should have a simple understanding of SMC, but I need to make one thing clear here: SMC is not the only way to enter Monitor mode, such as directly writing to the CPSR register.

3. REE/TEE transmission method

The above briefly explains SMC. So what should we do when the REE and TEE sides need to transfer data? In the existing processing scheme, shared memory is used, including static shared memory and dynamic shared memory. Since static shared memory is a shared memory agreed upon by the REE and TEE sides, an area will be reserved regardless of whether it is needed, which is a waste of memory. Dynamic shared memory has more complicated operation steps. We need to apply for memory first, then perform mmap mapping (both the TEE and REE sides need to perform mapping)), and then transfer data through shared memory.

Let's think about another question. When the TEE side transmits data to the REE side and the REE side transmits data to the TEE side, who applies for the shared memory respectively? Before answering this question, I need to introduce the term Session. A Session needs to be established before the TEE side and the REE side communicate. When the Session is established on the REE side, the shared memory is ready. After that, no matter which side the data is transmitted from or to, the previously prepared shared memory is used.

If you have a chance to look at the code of CA (an executable program on the REE side), you will find that the session is established first, and then the corresponding business processing can be carried out. There are different TEE manufacturers in the market, and their implementation details may differ, but their ideas are consistent.

4. Library

Generally, TEE manufacturers will provide us with TEE-related libraries, which will complete various functions by calling the corresponding TEE driver. Usually when developing a program that requires a TEE environment, it is best to ask the corresponding TEE manufacturer for a demo. With this demo, we will know how to develop a program based on the corresponding TEE.

5.GP

When I was communicating with some friends who work on Android, I found that they either didn't know TEE, or knew TEE but didn't know GP. Imagine that there are many TEE manufacturers on the market, such as Doujia and Trustonic, each of which has its own unique API interface. For some TEE-based functions, such as fingerprint, payment, etc., do we need to adapt each TEE differently? The full name of GP is Global Platform, which provides some security-related API requirements. If all projects use GP, then TEE-based modules (such as common fingerprint, payment, etc.) do not need to make major changes, and when communicating with such suppliers, you need to inform the supplier whether the current project uses the GP interface.

Summarize

So far, I have introduced the five major factors we need to know. Now, let's think about it. If I need to add fingerprint function to my project, what should I do?

• The deployment of the TEE environment includes the TEE system itself, Monitor, and TEE-related drivers and libraries on the REE side. Other details can be communicated with the TEE vendor.
• Communicate with the fingerprint manufacturer and inform them of the TEE system and TEE version used in the project, whether the GP interface is adopted, the fingerprint device model used in the project, etc.

In this article, I divide TEE into five elements. But in fact, the TEE system is far more complicated than what is introduced in this article. I hope that you can have a general understanding of TEE through this article, and on this basis, you can continue to study in depth.

About the Author

Zhao Qingtiao, 51CTO community editor, has been engaged in driver development for many years. His research interests include secure OS and network security, and he has published network-related patents.