Distributed TEE system, communication method based on distributed TEE system

Abstract

This application relates to a distributed TEE system and a communication method based on the distributed TEE system. The system includes multiple TEEs, each TEE's secure world includes a key management module and a communication invocation module, and the TEE's trusted operating system includes an encryption / decryption module. Each module is invoked by a security monitor within the TEE or runs in a first memory location of the secure world that can be accessed by the ordinary world. The key management module is used to generate keys; the encryption / decryption module is used to encrypt specified data according to the key when the TEE generates specified data in response to a memory access instruction, verify the integrity of the first data packet received from another TEE, and decrypt the first data packet according to the key; the communication invocation module is used to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet. This method can improve the security of data communication when deploying a TEE system in a distributed system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of trusted execution environment, in particular to a distributed TEE system and a communication method based on the distributed TEE system. BACKGROUND

[0002] TEE (Trusted Execution Environment) is a kind of secure computing environment of software and hardware combination to ensure the confidentiality and integrity of data and code during execution. TEE provides a secure and isolated environment for mobile devices and other types of hardware to ensure that sensitive data and critical code run in a protected environment. At present, the research on TEE is mostly concentrated in devices such as CPU (Central Processing Unit) or GPU (Graphics Processing Unit), considering the boundary expansion of TEE in the system, and constantly expanding the scope of TEE to protect the data of multiple devices, but not considering the communication security problem between different TEEs, and lacking of security consideration for deploying TEE system in distributed system.

[0003] In view of the low data security problem of deploying TEE system in distributed system in the related art, there is no effective solution at present. SUMMARY

[0004] Therefore, it is necessary to provide a distributed TEE system and a communication method based on the distributed TEE system to solve the problem of low data security when deploying TEE system in distributed system.

[0005] In a first aspect, a distributed TEE system is provided in the present embodiment, the distributed TEE system comprising: a plurality of TEEs, each of the TEEs comprising a key management module and a communication calling module in a security world of the TEE, and comprising an encryption and decryption module in a trusted operating system of the TEE, the key management module, the communication calling module and the encryption and decryption module being invoked by a security monitor in the TEE or running in a first memory, the first memory being a part of memory area in the security world of the TEE that can be accessed by programs and operating systems of a normal world, and wherein,

[0006] The key management module is configured to generate a key corresponding to each TEE.

[0007] The encryption and decryption module is configured to encrypt the specified data according to the key when the TEE generates the specified data in response to a memory access instruction; and verify the integrity of the first data packet transmitted by another TEE and decrypt the first data packet according to the key when the first data packet is received and is intact.

[0008] The communication calling module is configured to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet.

[0009] In some embodiments, the distributed TEE system includes a primary TEE and a plurality of secondary TEEs, the primary TEE includes a first security monitor, and the first security monitor is provided with a first security checking module, a first function calling module, the key management module and the communication calling module; wherein,

[0010] The first function calling module is configured to provide a function calling interface of an encryption and decryption module of the primary TEE.

[0011] The first security checking module is configured to, when the first data packet transmitted by the secondary TEE is received, call the encryption and decryption module of the primary TEE through the function calling interface to perform the steps of verifying the integrity of the first data packet and decrypting the first data packet according to the key when the first data packet is intact.

[0012] In some embodiments, the communication calling module is configured to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet, including:

[0013] The communication calling module of the primary TEE is configured to encapsulate the encrypted specified data into a second data packet and transmit the second data packet to the secondary TEE through an application program in the TEE; and / or, when the data obtained by decrypting the first data packet is non-control data, encapsulate the decrypted first data packet into the second data packet.

[0014] In some embodiments, the distributed TEE system includes an ordinary world and a secure world isolated from each other, the distributed TEE system includes a primary TEE and a plurality of secondary TEEs, and the memory of the secure world accessible by the secondary TEEs includes the first memory and the second memory; wherein,

[0015] The first memory is a memory region that can be accessed by programs and operating systems of the ordinary world based on a preset interface;

[0016] The second memory is a memory region that cannot be accessed by programs and operating systems of the ordinary world.

[0017] In some embodiments, the distributed TEE system includes a primary TEE and multiple secondary TEEs. Each secondary TEE includes a second security monitor, which is equipped with a second function call module, the key management module, and the communication call module.

[0018] The second function call module is used to provide a function call interface to call the encryption / decryption module of the second-level TEE to verify the integrity of the first data packet, and decrypt the first data packet according to the key if the first data packet is intact, and / or call the encryption / decryption module of the second-level TEE to encrypt the specified data.

[0019] In some embodiments, the distributed TEE system includes a primary TEE and multiple secondary TEEs. When the secondary TEE includes multiple trusted operating systems, each trusted operating system is equipped with the encryption / decryption module.

[0020] Secondly, this embodiment provides a communication method based on a distributed TEE system. The distributed TEE system includes multiple TEEs. If the security world of each TEE includes a security monitor, the method is executed based on the security monitor. If the TEE does not include the security monitor, a first memory accessible to programs and operating systems in the ordinary world is determined within the security memory of the TEE, and the method is executed in the first memory. The method includes:

[0021] Upon receiving the first data packet transmitted by another TEE, the integrity of the first data packet is verified. If the first data packet is intact, the first data packet is decrypted based on the key corresponding to the other TEE, and the corresponding memory access instruction is executed based on the decrypted data.

[0022] When the TEE generates specified data in response to a memory access instruction, the key corresponding to the TEE is invoked to encrypt and encapsulate the specified data, and the encapsulated second data packet is transmitted to the corresponding other TEE and / or the corresponding electronic control unit.

[0023] In some embodiments, executing the corresponding memory access instruction based on the decrypted data includes:

[0024] Determine whether the data obtained after decrypting the data packet is preset control data;

[0025] If the decrypted data is the control data, then the decrypted data is sent to the corresponding electronic control unit.

[0026] If the data obtained after decryption is non-control data, then the data obtained after decryption is stored in the corresponding memory.

[0027] In some embodiments, the distributed TEE system includes mutually isolated ordinary world and secure world, wherein the memory accessible in the ordinary world is ordinary memory, and the memory accessible in the secure world is secure memory. If the decrypted data is non-control data, then storing the decrypted data in the corresponding memory includes:

[0028] If the data obtained after decryption is determined to belong to the first type of data based on the data transmission type of the data packet, the specified data is granted read permission, and the data obtained after decryption is stored in the ordinary memory;

[0029] If the data obtained after decryption is determined to belong to the second type of data based on the data transmission type of the data packet, the data obtained after decryption is stored in the secure memory.

[0030] In some embodiments, after storing the decrypted data in secure memory, the method further includes:

[0031] Encapsulate the decrypted data;

[0032] In response to a data transmission command, the encapsulated data packet is transmitted to another of the TEEs.

[0033] The aforementioned distributed TEE system and the communication method based on the distributed TEE system, by calling the key management module, communication call module, and encryption / decryption module through the security monitor, or by running the key management module, communication call module, and encryption / decryption module through the first memory, can enable each TEE to first check the security of the data packet and then execute the memory access instruction corresponding to the data packet. This avoids programs in the ordinary world from directly accessing resources in the secure world, thus improving the security of data communication when multiple TEEs are deployed in a distributed system. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the structure of a distributed TEE system in one embodiment;

[0035] Figure 2 This is a schematic diagram of the structure of a distributed TEE system in another embodiment;

[0036] Figure 3 This is a schematic diagram of the structure of a distributed TEE deployed in a smart vehicle in one embodiment;

[0037] Figure 4This is a schematic diagram of a Level 1 Center-TEE architecture in one embodiment;

[0038] Figure 5 This is a schematic diagram of a 2-level subf-TEE architecture in one embodiment;

[0039] Figure 6 This is a schematic diagram of a two-level subs-TEE architecture in one embodiment;

[0040] Figure 7 This is a schematic diagram of a two-level subt-TEE architecture in one embodiment;

