Lightweight confidential container construction method based on hardware trusted environment

Abstract

The invention provides a lightweight confidential container construction method based on a hardware trusted environment, which belongs to the technical field of confidential containers, and comprises a shared security memory module, a shared security storage module and a system call distribution module, according to the method, a lightweight confidential container is realized by utilizing an existing open source trusted execution environment operating system (OP-TEE) on end side embedded equipment supporting an ARM TrustZone technology; through the design based on the unique identifier of the confidential container, a plurality of confidential containers are realized in the TEE, and a plurality of trusted applications in the same confidential container have fine-grained secure memory and secure storage condition sharing, so that the communication overhead among the trusted applications in the confidential containers is reduced; the secure memory and the secure storage of the confidential container are strongly isolated from the untrusted world; according to the method, the development and deployment difficulty of the security sensitive application is reduced, and the resource utilization efficiency and the system expandability are remarkably improved while the confidentiality and integrity of hardware-level data are guaranteed.

Description

Technical Field

[0001] The present invention belongs to the technical field of confidential containers, and particularly relates to a method for constructing a lightweight confidential container based on a hardware trusted environment. Background Art

[0002] With the rapid development of Internet of Things and edge computing technologies, embedded and edge devices have been widely used in fields such as intelligent manufacturing, autonomous driving, and smart healthcare. While the large-scale deployment of these devices improves real-time and local processing capabilities, they also face severe security challenges. Since edge devices are often exposed to open physical environments and are restricted by computing resources and energy consumption constraints, it is difficult to deploy complex security mechanisms, making them the main targets of threats such as side-channel attacks and malicious code injection, thereby exacerbating the risks of critical data leakage and system integrity damage.

[0003] A Trusted Execution Environment (TEE) is a heterogeneous security architecture based on hardware extensions. By constructing a software-hardware collaborative isolated execution environment, it achieves minimization of the Trusted Computing Base (TCB) and ensures the integrity of the Chain of Trust (CoT). Compared with traditional solutions that rely on software privilege control and cryptographic algorithms, TEE relies on hardware-enforced isolation mechanisms to provide code / data confidentiality, runtime integrity, and resistance to side-channel attacks within a Secure Enclave, and ensures trusted verification of the entire life cycle from loading to execution based on a dynamic measurement mechanism. This technology has become the core infrastructure supporting privacy-sensitive computing paradigms such as confidential computing.

[0004] To address security threats, Trusted Execution Environment (TEE) technology provides effective protection for sensitive computing through hardware isolation mechanisms. Currently, most mobile devices and embedded devices are equipped with hardware that supports TEE (such as ARM TrustZone). In the Internet of Things and edge computing scenarios, embedded and edge devices face severe security challenges due to their physical exposure, resource constraints, and real-time computing requirements. Such devices are restricted by low computing power and high energy consumption, making it difficult to deploy complex security protocols. They are vulnerable to physical attacks, malicious code injection, and side-channel attack threats, resulting in a significant increase in the risk of critical data leakage and system integrity damage. Although TEE technology can theoretically provide lightweight security protection for edge devices, its practical deployment still has three deficiencies: First, the development of trusted applications is difficult due to the need to use a small number of interfaces provided by the trusted execution environment, or even dedicated development tools, which leads to difficulties in development, maintenance, and migration; Second, the development of the secure world of TEE requires a customized programming model, resulting in high complexity in coordinating security functions with ordinary business logic and low development efficiency; Finally, traditional TEE technology lacks support for lightweight isolation units, making it difficult to adapt to the requirements of containerized deployment and hindering the balance between security and flexibility in resource-constrained environments.

[0005] To simplify the development and deployment of security applications and achieve system-level isolation, academia and industry have begun to explore the construction of confidential containers in the TEE environment. Confidential container technology provides stronger security protection for the application stack and its runtime environment by integrating hardware isolation and containerized encapsulation. However, existing research has mainly focused on cloud scenarios, constructing confidential containers based on solutions such as Intel SGX. However, the rich resource environment it depends on is inherently contradictory to the heterogeneity and low computing power characteristics of edge devices, resulting in difficulty in directly migrating confidential virtual machines on edge devices. Therefore, there is an urgent need to design a lightweight confidential container architecture to meet the requirements of edge devices in terms of security, resource utilization, and flexibility. Summary of the Invention

