At the China Graduate Integrated Circuit Innovation Competition in August this year, T-Head launched a design challenge: building a dual-core TEE security solution based on Xuantie Open E902. In this competition, there were many excellent designs, and some teams took the initiative to share their designs. The ReShaker team from Guangdong University of Science and Technology won first prize in the competition, and they blogged about their design.
Trusted Execution Environment (TEE) is an effective approach to information security. In order to obtain higher efficiency, building a dual-core system-on-chip (SoC) with TEE security capabilities is the hottest topic . However, TEE SoCs currently usually use complex processor cores, such as Rocket, resulting in high resource usage; more importantly, the encryption unit lacks flexibility and ignores secure communication between cores.
To solve the above problems, we designed a dual-core TEE SoC based on RISC-V.
First, a multi-level bus architecture is built that is completely isolated from the TEE environment and integrates Secure Core that supports SHA1, AES and RSA algorithm acceleration. RSA can be flexibly configured to five different key lengths; in addition, it also introduces Secure boot process based on Chain of Trust (CoT) to verify the authenticity and integrity of the loader.
IOMP is also used to configure Rich Execution Environment (REE) CPU and security core access permissions. Finally, mailboxes are used for inter-core communication, and a hierarchical access strategy for data exchange is proposed to ensure communication security.
Multi-layer bus architecture of TEE SoC
The SoC architecture in this work is shown in Figure 1. The proposed architecture uses two E902 CPUs developed by T-Head as processor cores. The CPU running in the TEE environment is called TEE CPU, and the processor running in the REE environment is called REE CPU. As shown in Figure 1, the dual-core SoC adopts a three-layer hierarchical bus design. The first layer of the bus located in the isolated system is under a secure world called FL-AHB. As the master device, the TEE CPU can access all devices under the bus, such as BootRom. This layer of the bus does not provide access to devices other than the master device. Therefore, an isolated system is a completely isolated environment with no direct access to internal data. The second layer bus is the bus used to build the TEE system (SL-AHB), and the TEE CPU can access all slave devices on this bus layer. At the same time, REE CPU access is restricted to slave devices on the bus by IOMP. The third layer bus is a sub-bus of SL-AHB and is converted into an APB bus to connect the peripheral IP (TL-AHB2APBx). IP is divided and connected to secure and non-secure APB buses. Access to these IPs is granted based on the ID of the primary device initiating access. In this design, when secure boot is completed, both the TEE CPU and the REE CPU will read the corresponding code and data from the main memory. As can be seen from the architecture, both master devices can access the main memory slave device at the same time, so the AHB bus uses round-robin arbitration in the architecture to grant the two CPUs the same priority, that is, fair use of bus resources.
secure boot
Secure boot is a necessary design requirement for TEE SoC and a prerequisite to ensure system security. During the secure boot process, it is often necessary to verify the authenticity and integrity of the code to ensure that it has not been tampered with. The secure boot process designed in this work is shown in Figure 2. The dual-core boot process is divided into two stages: TEE CPU boot and REE CPU boot. The REE CPU will hang until the code is loaded and verified. The secure boot process of TEE SoC is as follows.
When the SoC is powered on and reset, the TEE CPU first runs code in the BootRom. This code is primarily responsible for loading the ZSBL code and carrying the corresponding signature via the secure serial port to the ZSBL RAM in the isolated system.
The TEE CPU performs a SHA-1 extraction digest of the loader in ZSBL RAM and performs decryption of the signature using the RSA public key of the ZSBL code segment within the BootRom for signature verification of the loader. When the verification is passed, the TEE CPU jumps to the ZSBL RAM to run.
ZSBL first configures the IOMP restricted access address in the SoC, and then starts the secure serial port to load the TEE_REE code and the code signature signed by the RSA private key. Once the load is complete, the TEE CPU calculates the SHA-1 digest of the loaded code and data by using Secure Core and verifies the signature using RSA before starting execution of the TEE software stack.
The TEE CPU performs SHA-1 on specific processes in the REE software stack and obtains the corresponding summary list, which lays the foundation for future secure dual-core communication. After completing the list generation, the TEE CPU will configure the REE CPU boot address and pull the REE CPU's reset signal high to start the REE CPU. At this point, the secure boot of the TEE SoC is completed.
Design of Mailbox
In the dual-core SoC architecture, inter-processor communication (IPC) is the key to providing data communication, event control and resource sharing. As shown in Figure 3, we use mailbox communication based on shared memory and inter-core interrupts, and the shared memory is implemented using FIFO. Dual-core processes can transfer data through mailboxes, that is, read and write communications according to the legal interaction agreement between the two parties. In order to solve the read and write consistency problem of shared memory and protect the data security of the security core in the shared area, TEE CPU and REE CPU use independent shared memory respectively. The basic operation is as follows, as shown in Figure 3. When the REE CPU transmits data to the TEE CPU through the mailbox, it first writes the data type, data length and data to the FIFO of the mailbox. When the writing is completed, the R_Intr signal will be generated to notify The TEE CPU receives data from the mailbox. When the TEE CPU finishes receiving data, it generates the R_OK_Intr signal to notify the REE CPU that the communication is complete. Similarly, data transfer from TEE CPU to REE CPU is also completed by R_Intr and R_OK_Intr signals. Therefore, in order to achieve dual-core communication, both processor cores need to add two mailbox interrupt responses.
multi-level access policy
In order to ensure the security of dual-core communication, we designed a multi-level access control strategy based on shared memory. TEE CPU implements access control to REE CPU based on multi-level access control policies to protect the security of shared memory. Our TEE SoC provides three different security access control strategies.
- Level 1: Direct access strategy, which does not require any access control. The TEE CPU directly provides access services to the REE CPU, and only the process needs to meet the dual-core communication protocol.
- Level 2: Integrity access policy, which verifies the REE CPU process's access to security area resources to ensure that the process code or data has not been maliciously tampered with.
- Level 3: Confidentiality access policy, including validity and integrity access policies and data encryption policies, used to control access to high-security data, such as access keys, extracting fingerprints, extracting or changing passwords, and updating security zones. data etc.
We specify that the transaction requesting encryption is a confidential access event, as shown in Figure 4. For this type of access, you first need to SHA1 the code block of the access task to obtain the corresponding digest, and compare it with the task code digest obtained by secure boot to achieve integrity verification. When authentication is successful, the TEE CPU transmits the ciphertext (encrypted using AES) through the common shared memory in the mailbox. At this point, if a malicious process intercepts the value read by the mailbox, the value will be invalid. To transfer keys to the REE CPU, we use secure registers and memory areas in the mailbox that are writable only by TEEs for secure transfer. When the REE CPU finishes receiving the ciphertext, the TEE CPU writes the encryption key to a separate memory block (FIFO) in the TEE, while the write to the security register is valid, and writes an interrupt signal to notify the REE CPU to read. The REE CPU's interrupt handler will first determine whether the value of the security register is valid, ie. , giving the REE CPU permission to read the storage area in the mailbox that only the TEE CPU has write access to. When valid, the REE CPU reads data from isolated memory; otherwise, it reads from shared memory. Therefore, for confidential access, the original access process returns the value as ciphertext. When REE receives the ciphertext, it calls a specific key request task to obtain the AES key so that an attacker cannot easily obtain the key to decrypt the ciphertext. In our approach, AES keys are not directly exposed to REE. The confidentiality task is transmitted in two parts. The first part is that the TEE sends the encrypted ciphertext to the REE through the shared memory in the mailbox. The second part is that the REE requests the AES key from the TEE, which also verifies the integrity of the key request task. To ensure security, the key is transmitted through isolated memory.
In our work, a TEE secure SoC system with dual-core RISC-V CPU and multi-level bus architecture. RISC-V's newly proposed IOMP is also used to restrict CPU access rights in non-secure environments. In order to improve the processing efficiency of secure boot and encryption and decryption operations, we designed hardware computing units for RSA, AES and SHA1 algorithms and integrated them into the TEE SoC as security cores; access to the security core is restricted by IOMP. At the same time, we designed a simple CoT-based secure boot process to ensure the boot time authenticity and integrity of SoC environment boot. We implement dual-core communication using mailboxes based on shared memory and inter-core interrupts. Our architecture has lower resource consumption, higher flexibility and better security, which well meets the basic security and computing requirements of IoT edge devices.