[0041] Figure 8 This is a schematic diagram of a Level 2 subf-TEE sending data to a Level 1 Center-TEE in one embodiment;

[0042] Figure 9 This is a schematic diagram of a Level 2 Subs-TEE sending data to a Level 1 Center-TEE in one embodiment.

[0043] Figure 10 This is a schematic diagram of a Level 2 subt-TEE sending data to a Level 1 Center-TEE in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] In related technologies, to protect security-critical applications and data, ARM initially proposed the TrustZone architecture (a TEE architecture) in 2009, dividing the system into a secure world and a normal world. Security-critical data can only be used and accessed in the secure world. In 2013, Intel proposed the SGX (Software Guard Extensions) design, introducing the concept of an enclave. When a normal user program uses security-critical data, an enclave is created. All operations on security-critical data are performed within the enclave. Once the data leaves the enclave, the enclave is automatically encrypted to prevent the leakage of sensitive data. In 2016, AMD proposed the Secure Encrypted Virtualization (SEV) architecture, which encrypts and stores security-critical data. When this data is needed, it is loaded into a virtual machine for decryption, with all related data operations confined within the virtual machine. With the rise of the RISC-V (Reduced Instruction Set Computer-Vector Extensions) instruction set architecture, businesses and academia gradually began researching RISC-V-based TEE architectures. In 2020, Keystone was first proposed. This technology utilizes the RISC-V architecture's unique PMP (Physical Memory Protection) mechanism to create enclaves and restrict their access scope, becoming the first RISC-V-based TEE design. In 2021, Shanghai Jiao Tong University designed and implemented a scalable RISC-V-based TEE system—"Penglai." The Penglai architecture extends existing RISC-V hardware primitives, allowing for scalable physical memory isolation. In 2021, ARM proposed a more complex and finer-grained CCA (Confidential Compute Architecture) architecture, achieving virtual machine-level isolation and protection, restricting the use of security-critical data to the Realm (the Realm world in the ARM CCA architecture) VM (Virtual Machine). In 2023, Intel also proposed a virtual machine-level TEE architecture—Intel TDX—which uses security-critical data only within confidential virtual machines, isolating confidential virtual machines from hardware.

[0046] However, the aforementioned TEE architectures all focus on the CPU and do not consider the interaction between the CPU and devices. With the advent of the big data era, many applications have begun to use heterogeneous devices such as FPGAs (Field Programmable Gate Arrays), GPUs, and NPUs (Neural Processing Units) to improve program performance. This also brings various security risks. Therefore, the academic community has begun to study extending the TEE boundary to heterogeneous devices to ensure the comprehensive security of data between the CPU and heterogeneous devices. In 2018, a GPU-supporting TEE architecture—Graviton—was proposed. It redefines the interface between the GPU driver and the hardware, introduces the concept of security context, and achieves secure isolation of data exchanged between devices. In 2019, the HIX architecture was proposed. This architecture extends the CPU TEE to the GPU by refactoring the GPU device driver, ensuring the security of data flow from the CPU to the GPU. In 2022, various heterogeneous device TEE architectures such as StrongBox, TNPU, and CRONUS were proposed. The StrongBox architecture extends TrustZone to ensure the security of general-purpose computing on integrated GPUs. The TNPU architecture focuses on designing low-overhead integrity protection and data encryption schemes to achieve a high-performance, low-loss, secure, and trustworthy NPU. The CRONUS architecture considers the commonalities of different devices and designs a general-purpose TEE architecture suitable for various heterogeneous devices, supporting simultaneous connections of different devices and providing a secure and isolated execution environment for multiple devices. In 2024, the CAGE architecture was proposed, which extends ARM CCA by introducing a shadow task mechanism and combining multiple GPTs (Granule Protection Tables) to collaboratively protect GPU computing tasks. In the same year, the ACAI architecture was proposed, which mainly focuses on the potential damage to system memory caused by the connection of damaged heterogeneous devices to the CPU. By deploying SMMU (device-side Memory Management Unit) and GPC (Granule Protection Check) checks, it performs security checks and isolation on data from heterogeneous devices, thereby protecting the data security of the CPU.

[0047] However, the aforementioned technologies lack consideration for deploying TEEs in distributed systems, do not support the deployment of different TEEs in distributed systems, and do not consider the communication security issues between different TEEs.

[0048] To address this issue, in one embodiment, a distributed TEE system is provided. This distributed TEE system can be applied to terminals including, but not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. Each module in the distributed TEE system of this embodiment can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0049] Figure 1 A schematic diagram of the distributed TEE system in this embodiment is provided, such as... Figure 1 As shown, the distributed TEE system includes multiple TEEs. Each TEE's secure world includes a key management module and a communication invocation module. The trusted operating system of the TEE includes an encryption / decryption module. The key management module, communication invocation module, and encryption / decryption module are invoked by the security monitor in the TEE or run in the first memory. The first memory is a portion of the memory in the TEE's secure world that can be accessed by programs and operating systems in the ordinary world.

[0050] Each TEE comprises an isolated secure world and a normal world, which cannot directly access each other's data. A security monitor provides a security service interface to the normal world, allowing it to access resources. When a TEE includes a security monitor, it invokes the key management module, communication module, and encryption / decryption module, enabling security checks on data during inter-TEE communication and preventing normal world programs from directly accessing secure world resources. When a TEE does not include a security monitor, the secure memory accessible to the secure world is at risk of being directly accessed by normal world programs and the operating system. By setting up a first memory area within the secure memory that can be accessed by normal world programs and the operating system, and performing security checks on inter-TEE communication data based on this special memory area, the direct access of normal world programs to secure world resources can also be prevented.

[0051] Figure 1In this system, the key management module generates keys corresponding to each TEE. Different TEEs have different keys, and these keys can be associated with the corresponding TEE's identity identifier through mapping. Optionally, since different TEEs have different identity identifiers, keys can be generated based on these identifiers. The keys generated by the key management module are stored in the memory of a secure world that cannot be accessed by programs and operating systems in the ordinary world.

[0052] The encryption / decryption module is used to encrypt specified data according to a key when the TEE generates specified data in response to a memory access instruction; to verify the integrity of the first data packet when it is received from another TEE, and to decrypt the first data packet according to the key if the first data packet is intact.

[0053] The encryption / decryption module can store one or more encryption / decryption algorithms. Each algorithm includes a corresponding function interface. Calling these interfaces within the module encrypts specified data and decrypts the first data packet. If the first data packet is incomplete, or if it cannot be decrypted using the key corresponding to the TEE module's identifier, the packet is discarded.

[0054] Optionally, integrity verification can be implemented using hash value verification: after XORing the calculated hash value with the hash value contained in the first data packet, if the result is non-zero, the integrity verification fails and the data packet is discarded; otherwise, the integrity verification passes. It is understood that other existing methods can also be used to implement data packet integrity verification.

[0055] The communication call module is used to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet.

[0056] In this configuration, the first data packet is the data packet received by the TEE, and the second data packet is the data packet to be sent. Both the first and second data packets are TEE communication data packets. By encapsulating and decrypting the first data packet to obtain the second data packet, the specified data can be transmitted to other corresponding TEEs, and the key management module and encryption / decryption module in the other TEEs can perform security verification of the data packets. Optionally, the communication calling module is used to encapsulate the encrypted data into TEE communication data packets and transmit them to the system where the corresponding other TEEs reside via Ethernet.

[0057] In this embodiment, the key management module, communication call module, and encryption / decryption module are invoked and run by the security monitor, or the methods in the key management module, communication call module, and encryption / decryption module are run through the first memory. This allows the security of data packets to be checked before executing the memory access instructions corresponding to the data packets during data communication between TEE systems. This avoids programs in the ordinary world from directly accessing resources in the secure world, improves the security of data communication when multiple TEEs are deployed in a distributed system, and is applicable to various types of TEEs.