[0006] Compared with the prior art, the present invention realizes a confidential container in embedded devices or mobile devices on the edge by designing a method for constructing a lightweight confidential container based on a hardware trusted environment, simplifies the development and deployment of security applications, and achieves system-level isolation, significantly improving the usability of the trusted execution environment on the edge.

[0007] The present invention adopts the following technical solutions to solve the above problems:

[0008] A method for constructing a lightweight confidential container based on a hardware trusted environment, the method comprising the following steps:

[0009] S1: Divide the Trusted Execution Environment (TEE) and the Regular Execution Environment (REE) within the OP-TEE OS in physical memory, and communicate between the Trusted Execution Environment and the Regular Execution Environment through SMC;

[0010] S2: The Trusted Execution Environment internally supports the coexistence of multiple confidential containers. Each confidential container supports multiple Trusted Applications (TAs), and the shared resources within each confidential container are protected by the security domain where the confidential container is located;

[0011] S3: Design and implement a shared secure memory module, a shared secure storage module, and a system call distribution module. The shared secure memory and the shared secure storage provide services to Trusted Applications (TAs) in the form of system calls;

[0012] S4: Set the permissions of the Trusted Application (TA) to be readable, writable, and executable for the shared physical memory. Different confidential containers have different uses of the shared secure physical memory;

[0013] S5: Trusted Applications (TAs) within the same confidential container can share secure memory and secure storage, while Trusted Applications (TAs) in different confidential containers cannot share each other's secure memory and secure storage, and any tentative access will be intercepted by the corresponding checking mechanism.

[0014] Furthermore, in S3, the shared secure memory module is responsible for managing the shared secure memory between different Trusted Applications (TAs) within the confidential container. During the memory address mapping process of the Trusted Application (TA), the shared secure memory module will take over the address mapping process of the native OP-TEE. By modifying the memory mapping mechanism, it is ensured that within the same container, for a Trusted Application (TA), there is a virtual memory block in the mapped virtual address space that comes from the same physical memory.

[0015] Furthermore, in S3, the shared secure storage module, combined with the internal encryption and decryption module, is responsible for managing the shared secure storage between different Trusted Applications (TAs) within the confidential container. By designing a Shared File Encryption Key (SFEK) that combines the GP standard key chain and the confidential container identifier and is used for the encryption and decryption operations of the shared secure storage files, and then designing the shared secure storage module, storage sharing within the same confidential container is achieved.

[0016] Furthermore, the shared secure storage module has relevant modules on both sides of the Trusted Execution Environment (TEE) and the Regular Execution Environment (REE). On the TEE side, a shared secure storage module is designed to provide system calls for Trusted Applications (TAs). On the REE side, a shared secure storage proxy module is added to handle the system calls sent from the TEE side and implement specific file system functions.

[0017] Furthermore, in S3, the system call distribution module is responsible for handling the system calls of the shared secure memory module and the shared secure storage module. By combining the designed Secret Container Unique Identification Code (SID), a security domain is divided on the TEE side of OP-TEE. Then, the secret container function is implemented through domain control means to ensure its security.

[0018] Furthermore, the shared secure memory module and the shared secure storage module are respectively connected to the system call processing module. The system call processing module is connected to the secret container system call interface, and the secret container system call interface is respectively connected to different Trusted Applications (TAs).

[0019] Furthermore, an OP-TEE driver is provided inside the Regular Execution Environment (REE). The OP-TEE driver is sequentially connected to the TEE Supplicant daemon process and the shared secure storage proxy module, and the shared secure storage proxy module is finally connected to the Linux file system.

[0020] Furthermore, in addition to being implemented in the OP-TEE system, the secret container also retains the design of OP-TEE in terms of strong isolation of Trusted Applications (TAs), and Trusted Applications (TAs) can run normally outside the secret container.

[0021] Furthermore, the Trusted Applications (TAs) inside the secret container can also use the services provided by the native OP-TEE and have exclusive secure storage files.

[0022] Furthermore, the modules designed and implemented by this method are supplements and extensions of the native OP-TEE mechanism and do not conflict with the modules in the native OP-TEE.

[0023] The beneficial effects of the present invention are as follows:

[0024] 1. The present invention implements multiple confidential containers on the TEE side of the ARM TrustZone device at the edge side. The trusted applications (TAs) inside the confidential containers support security policies of conditional sharing of memory and storage and mutual isolation between confidential containers. Through the integration of hardware isolation and containerized encapsulation, system-level protection for the entire life cycle of the application stack is achieved, simplifying the development and deployment difficulties of security applications, optimizing the isolation granularity, reconstructing the trust transfer mechanism, and streamlining the runtime overhead, realizing the collaborative optimization of security protection intensity and resource utilization efficiency, and balancing the ease of use and security of the trusted execution environment.

[0025] 2. In the native OP-TEE, the available memory address spaces of different trusted applications (TAs) are isolated from each other. The isolation mechanism is supported by the page table mechanism, and no shared memory area is designed. The native design mechanism of TrustZone requires world switching for communication between TAs, resulting in a large performance overhead. To optimize this problem, in the implemented confidential container, a shared memory mechanism is designed and implemented for TAs that need to communicate frequently. The shared secure memory mechanism is implemented through the shared secure memory module. By using the native design mechanism of OP-TEE, there is a reserved memory between the kernel and the RAM for TAs in the physical memory that allows users to use it themselves. This method modifies the partitioning of the physical address of this reserved memory for shared secure memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the specific embodiments of the present invention, the drawings required for the description of the specific embodiments will be briefly introduced below. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0027] Figure 1 It is the overall structure diagram of the confidential container of the present invention;

[0028] Figure 2 It is the schematic diagram of the memory layout of the confidential container of the present invention;

[0029] Figure 3 It is the flowchart of the shared secure memory mapping of the present invention;

[0030] Figure 4 It is the generation process of the shared secure storage key chain of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] To enable those skilled in the art to better understand the technical solutions of the present invention, the present invention will be described in detail below with reference to the drawings and specific embodiments.

[0032] The present invention discloses a method for constructing a lightweight confidential container based on a hardware trusted environment. This method utilizes the existing open-source trusted execution environment operating system OP-TEE (Open Source Project Trusted Execution Environment) on end-side embedded devices that support the ARM TrustZone technology to implement a lightweight confidential container. Through the design based on the unique identifier of the confidential container, multiple security domains for the confidential containers are partitioned within TrustZone; furthermore, it is realized that multiple trusted applications within the same confidential container have fine-grained secure memory and secure storage sharing, and the strong isolation state of the trusted execution environment is still maintained in the secure memory and secure storage of the confidential container.

[0033] The present invention includes three parts, specifically: a shared secure memory module, a shared secure storage module, and a system call distribution module. The present invention combines the confidential container with the security domain, realizes the security policy of internal sharing within the confidential container, isolation between confidential containers, and isolation between the inside and outside of the confidential container, reduces the communication overhead between trusted applications, and balances the usability and security of the trusted execution environment.

[0034] Embodiment 1

[0035] As Figure 1 shown, the method for constructing the confidential container of the present invention includes the following steps:

[0036] S1: Partition a trusted execution environment (TEE) and a normal execution environment (REE) in the OP-TEE OS in physical memory, and the communication between the trusted execution environment and the normal execution environment is carried out through SMC.

[0037] There is an OP-TEE driver inside the normal execution environment (REE), and the OP-TEE driver is sequentially connected to a TEESupplicant daemon process and a shared secure storage proxy module, and the shared secure storage proxy module is finally connected to the Linux file system.

[0038] S2: The trusted execution environment internally supports the coexistence of multiple confidential containers, each confidential container supports multiple trusted applications (TAs), and the shared resources within each confidential container are protected by the security domain where the confidential container is located.

[0039] S3: Design and implement a shared secure memory module, a shared secure storage module, and a system call distribution module, and the shared secure memory and shared secure storage provide services to trusted applications (TAs) in the form of system calls.

[0040] The shared secure memory module and the shared secure storage module are respectively connected to the system call processing module. The system call processing module is connected to the confidential container system call interface, and the confidential container system call interface is respectively connected to different trusted applications (TAs).

[0041] The shared secure memory module is responsible for managing the shared secure memory among different trusted applications (TAs) within the confidential container. During the memory address mapping process of the trusted application (TA), the shared secure memory module will take over the address mapping process of the native OP-TEE. By modifying the memory mapping mechanism, it is achieved that for the trusted applications (TAs) within the same container, there is a virtual memory block within the mapped virtual address space that comes from the same physical memory.