[0058] In some of these embodiments, Figure 2 Another schematic diagram of a distributed TEE system is provided, such as Figure 2 As shown, the distributed TEE system includes a primary TEE and multiple secondary TEEs. The primary TEE is responsible for managing the interaction and security between different TEEs, and can communicate with one or more secondary TEEs via Ethernet. The architectures of the secondary TEEs can be different or the same. Each secondary TEE can be applied to different subsystems of the terminal.

[0059] In one embodiment, the first-level TEE includes a first security monitor, which is equipped with a first security check module, a first function call module, a key management module, and a communication call module. The first function call module provides a function call interface for the encryption / decryption module of the first-level TEE. The first security check module, upon receiving a first data packet transmitted from the second-level TEE, calls the encryption / decryption module of the first-level TEE through the function call interface to verify the integrity of the first data packet and, if the first data packet is intact, decrypts it according to the key.

[0060] Optionally, the first security check module obtains the integrity of the data packet from the encryption / decryption module through the first function call module, and determines whether the data packet passes the integrity check based on the function execution result and a preset standard. The first security check module can also obtain the key generated by the key management module based on the secondary TEE, and use the key as a parameter to obtain the decrypted data of the first data packet through a function in the first function call module.

[0061] Furthermore, after decrypting the first data packet, the first security check module can determine the data type based on the data packet's transmission data type, and encapsulate or transmit the data through the communication call module based on the data type. Specifically, when the data is control data from the terminal, the module analyzes whether the decrypted data is executable, considering the current execution environment context. If the data is executable, the CAN data packet containing the corresponding control command is sent to the corresponding ECU (Electronic Control Unit) via the CAN (Controller Area Network) bus. When the data is non-control data from the terminal, data reading is allowed, and the data can be encapsulated through the communication call module. In this embodiment, by using a first-level TEE equipped with a first security monitor, when the first-level TEE receives a data packet transmitted from a second-level TEE, it verifies the data packet based on the first security monitor to determine whether the data packet has been tampered with and is secure, thereby improving the security of data communication between TEEs after deploying TEEs in a distributed system.

[0062] Furthermore, in one embodiment, the communication invocation module is used to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet, including: a communication invocation module of a first-level TEE, used to encapsulate the encrypted specified data into a second data packet and transmit it to a second-level TEE through an application in the TEE; and / or, used to encapsulate the decrypted first data packet into a second data packet when the data obtained by decrypting the first data packet is non-control data.

[0063] The first data packet is the data packet received by the TEE, and the second data packet is the data packet to be sent. Both the first and second data packets are TEE communication data packets. Optionally, when the first-level TEE needs to send the data to the second-level TEE, after obtaining the data obtained by decrypting the first data packet, the first-level TEE can also encrypt the data through the encryption / decryption module, and then encapsulate the data into a TEE communication data packet.

[0064] Optionally, the TEE communication data packet encapsulated by the communication call module includes three parts: a header, a data portion, and a trailer. The header fields include, but are not limited to, the TEE Identity (TID) and data type (Type) fields of the secondary TEE to be received. The data portion fields are encrypted data, and the trailer fields are the hash values ​​of the header fields and the data portion. In this embodiment, by encapsulating the data packet through the communication call module, the secondary TEE receiving the second data packet can perform integrity verification on the second data packet.

[0065] In one embodiment, the distributed TEE system includes a normal world and a secure world that are isolated from each other. The distributed TEE system includes a first-level TEE and multiple second-level TEEs. The memory of the secure world accessible by the second-level TEE includes a first memory and a second memory. The first memory is a memory area that can be accessed by programs and operating systems in the normal world based on a preset interface. The second memory is a memory area that cannot be accessed by programs and operating systems in the normal world.

[0066] The preset interface can be the interface corresponding to the encryption / decryption module in the current secondary TEE, or it can be other pre-set interfaces; there are no restrictions here. Optionally, the key generated by the storage key management module can be stored in a second memory that cannot be accessed by the ordinary world to ensure the accuracy of data packet security verification; the secondary TEE can also store security-critical data in the second memory.

[0067] By setting up a first memory and a second memory within one or more secondary TEEs (Temporary Execution Environments) without a security monitor, the real-time performance of data processing within the secondary TEE can be improved. Therefore, in this embodiment, the secondary TEE can be located within a terminal or within one or more systems with relatively high real-time requirements. To enhance data communication security, this embodiment allocates a special area as the first memory within the secure world memory accessible to the secondary TEE. Applications and control systems in the ordinary world can access the first memory through calls from the terminal system, but cannot access the second memory, thus achieving access isolation between the ordinary world and the secondary TEE.

[0068] In one embodiment, the distributed TEE system includes a primary TEE and multiple secondary TEEs. Each secondary TEE includes a second security monitor, which is equipped with a second function call module, a key management module, and a communication call module. The second function call module includes a function call interface for an encryption / decryption module. The second function call module is used to provide the function call interface to call the encryption / decryption module of the secondary TEE to verify the integrity of a first data packet, and, if the first data packet is intact, to decrypt the first data packet according to the key, and / or to call the encryption / decryption module of the secondary TEE to encrypt specified data.

[0069] The second function call module includes function call interfaces for various functions stored in the encryption / decryption module of the current secondary TEE. A second security monitor can be set in one or more secondary TEEs. Optionally, when a secondary TEE receives a communication data packet sent by a primary TEE, it calls a function stored in the encryption / decryption module of the current secondary TEE through the second function call module, and performs integrity verification on the first data packet based on the called function. If the first data packet is intact, it obtains the key corresponding to the primary TEE stored in the key management module, and decrypts the data portion of the second data packet based on the key and the function in the encryption / decryption module. In this embodiment, by setting a second security monitor in the secondary TEE to be responsible for verifying communication data packets, data communication security is improved. The secondary TEE in this embodiment can be set within a terminal, in one or more systems with relatively low real-time requirements.

[0070] In one embodiment, the distributed TEE system includes a primary TEE and multiple secondary TEEs. Each secondary TEE includes multiple trusted operating systems, each equipped with an encryption / decryption module. Simultaneously, each secondary TEE includes a third security monitor, which contains a third function call module, a key management module, and a communication call module. The third function call module includes a function call interface for the encryption / decryption module within the current secondary TEE. This third function call module is used to call the encryption / decryption module to verify the integrity of a first data packet, and if the first data packet is intact, to decrypt it using the key, and / or to call the encryption / decryption module within the current secondary TEE to encrypt specified data.

[0071] Optionally, the multiple trusted operating systems included in the secondary TEE are trusted micro-operating systems. One or more of the multiple secondary TEEs in the distributed TEE system can be configured as the secondary TEE in this embodiment. Multiple trusted operating systems are configured to correspond to different trusted applications within the secondary TEEs.

[0072] Furthermore, in one embodiment, the multiple secondary TEEs of the distributed TEE system may include at least one of the following: a secondary TEE with a first memory and a second memory, a secondary TEE with a second security monitor, and a secondary TEE with a third security monitor. This allows the distributed TEE system to adapt to different types of TEEs while ensuring data communication security.

[0073] Based on the same inventive concept, embodiments of this application also provide an application for, for example... Figure 1The diagram illustrates a communication method based on a distributed TEE system. The solution provided by this method is similar to the implementation described above. Therefore, the specific limitations of the communication method based on the distributed TEE system in one or more method embodiments provided below can be found in the limitations of the system embodiments described above, and will not be repeated here.

[0074] In one embodiment, the communication method based on the distributed TEE system can be applied to the distributed system described in any of the above system embodiments. The distributed TEE system includes multiple TEEs. If the security world of the TEE includes a security monitor, the communication method based on the distributed TEE system in this embodiment is executed based on the security monitor. If the TEE does not include a security monitor, a first memory accessible to programs and operating systems in the ordinary world is determined in the TEE's security memory, and the communication method based on the distributed TEE system in this embodiment is executed in the first memory, including:

[0075] Upon receiving the first data packet transmitted by another TEE, the integrity of the first data packet is verified. If the first data packet is intact, the first data packet is decrypted based on the key corresponding to the other TEE, and the corresponding memory access instruction is executed based on the data obtained after decryption.

[0076] When the TEE generates specified data in response to a memory access instruction, it calls the key corresponding to the TEE to encrypt and encapsulate the specified data, and transmits the encapsulated second data packet to the corresponding other TEE and / or the corresponding electronic control unit.

[0077] Optionally, a communication method based on the distributed TEE system is executed within a terminal equipped with such a system, with the electronic control unit (ECU) serving as the control unit within the terminal. Each TEE's secure environment includes a key management module and a communication invocation module, and the TEE's trusted operating system includes an encryption / decryption module. The key management module in the distributed system generates a key corresponding to the TEE. The encryption / decryption module verifies the integrity of the first data packet and, if the first data packet is intact, invokes the key corresponding to other TEEs; or, when a TEE generates specified data in response to a memory access instruction, it invokes the key corresponding to the TEE to encrypt the specified data. The communication invocation module encapsulates the encrypted specified data and / or the decrypted first data packet into a second data packet.

[0078] Optionally, the encapsulated second data packet is transmitted to the corresponding electronic control unit via the CAN bus, or the encapsulated second data packet is transmitted to another corresponding TEE via Ethernet, or the first data packet transmitted by another TEE is received.

[0079] Furthermore, the distributed TEE system includes a primary TEE and multiple secondary TEEs. The primary TEE is responsible for managing the interaction and security between different TEEs. The primary TEE can receive the first data packet from a secondary TEE via Ethernet, or transmit a second data packet to a secondary TEE via Ethernet. Each secondary TEE can communicate with the primary TEE via Ethernet.

[0080] In this embodiment, data communication is achieved based on a TEE equipped with a security monitor or a first memory set in secure memory. This allows each TEE to perform a security check upon receiving a data packet before determining whether to execute a memory access instruction, thereby improving the security of data communication.

[0081] In one embodiment, executing a memory access instruction based on the decrypted data includes: determining whether the data obtained after decrypting the data packet is preset control data; if the data obtained after decryption is control data, then sending the decrypted data to the corresponding electronic control unit; if the data obtained after decryption is non-control data, then storing the decrypted data in the corresponding memory.

[0082] The preset control data refers to data generated based on the operation of the electronic control unit (ECU) controlling the terminal. Optionally, before sending the decrypted control data to the corresponding ECU, a security check can be performed on the decrypted data, taking into account the current execution environment context. If the security check passes, the step of sending the decrypted data to the corresponding ECU is executed.

[0083] For non-control data, the decrypted data can be stored in ordinary memory in the ordinary world, or in secure memory in the secure world. Further, in one embodiment, the distributed TEE system includes mutually isolated ordinary and secure worlds. The memory accessible in the ordinary world is ordinary memory, and the memory accessible in the secure world is secure memory. If the decrypted data is non-control data, storing it in the corresponding memory includes: if the data type determines that the decrypted data belongs to the first type of data, granting specified read permissions and storing the decrypted data in ordinary memory; if the data type determines that the decrypted data belongs to the second type of data, storing the decrypted data in secure memory.

[0084] The first type of data is data that is not strongly related to security operations, while the second type of data is data that is strongly related to terminal security operations. Storing the first type of data in ordinary memory areas can reduce the burden on the security world; storing the second type of data in secure memory areas can improve the data security of the TEE system.

[0085] Furthermore, in one embodiment, after storing the decrypted data in secure memory, the method further includes: encapsulating the decrypted data; and transmitting the encapsulated data packet to other TEEs in response to a data transmission command. Optionally, when there is a need to send the second type of data stored in the secure memory area to other subsystems, the function call interface provided by the function call module in the above-described distributed TEE system embodiment is used to call the function in the encryption / decryption module to encrypt the second type of data, and then the encrypted data is encapsulated into a TEE communication data packet through the communication call module and transmitted to other TEEs via Ethernet.

[0086] In some of these embodiments, Figure 3 A distributed TEE for deployment in smart vehicles is provided, such as Figure 3 As shown, a Level 1 TEE is deployed in the central control system of an intelligent vehicle, resulting in a Level 1 Center-TEE. The Level 1 Center-TEE is responsible for managing the interaction and security between different TEEs, and communicates with the Level 2 TEEs via Ethernet. Taking an intelligent vehicle as an example, one or more Level 2 TEEs can be set up according to application requirements. Optionally, multiple Level 2 TEEs can be set up, including subf-TEEs with high real-time requirements, subs-TEEs with low real-time requirements, and subt-TEEs designed for T-BOX (Telematics Box). The Level 2 TEEs can be applied to intelligent driving systems, real-time navigation systems, intelligent cockpit systems, T-BOXs, etc., within the intelligent vehicle. It is understood that... Figure 3 The distributed TEE shown can also be applied to other terminals besides smart cars, including but not limited to various personal computers, laptops, smartphones, tablets, IoT devices, portable wearable devices, etc.

[0087] In one embodiment, Figure 4 A schematic diagram of a Level 1 Center-TEE architecture is provided, such as... Figure 4As shown, the Level 1 Center-TEE is divided into two parts: the Normal World and the Secure World. These two worlds are isolated from each other and cannot directly access each other's data. The Normal World consists of ordinary applications (Apps) and ordinary operating systems (OS); the Secure World consists of trusted applications (Tapps), trusted operating systems (Trusted OS), and secure monitors (SMs). Correspondingly, system memory is also divided into Normal Memory and Secure Memory, which can only be accessed by programs and operating systems in their respective worlds.

[0088] In the Level 1 Center-TEE, the Security Monitor (SM) is responsible for security operations such as context switching and security checks between the secure world and the normal world. Optionally, the Security Monitor (SM) provides a security service interface to the normal world. When an App needs to access data or use security services in the secure world, the normal world switches to the secure world via the SMC (Secure Monitor Call) interface, transferring control to the SM, which then executes the corresponding security service. The TApp and Trusted OS in the secure world are responsible for executing and calling programs involving security-critical data; the App and OS in the normal world are responsible for executing and calling programs that do not involve security-critical data.

[0089] Optionally, an encryption / decryption module is added to the Trusted OS of the Level 1 Center-TEE. This module is responsible for data encryption and decryption when this TEE communicates with other TEEs. Specifically, the Enc-Dec module (encryption / decryption module) added to the Trusted OS module of the Level 1 Center-TEE includes: AES encryption algorithm (Advanced Encryption Standard), SM2 national cryptographic algorithm, SHA3 (Secure Hash Algorithm 3) hash algorithm, SM3 national cryptographic algorithm, etc.; at the same time, corresponding function interfaces tos_sm_enc, tos_sm_dec, and tos_sm_hash are added, allowing the SM of the Level 1 Center-TEE to initiate encryption / decryption operation commands and / or hash operation commands by calling the corresponding function interfaces. The corresponding function operations are actually executed in the Trusted OS, reducing the amount of code in the SM.

[0090] Optionally, the SM of the Level 1 Center-TEE corresponds to the first security monitor in the above embodiment. Based on the initial SM design of the Level 1 Center-TEE, a sub-TEE management module is added. This sub-TEE management module is responsible for communication management between different TEEs, specifically including securely generating, storing, and managing encryption / decryption keys used for communication with the Level 2 TEE (referred to as TEE communication encryption / decryption keys), calling encryption / decryption functions to perform encryption / decryption operations on data, performing security checks on data from the Level 2 TEE, and encapsulating data into TEE communication data packets.