[0042] The shared secure storage module, in combination with the internal encryption and decryption module, is responsible for managing the shared secure storage among different trusted applications (TAs) within the confidential container. By designing a shared file encryption key (SFEK) that combines the GP standard key chain and the confidential container identifier and is used for the encryption and decryption operations of the shared secure storage files, and then designing the shared secure storage module, the storage sharing within the same confidential container is realized.

[0043] The shared secure storage module has relevant modules on both sides of the trusted execution environment (TEE) and the normal execution environment (REE). On the TEE side, the shared secure storage module is designed to provide system calls for the TA. On the REE side, a shared secure storage proxy module is added to handle the system calls sent from the TEE side and implement the specific file system functions.

[0044] The system call distribution module is responsible for processing the system calls of the shared secure memory module and the shared secure storage module. By combining the designed unique identification code of the confidential container (Shared ID, SID), a security domain is divided on the TEE side of OPTEE. Then, the confidential container function is realized through domain control means and its security is ensured.

[0045] S4: The permissions of the trusted application (TA) are set to be readable, writable, and executable for the shared physical memory. Different confidential containers have different usages of the shared secure physical memory.

[0046] S5: The trusted applications (TAs) within the same confidential container can share the secure memory and the shared secure storage. The trusted applications (TAs) between different confidential containers cannot share each other's secure memory and secure storage, and any attempted access will be intercepted by the corresponding check mechanism.

[0047] It should be noted that in addition to being implemented in the OP-TEE system, the confidential container retains the design of OP-TEE in terms of strong isolation of TAs. TAs can run normally outside the confidential container; TAs inside the confidential container can also use the services provided by the native OP-TEE and have exclusive secure storage files. The modules designed and implemented by this method are supplements and extensions of the native OP-TEE mechanism and do not conflict with the modules in the native OP-TEE.

[0048] Embodiment 2

[0049] As a preferred embodiment, this embodiment further defines the shared secure memory module, the shared secure storage module, and the system call distribution module, and the remaining technical features are the same as those in Embodiment 1.

[0050] This method realizes the support for multiple confidential containers to exist simultaneously on the TEE side of OP-TEE, and within the confidential container, it can support the secure memory and shared secure storage of multiple TAs. The shared resources within each confidential container are protected by the security domain where the confidential container is located. As Figure 1 shown, there are two TAs within the confidential container, and they can share secure memory and shared secure storage, while TAs between different confidential containers cannot share each other's secure memory and secure storage, and any tentative access will be intercepted by the corresponding checking mechanism.

[0051] In addition to implementing the confidential container in the OP-TEE system, this method retains the design of OP-TEE in terms of strong isolation of TAs. For example, TAs can run normally outside the confidential container. Similarly, TAs inside the confidential container can also use the services provided by the native OP-TEE. For example, TAs inside the confidential container can still use the original secure storage mechanism and have exclusive secure storage files. The modules designed and implemented by this method are supplements and extensions of the native OP-TEE mechanism and do not conflict with the modules in the native OP-TEE.

[0052] In the native OP-TEE, the available memory address spaces of different trusted applications (TAs) are isolated from each other. The isolation mechanism is supported by the page table mechanism, and no shared memory area is designed. The native design mechanism of TrustZone requires world switching for communication between TAs, which has a relatively large performance overhead. To optimize this problem, within the implemented confidential container, a shared memory mechanism is designed and implemented for TAs that need to communicate frequently. The shared secure memory mechanism is implemented through the shared secure memory module; by using the native design mechanism of OP-TEE, there is a reserved memory area between the kernel and the RAM used for TAs in physical memory that allows users to use it themselves. This method modifies the division of the physical address of this reserved memory for shared secure memory.

[0053] OP-TEE strictly differentiates the types of secure memory. Therefore, in this method, the TA permissions within the confidential container are set to have read, write, and execute permissions for the shared physical memory. During the TA memory address mapping process, the shared secure memory module will take over the address mapping process of the native OP-TEE. By modifying the memory mapping mechanism, it is achieved that for the TA within the same container, there is a virtual memory within the mapped virtual address space that comes from the same physical memory.

[0054] In this method, the size of the shared physical memory is statically set to 0x1000, which is 4KB. This design is considered for compatibility and efficiency. Since the environment used by OP-TEE may be a 32-bit system, when the page table mechanism is enabled, the standard size of a page is 4KB. In this case, the size of the shared physical memory is one page size, and at this time, memory mapping can be directly page-aligned to improve the efficiency of memory mapping.