[0091] Specifically, the sub-TEE Management module added to the SM of the Level 1 Center-TEE includes: Key Management, Enc_Dec Call, sub_TEESecurity Check, and TEE2TEE Call. The Key Management module is responsible for the secure generation, storage, and management of TEE communication encryption and decryption keys. The key generation function `Key_Gen` generates the corresponding TEE communication encryption and decryption key `TKey` based on the Level 2 TEE identity identifier `TID`, and stores and maintains a mapping table `TID_Tkey_MapTable` between `TID` and `TKey`. This mapping table is stored in a secure memory area and can only be accessed and modified by the SM (Software Management System). The Enc_Dec Call module provides calling interfaces for the encryption and decryption functions and / or hash functions of the Enc-Dec module within the Trusted OS, including calling interfaces for the `sm_tos_enc`, `sm_tos_dec`, and `sm_tos_hash` functions. The sub_TEE Security Check module is responsible for data analysis and security checks on TEE communication data packets, including integrity verification and data format checks. Integrity verification needs to be implemented in conjunction with the Enc_Dec Call module, and data analysis needs to be performed in conjunction with the current execution environment context and data content to complete security analysis. (TEE2TEE) The Call module is responsible for encapsulating the data sent to the Level 2 TEE into a TEE communication data packet. This data packet is divided into three parts: header, data, and trailer. The header fields include the Level 2 TEE identity identifier (TID) and data type (Type). The data part is the encrypted data. The trailer fields are the hash values ​​of the header fields and the data part, which are used for subsequent integrity verification.

[0092] For example, when a Level 1 TEE receives a communication data packet from a Level 2 TEE, it first performs an integrity check using the sub_TEESecurity Check module. This requires calling the sm_tos_hash function of the Enc_Dec Call module to perform a hash operation. The calculated hash value is XORed with the hash value contained in the data packet. If the result is non-zero, the integrity check fails, and the data packet is discarded. Otherwise, the integrity check passes, and the data packet has not been tampered with. The corresponding Level 2 TEE identity identifier (TID) is extracted from the communication data packet. The corresponding TEE communication encryption / decryption key is then searched in the mapping table TID_Tkey_MapTable. Using this key as a parameter, the sm_tos_dec function of the Enc_Dec Call module is called to correctly decrypt the message. Subsequent data analysis and security checks are then performed. The data type of the data packet is extracted from the communication data packet. If it belongs to non-control data such as "data collected by camera" or "data received by radar", then read-only permission is granted to the data. If it belongs to control data such as "opening the rear window" or "turning on the air conditioner", further security checks are performed. Based on the current execution environment context, it is analyzed whether the current vehicle status allows the corresponding action to be executed. If the security check passes, the CAN data packet of the corresponding control command is sent to the corresponding ECU via the CAN bus. Non-control data is divided into ordinary data and safety-critical data. For ordinary data (such as music and social communication messages), which are not strongly related to safety operations, the permission is set to non-writable, and it is directly stored in the ordinary memory area. Ordinary programs can read it but cannot modify it, reducing the burden on the security world. Ordinary programs can directly send ordinary data to the subsystem of the intelligent vehicle via Ethernet. For safety-critical data (such as vehicle environment data and vehicle status data), the data is first stored in the secure memory area. When a Level 1 Center-TEE needs to send safety-critical data to other subsystems, it uses the sm_tos_enc function of the Enc_Dec Call module to encrypt the data, and then encapsulates the encrypted data into a TEE communication data packet through the TEE2TEE Call module, and transmits it to the corresponding Level 2 TEE via Ethernet.

[0093] In one embodiment, Figure 5 A schematic diagram of a two-level subf-TEE architecture is provided, such as... Figure 5As shown, the Level 2 subf-TEE is divided into a secure world and a normal world, which are isolated from each other and cannot directly access each other's data. The normal world consists of a regular application (App) and a regular operating system (OS); the secure world consists of a trusted application (TApp), a trusted operating system (Trusted OS), a key management module (Key Management), and a TEE2TEE Call module. Since the secure world does not have a security monitor (SM), it can meet the requirements for high real-time data processing. The App and OS in the normal world are responsible for executing and calling programs that do not involve security-critical data, while the TApp and Trusted OS in the secure world are responsible for executing and calling programs that involve security-critical data.

[0094] Correspondingly, the Level 2 subf-TEE system memory is divided into ordinary memory and secure memory. Secure memory includes the first memory and the second memory described in the above embodiment, wherein the first memory is... Figure 5 The NSC (Non-Secure Callable) memory in the system is a secure memory area that can be accessed by ordinary applications through system calls.

[0095] The NSC memory region is set up because subf-TEE lacks a Security Monitor (SM) to perform security checks on access from the normal world to secure world resources. Without isolation, ordinary programs could directly access secure world resources through function calls, greatly increasing the likelihood of arbitrary access to secure memory and compromising system memory isolation. Therefore, a dedicated NSC memory region is established as a special area for ordinary programs to access secure memory data. This allows ordinary programs (App) and trusted programs (TApp) to access NSC memory and ordinary memory respectively through specific function calls. This satisfies application requirements while ensuring data security isolation.

[0096] Optionally, an encryption / decryption module is added to the Trusted OS of the Level 2 subf-TEE. This module is responsible for data encryption and decryption when this TEE communicates with other TEEs. Specifically, the Enc-Dec module (encryption / decryption module) added to the Trusted OS of the Level 2 subf-TEE includes: AES encryption algorithm, SM2 national cryptographic algorithm, SHA3 hash algorithm, etc. Corresponding function interfaces tos_app_enc, tos_app_dec, and tos_app_hash are also added, allowing ordinary world apps to call the corresponding function interfaces to initiate encryption / decryption or hash operation commands, which are then actually executed in the Trusted OS.

[0097] Optionally, two modules, Key Management and TEE2TEE Call, are added to the secure world of Level 2 subf-TEE. These modules include the secure generation, storage, and management of TEE communication encryption / decryption keys, and the encapsulation of data into TEE communication data packets. Specifically, the Key Management module is responsible for the secure generation, storage, and management of TEE communication encryption / decryption keys. The key generation function Key_Gen generates a corresponding key TKey based on the current TEE identity and stores it in a secure memory area other than NSC memory. The TEE2TEE Call module is responsible for encapsulating data sent to Level 1 Center-TEE into TEE communication data packets. This data packet consists of a header, a data portion, and a trailer. The header fields include the Level 2 TEE identity TID and the data type Type. The data portion is the encrypted data, and the trailer field is the hash value of the header fields and the data portion, used for subsequent integrity verification.

[0098] For example, when the subf-TEE receives a communication data packet from the Level 1 Center-TEE, it first uses the tos_app_hash function of the Enc-Dec module in the Trusted OS to perform an integrity check on the data packet. If the XOR result of the calculated hash value and the hash value in the data packet is not zero, that is, the data packet has been tampered with, the data packet is directly discarded. Otherwise, the integrity check passes, and then the data part of the communication data packet is decrypted using the key TKey stored in secure memory to obtain the correct data.

[0099] For example, when the subf-TEE needs to send non-control data or control commands to the Center-TEE, it first encrypts the data using the key TKey, then encapsulates it into a TEE communication data packet through the TEE2TEE Call module. The encapsulation process includes setting header information, calculating tail values, etc. Finally, the TEE communication data packet is transmitted to the Center-TEE via Ethernet.

[0100] In one embodiment, Figure 6 A schematic diagram of a two-level subs-TEE architecture is provided, such as... Figure 6As shown, the Level 2 subs-TEE is divided into two parts: the normal world and the secure world. The normal world and the secure world are isolated from each other and cannot directly access each other's data. The normal world consists of a normal application (App) and a normal operating system (OS), while the secure world consists of a trusted application (TApp), a trusted operating system (Trusted OS), and a security monitor (SM). In the Level 2 subs-TEE, the SM is responsible for context switching and security checks between the secure world and the normal world. Optionally, the SM in the Level 2 subs-TEE provides a security service interface to the normal world. When an App needs to access data or use security services in the secure world, the normal world switches to the secure world through the SMC call interface, transferring control to the SM, which then executes the corresponding security service. The App and OS in the normal world are responsible for executing and calling programs that do not involve security-critical data, while the TApp and Trusted OS in the secure world are responsible for executing and calling programs that involve security-critical data.

[0101] Correspondingly, system memory is also divided into ordinary memory and secure memory, which can only be accessed by programs and operating systems in their respective worlds.

[0102] Optionally, an encryption / decryption module is added to the Trusted OS within the Level 2 subs-TEE. This module is responsible for data encryption and decryption when this TEE communicates with other TEEs. Specifically, the Enc-Dec module added to the Trusted OS module of the Level 2 subs-TEE includes AES encryption algorithm, SM2 national cryptographic algorithm, SHA3 hash algorithm, SM3 national cryptographic algorithm, etc., and adds corresponding function interfaces tos_sm_enc, tos_sm_dec, and tos_sm_hash. This allows the SM to initiate encryption / decryption commands and / or hash operation commands by calling the corresponding function interfaces. The corresponding function operations are actually executed in the Trusted OS, reducing the amount of code in the SM.

[0103] Optionally, the SM in the Level 2 subs-TEE corresponds to the second security monitor in the above embodiment. Based on the initial SM design, three modules are added: Key Management, Enc_Dec Call, and TEE2TEE Call. The three added modules are respectively responsible for securely generating, storing, and managing TEE communication encryption and decryption keys; calling encryption and decryption functions to perform encryption and decryption operations on data; and encapsulating data into TEE communication data packets. Specifically, the Key Management module is responsible for the secure generation, storage, and management of TEE communication encryption and decryption keys. The key generation function Key_Gen generates the corresponding key TKey based on the current TEE identity and stores it in a secure memory area. The Enc_Dec Call module is responsible for providing call interfaces for the encryption and decryption functions and / or hash functions of the Enc-Dec module in Trusted OS, including the sm_tos_enc, sm_tos_dec, and sm_tos_hash function call interfaces. The TEE2TEE Call module is responsible for encapsulating the data sent to the Level 1 Center-TEE into TEE communication data packets. These data packets are divided into three parts: header, data, and trailer. The header fields include the Level 2 TEE identity TID and data type Type. The data part is the encrypted data, and the trailer fields are the hash values ​​of the header fields and the data part, which are used for subsequent integrity verification.

[0104] For example, when the subs-TEE receives a communication data packet from the Level 1 Center-TEE, it first uses the sm_tos_hash function of the Enc_Dec Call module to perform an integrity check on the data packet. If the XOR result of the calculated hash value and the hash value in the data packet is not zero, that is, the data packet has been tampered with, the data packet is directly discarded. Otherwise, the integrity check passes, and then the data part of the communication data packet is decrypted using the key TKey stored in secure memory to obtain the correct data.

[0105] When the subs-TEE needs to send non-control data or control commands to the Center-TEE, it first encrypts the data using the key TKey, then encapsulates it into a TEE communication data packet through the TEE2TEE Call module. The encapsulation process includes setting header information, calculating tail values, etc. Finally, the TEE communication data packet is transmitted to the Center-TEE via Ethernet.

[0106] In one embodiment, Figure 7 A schematic diagram of a two-level subt-TEE architecture is provided, such as... Figure 7As shown, the Level 2 subt-TEE system is divided into two parts: the ordinary world and the secure world. These two worlds are isolated from each other and cannot directly access each other's data. The ordinary world consists of ordinary applications (Apps) and ordinary operating systems (OS), while the secure world consists of trusted applications, trusted micro-operating systems (mOSs), and a security monitor (SM). Trusted applications include one or more of three types: OTApp, MoApp, and InfApp. Correspondingly, system memory is also divided into ordinary memory and secure memory, which can only be accessed by programs and operating systems in their respective worlds.

[0107] In this system, the SM (Security Management System) within the Level 2 subt-TEE is responsible for security operations such as context switching and security checks between the secure world and the normal world. Specifically, the SM in the Level 2 subt-TEE provides security service interfaces to the normal world. When an App needs to access data or use security services in the secure world, the normal world switches to the secure world through the SMC (Security Management System) interface, transferring control to the SM, which then executes the corresponding security service. The App and OS in the normal world are responsible for executing and calling programs that do not involve security-critical data. The trusted application and trusted micro-operating system (mOS) in the secure world are responsible for executing and calling programs that involve security-critical data. Corresponding mOS are designed for different types of trusted applications for management and scheduling.

[0108] Optionally, the Level 2 subt-TEE includes multiple trusted operating systems (mOS). Each mOS adds an encryption / decryption module responsible for data encryption and decryption when the corresponding trusted application communicates with other TEEs. Specifically, the Enc-Dec module added to each mOS module includes: AES encryption algorithm, SM2 national cryptographic algorithm, SHA3 hash algorithm, SM3 national cryptographic algorithm, etc. Simultaneously, corresponding function interfaces mos_sm_enc, mos_sm_dec, and mos_sm_hash are added, allowing the SM to initiate encryption / decryption commands and / or hash operation commands by calling the corresponding function interfaces. The corresponding function operations are actually executed in the mOS, reducing the amount of code in the SM.

[0109] Optionally, the SM in the Level 2 subs-TEE corresponds to the third security monitor in the above embodiments. Based on the initial SM design, three modules are added: Key Management, Enc_Dec Call, and TEE2TEE Call. The three modules are responsible for the following three functions: securely generating, storing, and managing TEE communication encryption and decryption keys; calling encryption and decryption functions to perform encryption and decryption operations on data; and encapsulating data into TEE communication data packets. Specifically, the Key Management module is responsible for the secure generation, storage, and management of TEE communication encryption and decryption keys. The key generation function Key_Gen generates the corresponding key TKey based on the current TEE identity and stores it in a secure memory area. The Enc_Dec Call module provides calling interfaces for the encryption and decryption functions and / or hash functions of the Enc-Dec module in mOS, including the sm_mos_enc, sm_mos_dec, and sm_mos_hash function calling interfaces. The TEE2TEE Call module is responsible for encapsulating the data sent to the Level 1 Center-TEE into TEE communication data packets. These data packets are divided into three parts: header, data, and trailer. The header fields include the Level 2 TEE identity TID and data type Type. The data part is the encrypted data, and the trailer fields are the hash values ​​of the header fields and the data part, used for subsequent integrity verification.

[0110] For example, when subt-TEE receives a communication data packet from Level 1 Center-TEE, it first uses the sm_mos_hash function of the Enc_Dec Call module to perform an integrity check on the data packet. If the check fails, that is, the data packet has been tampered with, the data packet is discarded directly. Otherwise, if the integrity check passes, the data portion of the communication data packet is decrypted using the key TKey stored in secure memory to obtain the correct data.

[0111] For example, when subt-TEE needs to send non-control data or control commands to Center-TEE, it first encrypts the data using the key TKey, then encapsulates it into a TEE communication data packet through the TEE2TEE Call module. The encapsulation process includes setting header information, calculating tail values, etc. Finally, the TEE communication data packet is transmitted to Center-TEE via Ethernet.

[0112] In one embodiment, based on Figure 3The distributed TEE of the intelligent vehicle shown illustrates the complete data flow process of the distributed TEE system application. Specifically, the transmission of control data and / or non-control data from the Level 2 TEE to the Level 1 Center-TEE includes: Level 2 subf-TEE transmitting control and / or non-control data to the Level 1 Center-TEE; Level 2 subs-TEE transmitting control and / or non-control data to the Level 1 Center-TEE; and Level 2 subt-TEE transmitting control and / or non-control data to the Level 1 Center-TEE.