[0055] As Figure 2 shown, for the TA within the confidential container, such as the two TAs in the confidential container, there is a mapping in their virtual address spaces that comes from the same physical memory. For TA1, it can indirectly access the shared secure memory in the virtual address space of TA2 by accessing the shared secure memory, but TA1 cannot access other virtual address spaces of TA2.

[0056] For different confidential containers, they respectively use different shared secure physical memories. There is a one-to-one correspondence between the confidential container and the shared secure physical memory. This method designs a Key-Value type correspondence mechanism, sets the unique identifier of the confidential container as the Key, and the starting address of the shared secure physical memory as the Value, and stores it in the OP-TEE OS in the form of a global linked list. Therefore, the TA in the confidential container cannot access the address space of the TA in other containers across containers.

[0057] The specific process of shared secure memory allocation for TA is as Figure 3 shown: First, the first TA in the confidential container that needs to load the dynamic physical address executes to open a session. During the process of opening the session, it judges whether this TA is within a confidential container by passing in parameters. If it is not within a confidential container, it executes the normal memory mapping process of the original OP-TEE. If this TA is in a confidential container, then it judges whether the physical memory corresponding to the unique identifier of this confidential container exists (that is, whether this TA is the first TA loaded into the TEE within this confidential container) by passing in the unique identifier of the confidential container. If it exists, it directly uses the already allocated physical memory to establish the mapping relationship between the physical memory and the virtual memory. If it does not exist, it first performs the physical memory allocation operation, and after the allocation is completed, it establishes the mapping relationship of the physical memory, and finally completes the loading.

[0058] Regarding the setting of the release process of shared secure memory, since the life cycle of the secure physical memory for sharing exists throughout the life cycle of the entire confidential container, after being allocated for the first use, it will not be released until the TA inside the confidential container finishes using it for the last time. Therefore, the shared memory module sets a reference count for each piece of secure physical memory used for sharing. If it is released, the reference count will be decreased by one. If the reference count has been decreased to zero, then before the last TA of this container exits, when the release function is called, OP-TEE OS will release the physical memory corresponding to this confidential container.

[0059] To implement the shared secure storage of TAs inside the confidential container, this method first designs a Shared File Encrypt Key (SFEK) that combines the GP standard key chain and the confidential container identifier, and uses it for the encryption and decryption operations of the files for shared secure storage; then designs a shared secure storage module to achieve storage sharing inside the same confidential container.

[0060] The design of the shared file encryption key is as follows:

[0061] The Global Platform (GP) standard organization stipulates that a TEE without its own file system can rely on the file system of the normal world, but it needs to use cryptographic algorithms to ensure security, and the securely stored files should be bound to the device. The solution adopted by the native OP-TEE is to build a key chain, add information such as the hardware identifier and chip ID into the key chain, and finally generate the key for secure storage. Therefore, combining the original OP-TEE solution, the generation process of the shared file encryption key designed in this invention is as Figure 4 shown.

[0062] In the keychain, the key related to the hardware is the Hardware Secure Storage Key (HSSK), which is generated by the Hardware Unique Key (HUK), the Chip Identification (ChipID), and the Container Secure Key (CSK). The HUK is written by the manufacturer into the coprocessor or other hardware when the device leaves the factory and can only be read on the TEE side. The ChipID is also written by the chip manufacturer into the hardware at the time of factory shipment. The above two hardware identifiers are guaranteed to be unique by the manufacturer and cannot be changed on the hardware. The CSK is the unique identifier for the confidential container-related information designed for secure storage in the design solution. This key can be specified by the developer himself, which is a compatibility consideration for the actual usage scenario. This design can ensure that each user and each manufacturer can specify a part of the keychain by themselves to prevent brute-force collisions. The calculation process of HSSK is as follows:

[0063] HSSK = HMAC SHA256 (HUK, ChipID || CSK)

[0064] HMAC SHA256 refers to the Hash-based Message Authentication Code, which uses the SHA256 algorithm to generate an irreversible ciphertext result. The HSSK will be uniquely bound to the device and the version of the confidential container solution used.

[0065] STSK = HMAC SHA256 (SID, HSSK)

[0066] The SID is the unique identifier for the confidential container used for shared secure storage, and together with the HSSK, it generates the Shared TA Storage Key (STSK).

[0067] SFEK = AES_CBC(STSK)