[0113] Figure 8 A schematic diagram is provided showing how a Level 2 subf-TEE sends data to a Level 1 Center-TEE. Figure 8 Labels 1 to 15 are used to indicate the data transmission order. For example... Figure 8As shown, the trusted application TApp of subf-TEE initiates TEE communication by calling a function. TApp first transmits the data to Trusted OS. Trusted OS encrypts the data and then transmits it to the TEE2TEE Call module. The TEE2TEE Call module encapsulates the data, using the subf-TEE's identity identifier (TID) and data type as the header of the TEE communication data packet, and calculates a hash value using a hash function within Trusted OS, which is then used as the tail data of the data packet, resulting in the final TEE communication data packet. This data packet is then transmitted back to TApp via Trusted OS. TApp sends the encapsulated TEE communication data packet to the Level 1 Center-TEE via Ethernet. The Center-TEE's TApp receives the data packet and passes it to the Security Monitor SM via Trusted OS. The TEE2TEECall within the SM performs a security check via the sub_TEE Security Check module. This security check includes integrity verification and data analysis. If the check fails, the data packet is discarded. If the check passes, the security check calls the Enc_Dec Call module to decrypt the data, obtaining the correct data. If the correct data obtained is control data, such as car turning, the control command is directly transmitted to the TApp via the Trusted OS. The TApp then sends the corresponding CAN data packet to the corresponding ECU. If the correct data obtained is non-control data, such as vehicle environmental data, the data is encapsulated into a new TEE communication data packet and transmitted to the TApp via the Trusted OS. The TApp then sends the packet to other Level 2 TEEs via Ethernet. Taking a subs-TEE as an example, after receiving the TEE communication data packet, the TApp in the subs-TEE transmits it to the SM via the Trusted OS. The SM's TEE2TEE Call module decapsulates the packet and calls the Enc_Dec Call module for integrity verification and decryption to obtain the correct data. It is understood that other Level 2 TEEs can also be subf-TEEs or subt-TEEs, which will not be elaborated upon here.

[0114] Taking the requirement of "the intelligent driving system transmitting environmental data collected by the surround-view camera to the central control screen of the intelligent cockpit system" as an example, the intelligent driving system (subf-TEE) creates a trusted application TApp. TApp transmits the environmental data collected by the surround-view camera to the Trusted OS in the subf-TEE. The Trusted OS in the subf-TEE encrypts the data using a key stored in secure memory and transmits the encrypted data to the TEE2TEE Call module in the subf-TEE. The TEE2TEE Call module in the subf-TEE encapsulates the encrypted data into a TEE communication data packet. The encapsulation process includes setting header information and calculating the hash value of the header information and the data portion, which serves as the tail data of the data packet. In the subf-TEE, the TEE2TEE Call module transmits the encapsulated TEE communication data packet back to the Trusted OS. The Trusted OS then transmits the data packet back to the TApp in the subf-TEE. The TApp in the subf-TEE sends the TEE communication data packet corresponding to the environmental data collected by the surround-view camera to the central control system (Center-TEE) via Ethernet.

[0115] The TApp in the central control system receives the data packet and passes it to the Trusted OS in the Center-TEE. The Trusted OS then passes it to the SM in the Center-TEE. The TEE2TEE Call module in the sub_TEE Management module of the SM decapsulates the data packet, obtains the data of each part of the data packet, and then calls the sub_TEESecurity Check module to perform a security check on the data packet, including integrity verification and data analysis. After the security check is passed, the decrypted environmental data is encapsulated into a new TEE communication data packet. This is because the TID and TKey of the subsequent Level 2 TEE communication are different from the previous ones, so it needs to be re-encrypted and encapsulated. The TEE2TEE Call module sends the encapsulated new TEE communication data packet back to the Trusted OS in the Center-TEE. The Trusted OS passes the TEE communication data packet to the TApp in the Center-TEE, and the TApp sends it to the intelligent cockpit system (subs-TEE) via Ethernet.

[0116] After receiving the TEE communication data packet, the TApp of the intelligent cockpit system transmits the data packet to the Trusted OS of the subs-TEE. The Trusted OS then transmits it to the SM of the subs-TEE. The TEE2TEE Call module of the SM decapsulates the packet and calls the Enc_Dec Call module in the subs-TEE to perform integrity verification and decryption, successfully obtaining the environmental data collected by the surround-view camera and displaying it on the central control screen.

[0117] Figure 9 A schematic diagram is provided showing how a Level 2 Subs-TEE sends data to a Level 1 Center-TEE. Labels 15 to 30 in section 9 indicate the data transmission order. For example... Figure 9 As shown, in subs-TEE, TApp initiates TEE communication by calling a function. TApp first sends the data to Trusted OS, which then sends the data to SM. The TEE2TEE Call module in SM calls the Enc_Dec Call module to encrypt the data and calculate the hash value of the header information and the data part. The original data is then encapsulated into a TEE communication data packet, which is then sent to TApp through Trusted OS. TApp then sends the TEE communication data packet to the Level 1 Center-TEE via Ethernet.

[0118] The Center-TEE's TApp receives the data packet and passes it to the Safety Monitor (SM) via the Trusted OS. The TEE2TEE Call within the SM performs a security check via the sub_TEE Security Check module, including integrity verification and data analysis. If the check passes, the Enc_Dec Call module is invoked to decrypt the data and obtain the correct information. If the data is control data, such as opening a window, the control command is directly transmitted to the TApp via the Trusted OS, and the TApp sends the corresponding CAN data packet to the corresponding ECU. If the data is non-control data, such as driver status data, it is encapsulated into a new TEE communication data packet and transmitted to the TApp via the Trusted OS. The TApp then sends this packet via Ethernet to other Level 2 TEEs, such as the subf-TEE. Upon receiving this TEE communication data packet, the subf-TEE's TApp transmits it via the Trusted OS to the TEE2TEE Call module for decapsulation, integrity verification, and decryption to obtain the correct information.

[0119] To facilitate understanding, let's take "the driver opening the car door via the central control screen" as an example. When the driver clicks the "open car door" button on the central control screen, the intelligent cockpit system (subs-TEE) creates a trusted application TApp. TApp transmits the control data to the Trusted OS of the subs-TEE. The Trusted OS then transmits the data to the Safety Monitor SM. The SM encapsulates the data into a TEE communication data packet through the TEE2TEECall module. The encapsulation process includes setting header information, such as TID and data type Type. By calling the Enc_Dec Call module, the data is encrypted using the encryption key TKey stored in secure memory. A hash function is then called to calculate the hash value of the header and data portions, which serves as the tail data of the TEE communication data packet. The SM (Management System) sends the encapsulated TEE communication data packet back to the Trusted OS. The Trusted OS then sends the packet back to the TApp. The TApp sends the TEE communication data packet corresponding to the control command to the Central Control System (Center-TEE) via Ethernet. The TApp in the Central Control System receives the packet and passes it to the Trusted OS. The Trusted OS then passes it to the SM. The TEE2TEE Call module in the sub_TEE Management module of the SM decapsulates the packet, obtaining the data portions. The sub_TEE Security Check module is then called to perform a security check on the packet, including integrity verification and data analysis. After the security check passes, the decrypted control command is sent back to the Trusted OS. The Trusted OS then sends the control command back to the TApp. The TApp sends the CAN data packet containing the control command to the corresponding ECU via the CAN bus, and the door is successfully opened.

[0120] Figure 10 A schematic diagram is provided showing how a Level 2 subt-TEE sends data to a Level 1 Center-TEE. Labels 31 to 46 in section 10 indicate the data transmission order. For example... Figure 10 As shown, trusted applications such as OTApp and MoApp in subt-TEE initiate TEE communication by calling functions. TApp first sends the data to the corresponding mOS, and the mOS sends the data to the SM. The TEE2TEE Call module in the SM calls the Enc_Dec Call module to encrypt the data and calculate the hash value of the header information and the data part. The original data is then encapsulated into a TEE communication data packet, and the encapsulated data packet is sent back to TApp through the mOS. TApp then sends the TEE communication data packet to the Level 1 Center-TEE via Ethernet.

[0121] The Center-TEE's TApp receives the data packet and passes it to the Safety Monitor (SM) via the Center-TEE's Trusted OS. The TEE2TEE Call within the SM performs a security check via the sub_TEE Security Check module, including integrity verification and data analysis. If the check passes, the Enc_Dec Call module is called to decrypt the data and obtain the correct information. If the data is control data, such as a mobile app controlling the opening of a car door, the control command is directly transmitted to the TApp via the Trusted OS. The TApp then sends the corresponding CAN data packet to the corresponding ECU. If the data is non-control data, such as OTA (Over-the-Air Technology) update data, it is encapsulated into a new TEE communication data packet and transmitted to the TApp via the Trusted OS. The TApp then sends this packet via Ethernet to other Level 2 TEEs, such as the subs-TEE. Upon receiving this TEE communication data packet, the subs-TEE's TApp transmits it to the SM's TEE2TEE Call module via the Trusted OS for decapsulation, integrity verification, and decryption to obtain the correct data.

[0122] To facilitate understanding, let's take "remotely opening a car door via mobile phone" as an example: The MoApp in the T-Box (subt-TEE) receives a control command from the mobile phone. The MoApp transmits the "open car door" control command to mOS2, which then passes it to the SM. The TEE2TEE Call module within the SM calls the Enc_Dec Call module to encrypt the control signal using the corresponding key stored in secure memory. The encrypted data is then encapsulated into a TEE communication data packet. The encapsulation process includes setting header information and calculating the hash value of the header and data portions, which is used as the tail data of the data packet. The TEE2TEE Call module sends the encapsulated TEE communication data packet back to mOS2, which then sends it back to the MoApp. The MoApp sends this data packet via Ethernet to the central control system (Center-TEE). The TApp in the central control system receives the data packet and passes it to the Trusted OS. The Trusted OS then passes it to the SM. The TEE2TEECall module in the sub_TEE Management module of the SM decapsulates the data packet, obtaining the various data portions, and then calls the sub_TEE... The SecurityCheck module performs a security check on the data packet, including integrity verification and data analysis. After the security check is passed, the decrypted control command is sent back to Trusted OS. Trusted OS then sends it to TApp, which transmits the CAN data packet corresponding to the control command to the corresponding ECU via the CAN bus, and the door is successfully opened.

[0123] It is understood that the encryption and decryption algorithms and hash algorithms used in this technical solution can be replaced by other algorithms with the same function without affecting the overall design concept of this technical solution.

[0124] Existing technologies lack consideration for deploying TEEs in distributed systems and do not support the deployment of different TEEs in distributed systems. To address this issue, this technical solution proposes an innovative distributed TEE architecture that allows the deployment of different TEEs in different subsystems (or devices), securely isolates safety-critical tasks, and ensures secure interaction between different TEEs. This distributed TEE can be deployed in different subsystems of intelligent vehicles, effectively ensuring the safe operation of intelligent vehicles.

[0125] The distributed system in this embodiment can support distributed heterogeneous computing; it can also support different devices using different TEE architectures, and effectively ensure the communication security between different TEEs by encrypting and encapsulating data packets, thereby comprehensively ensuring the data security of the distributed system.

[0126] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0127] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0128] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described method embodiments. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0129] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0130] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A distributed TEE system, characterized in that, The distributed TEE system includes multiple TEEs. Each TEE's secure world includes a key management module and a communication invocation module. The trusted operating system of each TEE includes an encryption / decryption module. The key management module, the communication invocation module, and the encryption / decryption module are invoked by a security monitor within the TEE or run in a first memory region. The first memory region is a portion of the memory within the TEE's secure world that can be accessed by programs and operating systems in the ordinary world. Specifically, if the TEE includes a security monitor, the key management module, the communication invocation module, and the encryption / decryption module are invoked by the security monitor; if the TEE does not include a security monitor, the key management module, the communication invocation module, and the encryption / decryption module run in the first memory region. The key management module is used to generate keys corresponding to each of the TEEs; The encryption / decryption module is used to encrypt the specified data according to the key when the TEE generates specified data in response to a memory access instruction; and to verify the integrity of the first data packet when receiving a first data packet transmitted by another TEE, and to decrypt the first data packet according to the key if the first data packet is intact. The communication call module is used to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet.

2. The system according to claim 1, characterized in that, The distributed TEE system includes a primary TEE and multiple secondary TEEs. The primary TEE includes a first security monitor, which is equipped with a first security check module, a first function call module, a key management module, and a communication call module. The first function call module is used to provide the function call interface for the encryption / decryption module of the first-level TEE; The first security check module is used to, upon receiving the first data packet transmitted by the second-level TEE, call the encryption / decryption module of the first-level TEE through the function call interface to perform the steps of verifying the integrity of the first data packet, and decrypting the first data packet according to the key if the first data packet is intact.

3. The system according to claim 2, characterized in that, The communication invocation module is used to encapsulate the encrypted specified data and / or the decrypted first data packet into a second data packet, including: The communication call module of the first-level TEE is used to encapsulate the encrypted specified data into a second data packet and transmit it to the second-level TEE through the application in the TEE; and / or, is used to encapsulate the decrypted first data packet into the second data packet if the data obtained by decrypting the first data packet is non-control data.

4. The system according to claim 1, characterized in that, The distributed TEE system comprises isolated normal and secure worlds. The system includes a primary TEE and multiple secondary TEEs. The memory of the secure world accessible to the secondary TEEs includes both primary and secondary memory. The first memory is a memory region that can be accessed by programs and operating systems in the ordinary world based on a preset interface; The second memory is a memory region that cannot be accessed by programs and operating systems in the ordinary world.

5. The system according to claim 1, characterized in that, The distributed TEE system includes a primary TEE and multiple secondary TEEs. Each secondary TEE includes a second security monitor, which is equipped with a second function call module, the key management module, and the communication call module. The second function call module is used to provide a function call interface to call the encryption / decryption module of the second-level TEE to verify the integrity of the first data packet, and decrypt the first data packet according to the key if the first data packet is intact, and / or call the encryption / decryption module of the second-level TEE to encrypt the specified data.

6. The system according to claim 5, characterized in that, The distributed TEE system includes a primary TEE and multiple secondary TEEs. Each secondary TEE includes multiple trusted operating systems, and each trusted operating system is equipped with the encryption / decryption module.

7. A communication method based on a distributed TEE system, characterized in that, A distributed TEE system includes multiple TEEs. If the security world of a TEE includes a security monitor, the method is executed based on the security monitor. If the TEE does not include the security monitor, a first memory accessible to programs and operating systems in the ordinary world is determined within the security memory of the TEE, and the method is executed in the first memory. The method includes: Upon receiving the first data packet transmitted by another TEE, the integrity of the first data packet is verified. If the first data packet is intact, the first data packet is decrypted based on the key corresponding to the other TEE, and the corresponding memory access instruction is executed based on the decrypted data. When the TEE generates specified data in response to a memory access instruction, the key corresponding to the TEE is invoked to encrypt and encapsulate the specified data, and the encapsulated second data packet is transmitted to the corresponding other TEE and / or the corresponding electronic control unit.

8. The method according to claim 7, characterized in that, The execution of corresponding memory access instructions based on the decrypted data includes: Determine whether the data obtained after decrypting the data packet is preset control data; If the decrypted data is the control data, then the decrypted data is sent to the corresponding electronic control unit. If the data obtained after decryption is non-control data, then the data obtained after decryption is stored in the corresponding memory.

9. The method according to claim 8, characterized in that, The distributed TEE system includes a normal world and a secure world that are isolated from each other. The memory accessible in the normal world is ordinary memory, and the memory accessible in the secure world is secure memory. If the data obtained after decryption is non-control data, then the data obtained after decryption is stored in the corresponding memory, including: If the data obtained after decryption is determined to belong to the first type of data based on the data transmission type of the data packet, the specified data is granted read permission, and the data obtained after decryption is stored in the ordinary memory; If the data obtained after decryption is determined to belong to the second type of data based on the data transmission type of the data packet, the data obtained after decryption is stored in the secure memory.

10. The method according to claim 9, characterized in that, After storing the decrypted data in secure memory, the method further includes: Encapsulate the decrypted data; In response to a data transmission command, the encapsulated data packet is transmitted to another of the TEEs.

Images