[0068] To further ensure security, the STSK is encrypted using the AES CBC algorithm to obtain the final Shared File Encrypt Key (SFEK), which will ultimately be used for the encryption and decryption operations of shared secure storage files.

[0069] The design of the shared secure storage module is as follows:

[0070] Since the file system of OP-TEE depends on REE, according to the interaction logic between the TEE side and the REE side, there are related modules on both the TEE side and the REE side in the shared secure storage module, such as Figure 1 As shown in ,

[0071] : On the TEE side, a shared secure storage module is designed to be responsible for providing system calls for TAs; on the REE side, a shared secure storage proxy module is added to be responsible for processing the system calls sent by the TEE side to implement specific file system functions.

[0071] Inside the shared secure storage module, an encryption and decryption module is designed to be responsible for providing key chain generation functions, key distribution and management, and encryption and decryption algorithms. The AES algorithm is implemented in the encryption and decryption module, and other cryptographic algorithm interfaces provided in OP-TEE can also be docked, such as SM2, SM3, SM4 and other algorithms.

[0072] The shared secure storage module is located in the OP-TEE OS and implements basic file system operations, specifically including functions such as opening, closing, reading, and writing shared secure storage files. The above functions are provided to the TAs in the confidential container in the form of system calls. After receiving the system call, OP-TEE OS will judge whether encryption or decryption operations need to be called in the shared secure storage module. If so, corresponding processing will be carried out. After the processing is completed or no encryption and decryption operations are required, an RPC request will be directly initiated. Through the OP-TEE driver, the file operations on the TEE side will ultimately be sent to the REE side through a remote system call.

[0073] The shared secure storage proxy module depends on the OP-TEE client existing on the REE side. The OP-TEE client contains the TEE Supplicant daemon process. The daemon process will continuously listen for RPC requests from the TEE side. After receiving the RPC request for shared secure storage, the TEE Supplicant daemon process will distribute it to the shared secure storage proxy module. The shared secure storage proxy module will further call the Linux file system service according to the system call number in the shared secure storage; all relevant data is transmitted and stored in ciphertext on the REE side. When the Linux file system service finishes processing, the processing result will be returned in the form of a function return value or a function parameter. When returning to the shared secure storage module, it will be judged again whether encryption and decryption operations are required, and finally returned to the TA inside the confidential container; to further ensure the security of the confidential container, the shared secure storage file mechanism does not set permission control, soft link and other operations on the REE side. The permissions directly belong to the TEE Supplicant daemon process or the root permission on the REE side, and other low-privilege users cannot perform file system operations on the shared secure storage files.

[0074] To handle system calls originating from shared secure memory modules and shared secure storage modules, an invention designs and implements a system call dispatching module. This module takes over system call requests and dynamically determines whether they are specific to confidential containers (such as shared memory / storage operations). To avoid coupling between modules and the security impact on code design, the module only designs necessary system calls and optimizes them through measures such as streamlining interface parameters and solidifying call paths to minimize the complexity of the TCB. A security verification mechanism is designed to strictly limit system calls to serving trusted applications within legitimate confidential containers, further ensuring container security while implementing confidential container function calls. The newly designed system calls of this invention are shown in the following table:

[0075] Function User-mode system call Implementation within OP-TEE OS Obtain the shared secure memory address TEE_GET_SHARED_VA _utee_get_shared_va Release the shared secure physical memory TEE_FREE_SHARED_PA _utee_free_shared_pa Open the shared secure storage file TEE_TCON_OPEN _utee_tcon_open Close the shared secure storage file TEE_TCON_CLOSE _utee_tcon_close Read the shared secure storage file TEE_TCON_READ _utee_tcon_read Write to the shared secure storage file TEE_TCON_WRITE _utee_tcon_write

[0076] All system calls implemented in this invention are equipped with a security domain check mechanism. The system call will determine whether the TA that calls it is inside a confidential container. If the TA makes an incorrect access, such as cross-container access, the system call will not be executed and will directly return an error value. The system calls implemented by this module only provide services to TAs inside the confidential container. The security domain check for system calls related to shared secure memory is guaranteed by the hardware MMU, which obtains the mapped address of physical memory in the virtual address space. The user-state address exclusive to a TA cannot be obtained by other TAs. For system calls related to shared secure storage, the incoming SID parameter will be checked. If the incoming SID value is incorrect, an error value will be directly returned and no further execution will occur.

[0077] The above has described this invention in detail through embodiments, but the content is only the preferred embodiment of this invention and cannot be considered as limiting the scope of implementation of this invention. All equivalent changes and improvements made according to the scope of this invention's application should still fall within the scope covered by this invention's patent.

Claims

1. A method for constructing a lightweight confidential container based on a hardware trusted environment, characterized in that: The method comprises the following steps: S1: The OP-TEE OS in the physical memory is divided into a trusted execution environment (TEE) and a normal execution environment (REE), and the trusted execution environment and the normal execution environment communicate with each other through the SMC; S2: The trusted execution environment (TEE) supports the coexistence of multiple confidential containers, each of which supports multiple trusted applications (TAs), and the shared resources in each confidential container are protected by the security domain where the confidential container is located; S3: Design and implement a shared secure memory module, a shared secure storage module, and a system call distribution module. The shared secure memory and shared secure storage provide services to the trusted application (TA) in the form of system calls. S4: The trusted application (TA) permission is set to read, write and execute permissions on the shared physical memory, and different confidential containers have different shared secure physical memory usages; S5: Trusted applications (TA) within the same confidential container can share secure memory and shared secure storage, but trusted applications (TA) between different confidential containers cannot share each other's secure memory and secure storage, and any attempted access will be intercepted by the corresponding inspection mechanism.

2. According to claim 1, a method for constructing a lightweight confidential container based on a hardware trusted environment is characterized in that: In S3, the shared secure memory module is responsible for managing the shared secure memory between different trusted applications (TA) in the confidential container. During the memory address mapping process of the trusted application (TA), the shared secure memory module will take over the address mapping process of the native OP-TEE, and by modifying the memory mapping mechanism, the trusted application (TA) in the same container is realized, and the mapped virtual address space has a virtual memory from the same physical memory.

3. According to claim 1, a method for constructing a lightweight confidential container based on a hardware trusted environment is characterized in that: In S3, the shared secure storage module is combined with the internal encryption and decryption module to manage the shared secure storage between different trusted applications (TA) in the confidential container. By designing a shared file encryption key (SFEK) that combines the GP standard key chain and the confidential container identifier, and using it for encryption and decryption operations of shared secure storage files, a shared secure storage module is then designed to achieve storage sharing within the same confidential container.

4. According to claim 3, a method for constructing a lightweight confidential container based on a hardware trusted environment is characterized in that: The shared secure storage module has related modules on both the trusted execution environment (TEE) and the normal execution environment (REE). On the trusted execution environment (TEE) side, a shared secure storage module is designed to provide system calls for trusted applications (TA). On the REE side, a shared secure storage agent module is added to process the system calls sent by the TEE side and implement specific file system functions.

5. According to claim 1, a method for constructing a lightweight confidential container based on a hardware trusted environment is characterized in that: In S3, the system call distribution module is responsible for processing the system calls of the shared secure memory module and the shared secure storage module, and by combining the designed unique identification code (SID) of the confidential container, divides the security domain on the TEE side of OP-TEE, and then implements the confidential container function and ensures its security through domain control.

6. A method for constructing a lightweight confidential container based on a hardware trusted environment according to any one of claims 1 to 5, characterized in that: The shared secure memory module and the shared secure storage module are respectively connected to a system call processing module, the system call processing module is connected to a confidential container system call interface, and the confidential container system call interface is respectively connected to different trusted applications (TA).

7. The method for constructing a lightweight confidential container based on a hardware trusted environment according to claim 1, characterized in that: An OP-TEE driver is provided inside the common execution environment (REE), and the OP-TEE driver is sequentially connected to the TEE Supplicant daemon and the shared secure storage proxy module, and the shared secure storage proxy module is finally connected to the Linux file system.

8. The method for constructing a lightweight confidential container based on a hardware trusted environment according to claim 1, characterized in that: In addition to being implemented in the OP-TEE system, the confidential container also retains OP-TEE's design for strong TA isolation, and the trusted application (TA) can run normally outside the confidential container.

9. The method for constructing a lightweight confidential container based on a hardware trusted environment according to claim 1, characterized in that: The trusted application (TA) inside the confidential container can also use the services provided by the native OP-TEE and have exclusive secure storage files.

10. The method for constructing a lightweight confidential container based on a hardware trusted environment according to claim 1, characterized in that: The module designed and implemented by this method is a supplement and extension of the native OP-TEE mechanism and does not conflict with the modules in the native OP-TEE.

Images