Trusted execution environment access control method and device, vehicle, and storage medium

Abstract

Embodiments of the present application provide a trusted execution environment (TEE) access control method and device, a vehicle, and a storage medium. The method comprises: by means of a TEE proxy isolation layer and on the basis of an interface of a preset format, receiving a TEE access request of a target client application in at least one REE; on the basis of the TEE access request, determining a target security service corresponding to the TEE access request from among at least one target security service in the TEE proxy isolation layer; determining a target conversion interface corresponding to the target security service, and performing format conversion on the TEE access request on the basis of the target conversion interface to obtain a converted TEE access request; and sending the converted TEE access request to a target TEE among at least one TEE, wherein the target TEE is a TEE where a target trusted application corresponding to the target security service is located.

Description

Trusted execution environment access control method, device, vehicle and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on June 25, 2023, with application number 202310758048.8, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of information security technology, for example, to a trusted execution environment access control method, device, vehicle and storage medium. Background Art

[0003] In application scenarios where security and openness coexist, two complete execution environments, a Rich Execution Environment (REE) and a Trusted Execution Environment (TEE), are typically established on a single device based on chip-level isolation. Ordinary applications or client applications in the REE and trusted applications in the TEE can interact and collaborate in real time to form a complete application.

[0004] However, during the implementation of this application, the applicant discovered that there are at least the following problems in the relevant technology: the application implementation on the REE side is heavily dependent on the design mechanism of the security architecture on the TEE side. When the chip platform migration occurs, the change of the TEE architecture causes the REE side application to need to be reconstructed to adapt to the new TEE architecture, which is labor-intensive and inefficient.

[0005] Summary of the Invention

[0006] Embodiments of the present application provide a trusted execution environment access control method, device, vehicle, and storage medium to reduce application development workload and improve efficiency in platform migration scenarios.

[0007] In a first aspect, an embodiment of the present application provides a trusted execution environment access control method, which is applied to a hardware platform, wherein the hardware platform includes at least one rich execution environment (REE) and at least one trusted execution environment (TEE), and the at least one rich execution environment (REE) is connected to the at least one TEE through a TEE proxy isolation layer. The method includes:

[0008] Receiving, through the TEE proxy isolation layer, a TEE access request of a target client application in the at least one REE based on an interface in a preset format;

[0009] Determine, according to the TEE access request, a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer;

[0010] Determine a target conversion interface corresponding to the target security service, and convert the format of the TEE access request based on the target conversion interface to obtain a converted TEE access request;

[0011] The converted TEE access request is sent to a target TEE among the at least one TEE; the target TEE is the TEE where the target trusted application corresponding to the target security service is located.

[0012] In a second aspect, an embodiment of the present application provides a trusted execution environment access control device, including:

[0013] a receiving module configured to receive a TEE access request from a target client application in the at least one REE through the TEE proxy isolation layer;

[0014] a determination module, configured to determine, according to the TEE access request, a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer;

[0015] a conversion module configured to determine a target conversion interface corresponding to the target security service, and convert the format of the TEE access request based on the target conversion interface to obtain a converted TEE access request;

[0016] A sending module is configured to send the converted TEE access request to a target TEE in the at least one TEE; the target TEE is the TEE where the target trusted application corresponding to the target security service is located.

[0017] In a third aspect, an embodiment of the present application provides a trusted execution environment access control device, comprising: at least one processor and a memory;

[0018] The memory stores computer-executable instructions;

[0019] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method of the first aspect and various possible designs of the first aspect.

[0020] In a fourth aspect, an embodiment of the present application provides a vehicle, including equipment as in the third aspect and various possible designs of the third aspect.

[0021] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the method of the first aspect and various possible designs of the first aspect are implemented.

[0022] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the method of the first aspect and various possible designs of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] FIG1 is a system architecture diagram of a system having both REE and TEE provided by the related art;

[0024] FIG2 is a flow chart of a first embodiment of a trusted execution environment access control method provided by the present application;

[0025] FIG3 a is a first structural diagram of a TEE proxy isolation layer provided in an embodiment of the present application;

[0026] FIG3 b is a second structural diagram of the TEE proxy isolation layer provided in an embodiment of the present application;

[0027] FIG3 c is a third structural diagram of the TEE proxy isolation layer provided in an embodiment of the present application;

[0028] FIG4 is a second flow chart of a trusted execution environment access control method provided in an embodiment of the present application;

[0029] FIG5 is a schematic diagram of the structure of a trusted execution environment access control device provided in an embodiment of the present application;

[0030] FIG6 is a schematic diagram of the hardware structure of a trusted execution environment access control device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by multiple parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0032] It should be noted that the trusted execution environment access control method and device provided in this application can be used in the field of information security, and can also be used in any field other than the field of information security. The application field of the trusted execution environment access control method and device provided in this application is not limited.

[0033] In application scenarios where security and openness coexist, two complete execution environments are typically established on a single chip based on chip-level isolation. One environment, defined as the Rich Execution Environment (REE), handles services requiring high functionality and openness; the other, defined as the Trusted Execution Environment (TEE), handles services requiring high security and privacy. The two execution environments coexist on a single chip, with the central processing unit (CPU), memory, peripherals, and other resources required for their operation strictly isolated based on chip-level security mechanisms. The Trusted Execution Environment (TEE) has higher execution privileges. Standard applications or custom applications (CAs) in the Rich Execution Environment (REE) and trusted applications (TAs) in the Trusted Execution Environment (TEE) can interact and collaborate in real time to form a complete application. Figure 1 shows the system architecture of a system with both REEs and TEEs, as provided by related technologies. As shown in Figure 1, the Rich Execution Environment (REE) and the Trusted Execution Environment (TEE) are built on the same hardware platform. Through hardware isolation, a secure channel is established between the REE and TEE for information transmission.

[0034] However, this application's research has found that the related art architecture shown in Figure 1 may encounter at least the following problems and shortcomings: First, the related art architecture lacks a universal TEE construction method and interface. Although the Global Platform (GP), the standard setter for TEEs, has established numerous standards and specifications, at the interface level, major vendors implement these interfaces in varying ways, resulting in significant fragmentation. Furthermore, for security reasons, the code is largely closed-source, making it impossible to establish a unified interface for promotion and requiring customization. Second, to accommodate different TEE implementations, corresponding extension applications are very discrete. Furthermore, when used, TEEs based on different chip architectures (such as ARM's Trust Zone and Intel SGX) are also incompatible, requiring developers to refactor existing program code and separate it into trusted and untrusted parts, a significant engineering effort. Consequently, when migrating chip platforms, a significant amount of REE-side application porting work will be required. Third, the related art architecture is not compatible with scenarios where multiple different TEE architectures coexist. REE-side application implementation is heavily dependent on the design mechanisms of the TEE's security architecture. Fourth, if a new TEE architecture solution emerges in the future, the software on the REE side will have to face the problem of demolition and reconstruction, which will result in huge changes and a huge impact, which is not conducive to the development of the software ecosystem.

[0035] To address the aforementioned technical issues, this research has discovered that a TEE proxy isolation layer (TEE Proxy) can be added between the REE and TEE to provide isolation, and by increasing data interface conversion and protocol adaptation, a solution can be implemented to support multiple heterogeneous chip trusted execution environments. This brings at least the following benefits: First, it can provide a standardized application interface for user programs on the REE side. The TEE Proxy will shield the software implementation differences caused by different hardware architectures on the TEE side (such as ARM Trust Zone, Intel SGX, AMD SEV, RISC-V MultiZone, etc.). Second, because platform differences are shielded by the TEE Proxy, REE software can be easily ported across platforms, achieving multi-platform compatibility. Third, through the unified management of the TEE Proxy, a single-chip, multi-TEE heterogeneous mode can be supported, which is more conducive to the combined use of multiple trusted execution environments and enriches the scalability of applications. Fourth, even if new TEE hardware architecture designs emerge in the future, the design of the original REE software will not be affected. This part of the work will be uniformly adapted by the TEE Proxy, greatly reducing the software development workload. Based on this, an embodiment of the present application provides a trusted execution environment access control method.

[0036] The following embodiments are used to describe the technical solution of the present application in detail. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail.

[0037] Figure 2 is a flow chart of a trusted execution environment access control method provided in an embodiment of the present application. As shown in Figure 2, the method is applied to a hardware platform, the hardware platform including at least one rich execution environment (REE) and at least one trusted execution environment (TEE), the at least one rich execution environment (REE) being connected to the at least one TEE via a TEE proxy isolation layer, and the method comprising:

[0038] 201. Receive a TEE access request of a target client application in the at least one REE through an interface in a preset format of the TEE proxy isolation layer.

[0039] The execution entities of this embodiment are a hardware platform and a terminal device including the hardware platform. For example, the hardware platform can be a chip obtained by packaging core dies of multiple chips (such as ARM dies and AMD dies), and the terminal device can be a vehicle, mobile phone, computer, tablet computer, or other device that uses the above hardware platform.

[0040] In this embodiment, with the development of the application ecosystem and the advancement of related technologies, more and more security-related applications have emerged, and the software call interfaces have become more diverse. At the same time, this has also provided many malware with corresponding attack opportunities and vulnerabilities. Therefore, it is necessary to design a unified interface (pre-set format interface) for all supported trusted services in the TEE proxy isolation layer (TEE Proxy), so as to apply it to multiple CA calls in the REE, such as biometric information recognition, password authentication, etc. The advantage of this is that all interfaces are treated uniformly, so that the CA on the REE side only needs to comply with the interface specification design, without having to worry about the actual hardware platform's TEE architecture, the corresponding TEE operating system (OS) provided by the software interface, etc. In this design mode, the TEE Proxy will internally adapt to the implementation of various different TEEs and TEE operating systems, and there is no need to readjust the CA on the REE side to adapt to the new TEE.

[0041] In this embodiment, a TEE proxy isolation layer can be constructed. There are multiple ways to construct the TEE proxy isolation layer. The following exemplifies three of the construction methods with reference to Figures 3a to 3c.

[0042] In one implementation, if the resource environment is relatively abundant, the TEE proxy isolation layer can be constructed based on a virtual machine. For example, a new REE can be constructed based on the virtual machine, and the TEE proxy isolation layer can be constructed in the new REE. As shown in Figure 3a, multiple different rich execution environments (REEs) can be virtualized on the same hardware platform (chip) through virtual machine support. The REE and TEE are isolated by the chip's hardware TEE mechanism. Multiple REEs (1#REE to n#REE, n is a natural number greater than 1) are set in the REE area, and each REE includes multiple CAs (CA1 to CAn, n is a natural number greater than 2). The rich operating system of each REE can use one of the operating systems such as Linux, Android, Windows, and IOS. Multiple CAs in the REE area use a unified preset format interface to exchange information with the trusted service (TS) in the TEE Proxy. The TEE Proxy implements information exchange between the TS and the corresponding TA through a secure channel. There are multiple TEEs (1#TEE to n#TEE, where n is a natural number greater than 1) set up in the TEE area. These multiple TEEs adopt at least two or more hardware architectures. For example, different TEEs can adopt different hardware architectures, and some TEEs can adopt the same hardware architecture. For example, 1#TEE adopts the first hardware architecture, and 2#TEE and 3#TEE adopt the second hardware architecture. Correspondingly, TEEs with different hardware architectures have different TEEOS. On this basis, a new REE can be constructed through a virtual machine, and the required TEE Proxy security service can be executed in this REE. In this way, access requests from all CAs in other REEs can be uniformly managed, and at the same time, it is responsible for information interaction and TA calls under the secure channel with the TEEOS on the TEE side.

[0043] In another implementation, for resource-constrained environments, the TEE proxy isolation layer can be constructed based on containers. For example, a target container can be constructed for each REE in the at least one REE, and the TEE proxy isolation layer can be constructed within the target container. As shown in Figure 3b, when resources are limited, or when the system has high security requirements for the TEE Proxy itself, the content required by the TEE Proxy can be contained within the REE environment by constructing a container. In this mode, the resource overhead required by the TEE Proxy itself is minimized, and the Trusted Services (TS) it contains can be compressed to only those actually required by the system, minimizing system overhead and avoiding resource waste. Through hardware isolation, it is divided into REE areas and TEE areas. The REE area can contain multiple REEs (1#REE to n#REE, where n is a natural number greater than 1), each REE including multiple CAs (only one is shown in the figure as an example), and the rich operating system of each REE can adopt one of Linux, Android, Windows, iOS, and other operating systems. For each REE, a TEE Proxy corresponding to the REE is built based on the container. Multiple CAs in the REE area use a unified preset format interface to exchange information with the trusted service (TS) in the TEE Proxy. The TEE Proxy implements information exchange between the TS and the corresponding TA through a secure channel. Multiple TEEs (1#TEE to n#TEE, where n is a natural number greater than 1) are set up in the TEE area. These multiple TEEs adopt at least two or more hardware architectures. For example, different TEEs can adopt different hardware architectures, and some TEEs can adopt the same hardware architecture. For example, 1#TEE is the first hardware architecture, and 2#TEE and 3#TEE are the second hardware architecture. Accordingly, the TEEs using different hardware architectures have different TEEOS. It should be noted that in this embodiment, the number of REEs, the number of CAs in the REE, the number of TSs in the TEE proxy isolation layer, the number of TEEs, and the number of TAs in the TEE can be the same as n, or different values. Generally, the number of TSs is the same as the total number of TAs in all TEEs.

[0044] In another possible implementation, when security requirements are relatively high, the TEE proxy isolation layer can be built based on an external secure element (Secure Element, SE). For example, the TEE proxy isolation layer can be built in the REE of the external secure element, and the at least one TEE can be built in the TEE of the external secure element. As shown in Figure 3c, when the system security requirements are particularly high, it can be considered to be implemented through an external secure chip. The entire TEE Proxy can be transplanted to the REE area within the secure chip, and security requests can be interacted through external communication bus interfaces (such as Ethernet, Uart, etc.) and other hardware platforms, such as the CA under the REE on the Accelerated Processing Unit (APU) side, thereby improving the overall security level of the system. It should be noted that multiple TEEs can be set in the TEE area of ​​the SE (1#TEE to n#TEE, n is a natural number greater than 1). The multiple TEEs adopt at least two or more hardware architectures, and the TEE Proxy realizes information interaction between the TS and the corresponding TA through a secure channel. The APU can be equipped with multiple REEs (1#REE to n#REE, where n is a natural number greater than 1). Each REE includes multiple CAs (only one REE is shown in the figure). The rich operating system of each REE can adopt one of the operating systems such as Linux, Android, Windows, and iOS. For each REE, a TEE Proxy corresponding to the REE is built based on the container. Multiple CAs in the REE area use a unified preset interface to exchange information with the trusted service (TS) in the TEE Proxy.

[0045] 202. Determine, based on the TEE access request, a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer.

[0046] 203. Determine a target conversion interface corresponding to the target security service, and perform format conversion on the TEE access request based on the target conversion interface to obtain a converted TEE access request.

[0047] Among them, the target security service includes a trusted service (TS), and the target conversion interface includes a trusted application (TA). Exemplarily, a plurality of trusted service TSs are set in the TEE proxy isolation layer, such as biometric information recognition (fingerprint authentication service, face authentication service), password authentication, etc. Exemplarily, the client application (CA) in the REE environment initiates an access request to the TEE and requests face verification. Thus, the TEE proxy isolation layer can determine the corresponding trusted service based on the access request, and then select the appropriate trusted service TS, and perform format conversion on the access request, and convert it into a format recognizable by the trusted operating system of the TEE where the trusted application corresponding to the face authentication is located. Exemplarily, as shown in Figure 3a, CA1 initiates a TEE access request, and the TEE proxy isolation layer (TEE Proxy) parses the TEE access request and determines that the trusted service TS1 matches the TEE access request, and TS1 corresponds to TA1 in 1#TEE. Then, based on TS1, the TEE access request is format converted into a format recognizable by the trusted operating system in 1#TEE.

[0048] In some embodiments, when the CA on the REE side is called, it sends a request for a response security service to the TEE Proxy. To improve security, the TEE Proxy performs a validity check on the request. Exemplarily, determining the target security service corresponding to the TEE access request based on the TEE access request may include: performing a security check on the TEE access request; and in response to the verification being qualified, determining the target security service corresponding to the TEE access request based on the TEE access request.

[0049] In some embodiments, the access request can be security-verified based on a unique instruction code. Exemplarily, the security verification of the TEE access request can include: obtaining the target instruction code in the TEE access request; in response to the target instruction code being consistent with the unique instruction code pre-assigned to the target client application, the TEE access request is determined to be qualified. Exemplarily, the assigned unique instruction code may include numbers, letters, special characters, etc. Different client applications can have different unique instruction codes. Of course, client applications can also be classified (for example, based on security level classification) and the same unique instruction code can be assigned to similar client applications.

[0050] In some embodiments, in order to effectively and reasonably utilize resources, a preliminary rationality check can be performed on the access request to avoid wasting computing resources during subsequent execution due to reasons such as data format not meeting requirements. Exemplarily, determining the target conversion interface corresponding to the target security service can include: performing a rationality check on the TEE access request based on the data specification corresponding to the target security service; and in response to the verification being qualified, determining the target conversion interface corresponding to the target security service.

[0051] For example, when the CA on the REE side has an information security-related request (usually to access data on the TEE part or call corresponding capabilities), the REE side will send a corresponding service request to the TEE Proxy. After receiving the request, the TEE Proxy will first perform a security check on the request. Rejecting all unknown and unreliable access requests is equivalent to playing a role similar to a security firewall in front of the TEE, reducing the risk of confidential files and information stored in the system being destroyed and stolen. In addition, the data legitimacy of the request that has passed the security check can also be checked at the same time (such as whether there may be a data processing overflow, or a request for an abnormal data type, etc.) to ensure the legitimacy and rationality of the access.

[0052] In some embodiments, the type of TEE to which the TS in the TEE Proxy corresponds can be determined by querying the configuration information. Exemplarily, determining the target conversion interface corresponding to the target security service may include: obtaining configuration information, the configuration information including the correspondence between the at least one target security service and the at least one TEE; determining the target TEE corresponding to the target security service based on the configuration information; and determining the target conversion interface corresponding to the target security service based on the target TEE.

[0053] Exemplarily, after determining the TS corresponding to the TEE access request, the configuration information can be queried to determine in which of the multiple TEEs the TA corresponding to the TS is installed, and then determine the conversion interface required by the TEE of this type.

[0054] 204. Send the converted TEE access request to a target TEE among the at least one TEE; the target TEE is the TEE where the target trusted application corresponding to the target security service is located.

[0055] Exemplarily, after completing the format conversion of the TEE access request, the converted TEE access request can be sent to the trusted operating system of the corresponding TEE, and then the converted TEE access request is sent to the corresponding trusted application (TA) through the trusted operating system.

[0056] In some embodiments, sending the converted TEE access request to the target TEE among the at least one TEE may include: establishing a target security channel between the target security service and the target TEE based on the technical implementation mechanism of the hardware architecture corresponding to the target TEE; and sending the converted TEE access request to the target TEE among the at least one TEE through the target security channel.

[0057] For example, when TEE Proxy verifies that the message sent by the REE-side CA is valid and reasonable, it will establish communication with TEEOS by establishing a corresponding secure channel in the hardware platform (the implementation method depends on the security level design of the chip architecture), and convert the message format into a corresponding data format that TEEEOS can recognize. In this way, TEEOS will call the TA in the TEE environment to perform corresponding security operations, such as biometric information collection, recognition, password authentication, storage, etc.

[0058] The trusted execution environment access control method provided in this embodiment, by setting up a TEE proxy isolation layer, transmits access requests and other data with the client application in the REE based on a preset format interface, and converts the access requests into different formats through the TEE proxy isolation layer to adapt to trusted applications in different TEEs, thereby supporting TEEs with various design mechanisms and being able to effectively deal with the high cost and low efficiency problems caused by hardware platform migration.

[0059] FIG4 is a second flow chart of a trusted execution environment access control method provided by an embodiment of the present application. As shown in FIG4 , the method includes:

[0060] 401. Build a TEE proxy isolation layer.

[0061] 402. Establish a unified standardized trusted service (TS) in TEE Proxy and provide it to the client application (CA) on the REE side.

[0062] 403. Receive a TEE access request of a target client application in the at least one REE through an interface in a preset format of the TEE proxy isolation layer.

[0063] 404. Determine, based on the TEE access request, a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer.

[0064] 405 : Determine a target conversion interface corresponding to the target security service, and perform format conversion on the TEE access request based on the target conversion interface to obtain a converted TEE access request.

[0065] 406. Send the converted TEE access request to a target TEE among the at least one TEE; the target TEE is the TEE where the target trusted application corresponding to the target security service is located.

[0066] Steps 401 to 406 in this embodiment are similar to steps 201 to 204 in the above embodiment, and are not described again here.

[0067] 407 : Call the target trusted application to execute the security operation corresponding to the TEE access request, obtain an execution result, and return the execution result to the target client application through the TEE proxy isolation layer.

[0068] For example, after the TA completes its execution, it feeds the results back to TEEOS, which then passes the final results to the TEE Proxy via a secure channel. Upon receiving the results, the TEE Proxy forwards the message to the CA initiator on the REE side. This completes the entire process of a trusted execution environment access control method based on TEE Proxy.

[0069] The trusted execution environment access control method provided in this embodiment sets up a TEE proxy isolation layer, transmits access requests and other data with the client application in the REE based on a preset format interface, and converts the access requests into different formats through the TEE proxy isolation layer to adapt to trusted applications in different TEEs, thereby supporting TEEs with various design mechanisms and being able to efficiently deal with the high cost and low efficiency problems caused by hardware platform migration.

[0070] FIG5 is a schematic diagram of the structure of a trusted execution environment access control device provided by an embodiment of the present application. As shown in FIG5 , the trusted execution environment access control device 50 includes: a receiving module 501 , a determining module 502 , a converting module 503 and a sending module 504 .

[0071] A receiving module 501 is configured to receive a TEE access request from a target client application in the at least one REE through the TEE proxy isolation layer;

[0072] A determination module 502 is configured to determine, according to the TEE access request, a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer;

[0073] The conversion module 503 is configured to determine a target conversion interface corresponding to the target security service, and convert the format of the TEE access request based on the target conversion interface to obtain a converted TEE access request;

[0074] The sending module 504 is configured to send the converted TEE access request to a target TEE in the at least one TEE; the target TEE is the TEE where the target trusted application corresponding to the target security service is located.

[0075] The trusted execution environment access control device provided in the embodiment of the present application sets a TEE proxy isolation layer, transmits access requests and other data with the client application in the REE based on an interface in a preset format, and converts the access requests into different formats through the TEE proxy isolation layer to adapt to trusted applications in different TEEs, thereby supporting TEEs with various design mechanisms and being able to efficiently deal with the high cost and low efficiency problems caused by hardware platform migration.

[0076] In some embodiments, the trusted execution environment access control device 50 also includes a construction module (not shown), which is configured to construct the TEE agent isolation layer based on a virtual machine; or, to construct the TEE agent isolation layer based on a container; or, to construct the TEE agent isolation layer based on an external security element.

[0077] In some embodiments, the construction module is configured to: construct a new REE based on the virtual machine, and construct the TEE agent isolation layer in the new REE.

[0078] In some embodiments, the construction module is configured to: construct a target container for each REE in the at least one REE, and construct the TEE proxy isolation layer in the target container.

[0079] In some embodiments, the building module is configured to: build the TEE proxy isolation layer in the REE of the external secure element, and build the at least one TEE in the TEE of the external secure element.

[0080] In some embodiments, the determination module 502 is configured to: perform a security check on the TEE access request; and in response to a qualified check, determine a target security service corresponding to the TEE access request based on the TEE access request.

[0081] In some embodiments, the determination module 502 is configured to: obtain a target instruction code in the TEE access request; and determine that the TEE access request is verified to be qualified in response to the target instruction code being consistent with a unique instruction code pre-assigned to the target client application.

[0082] In some embodiments, the conversion module 503 is configured to: perform a rationality check on the TEE access request according to the data specification corresponding to the target security service; and in response to the verification being qualified, determine the target conversion interface corresponding to the target security service.

[0083] In some embodiments, the conversion module 503 is configured to: obtain configuration information, the configuration information including the correspondence between the at least one target security service and the at least one TEE; determine the target TEE corresponding to the target security service based on the configuration information; determine the target conversion interface corresponding to the target security service based on the target TEE.

[0084] In some embodiments, the sending module 504 is configured to: establish a target security channel between the target security service and the target TEE based on the technical implementation mechanism of the hardware architecture corresponding to the target TEE; and send the converted TEE access request to the target TEE among the at least one TEE through the target security channel.

[0085] In some embodiments, the sending module 504 is further configured to: call the target trusted application to execute the security operation corresponding to the TEE access request, obtain the execution result, and return the execution result to the target client application through the TEE proxy isolation layer.

[0086] The trusted execution environment access control device provided in the embodiment of the present application can be configured to execute the above-mentioned method embodiment, and its implementation principle and technical effects are similar, which will not be described in detail in this embodiment.

[0087] FIG6 is a schematic diagram of the hardware structure of a trusted execution environment access control device provided in an embodiment of the present application. The device may be a computer, a messaging device, a tablet device, a medical device, etc.

[0088] The trusted execution environment access control device 60 may include at least one of the following components: a processing component 601, a memory 602, a power component 603, a multimedia component 604, an audio component 605, an input / output (I / O) interface 606, a sensor component 607, and a communication component 608.

[0089] The processing component 601 generally controls the overall operation of the trusted execution environment access control device 60, such as operations associated with display, phone calls, data communications, camera operation, and recording operations. The processing component 601 may include at least one processor 609 to execute instructions to perform all or part of the steps of the above-described method. In addition, the processing component 601 may include at least one module to facilitate interaction between the processing component 601 and other components. For example, the processing component 601 may include a multimedia module to facilitate interaction between the multimedia component 604 and the processing component 601.

[0090] The memory 602 is configured to store various types of data to support operations of the trusted execution environment access control device 60. Examples of such data include instructions for any application or method operating on the trusted execution environment access control device 60, contact data, phone book data, messages, pictures, videos, etc. The memory 602 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0091] The power supply component 603 provides power to various components of the trusted execution environment access control device 60. The power supply component 603 may include a power management system, at least one power supply, and other components associated with generating, managing, and distributing power to the device 60.

[0092] The multimedia component 604 includes a screen that provides an output interface between the device 60 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes at least one touch sensor to sense touches, slides, and gestures on the touch panel. The touch sensor can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 604 includes at least one of a front camera and a rear camera. When the device 60 is in an operating mode, such as a shooting mode or a video mode, at least one of the front camera and the rear camera can receive external multimedia data. Each front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capability.

[0093] The audio component 605 is configured to output or input audio signals. For example, the audio component 605 includes a microphone (MIC), which is configured to receive external audio signals when the device 60 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be stored in the memory 602 or transmitted via the communication component 608. In some embodiments, the audio component 605 also includes a speaker configured to output audio signals.

[0094] The I / O interface 606 provides an interface between the processing component 601 and peripheral interface modules, such as a keyboard, a click wheel, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0095] Sensor assembly 607 includes at least one sensor configured to provide multiple aspects of the status of device 60. For example, sensor assembly 607 can detect whether device 60 is open or closed, the relative positioning of components, such as the display and keypad of device 60, and can also detect changes in the position of device 60 or a component of device 60, the presence or absence of user contact with device 60, the orientation, acceleration, or deceleration of device 60, and changes in the temperature of device 60. Sensor assembly 607 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 607 can also include an optical sensor, such as a complementary metal-oxide-semiconductor (CMOS) or charge coupled device (CCD) image sensor, configured for use in imaging applications. In some embodiments, sensor assembly 607 can also include an accelerometer, a gyroscope, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0096] The communication component 608 is configured to facilitate communication between the device 60 and other devices in a wired or wireless manner. The device 60 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 608 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 608 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0097] In an exemplary embodiment, the device 60 can be implemented by at least one application specific integrated circuit (ASIC), digital signal processor (DSP), digital signal processing device (DSPD), programmable logic device (PLD), field programmable gate array (FPGA), controller, microcontroller, microprocessor or other electronic component, and is configured to perform the above method.

[0098] In an exemplary embodiment, a non-transitory computer-readable storage medium including computer-executable instructions is further provided, such as a memory 602 including computer-executable instructions. The computer-executable instructions can be executed by a processor 609 of the device 60 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a compact disc read-only memory (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, etc.

[0099] The computer-readable storage medium can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0100] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in a device as discrete components.

[0101] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0102] An embodiment of the present application further provides a computer program product, including a computer program, which, when executed by a processor, implements the above-mentioned trusted execution environment access control method.

Claims

1. A trusted execution environment access control method, applied to a hardware platform, wherein the hardware platform includes at least one rich execution environment (REE) and at least one trusted execution environment (TEE), wherein the at least one rich execution environment (REE) is connected to the at least one TEE through a TEE proxy isolation layer, and the method includes: Receiving, through the TEE proxy isolation layer, a TEE access request of a target client application in the at least one REE based on an interface in a preset format; Determine, according to the TEE access request, a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer; Determine a target conversion interface corresponding to the target security service, and perform format conversion on the TEE access request based on the target conversion interface to obtain a converted TEE access request; Sending the converted TEE access request to a target TEE in the at least one TEE; The target TEE is the TEE where the target trusted application corresponding to the target security service is located.

2. The method according to claim 1, wherein: Before receiving the TEE access request of the target client application in the at least one REE through the TEE proxy isolation layer based on the interface of the preset format, the method further includes: Constructing the TEE proxy isolation layer based on the virtual machine; or, Building the TEE proxy isolation layer based on the container; or, The TEE proxy isolation layer is built based on an external security element.

3. The method according to claim 2, wherein: The TEE proxy isolation layer is constructed based on the virtual machine, including: A new REE is constructed based on the virtual machine, and the TEE agent isolation layer is constructed in the new REE.

4. The method according to claim 2, wherein: The TEE proxy isolation layer is constructed based on the container, including: For each REE in the at least one REE, a target container is constructed, and the TEE proxy isolation layer is constructed in the target container.

5. The method according to claim 2, wherein: The TEE proxy isolation layer is constructed based on the external security element, including: The TEE proxy isolation layer is built in the REE of the external secure element, and the at least one TEE is built in the TEE of the external secure element.

6. The method according to claim 1, wherein: The determining, according to the TEE access request, from at least one target security service in the TEE proxy isolation layer a target security service corresponding to the TEE access request includes: Performing security verification on the TEE access request; In response to the verification being qualified, a target security service corresponding to the TEE access request is determined according to the TEE access request.

7. The method according to claim 6, wherein: The performing security verification on the TEE access request includes: Obtaining the target instruction code in the TEE access request; In response to the target instruction code being consistent with a unique instruction code pre-assigned to the target client application, it is determined that the TEE access request is qualified.

8. The method according to claim 1, wherein: The determining of the target conversion interface corresponding to the target security service includes: Performing a rationality check on the TEE access request according to the data specification corresponding to the target security service; In response to the verification being qualified, a target conversion interface corresponding to the target security service is determined.

9. The method according to any one of claims 1 to 8, wherein: The determining of the target conversion interface corresponding to the target security service includes: Acquire configuration information, where the configuration information includes a correspondence between the at least one target security service and the at least one TEE; Determine the target TEE corresponding to the target security service according to the configuration information; Determine a target conversion interface corresponding to the target security service according to the target TEE.

10. The method according to any one of claims 1 to 8, wherein: The sending the converted TEE access request to a target TEE in the at least one TEE includes: Based on the technical implementation mechanism of the hardware architecture corresponding to the target TEE, a target security channel is established between the target security service and the target TEE; The converted TEE access request is sent to a target TEE in the at least one TEE through the target secure channel.

11. The method according to any one of claims 1 to 8, wherein: After sending the converted TEE access request to the target TEE in the at least one TEE, the method further includes: The target trusted application is called to execute the security operation corresponding to the TEE access request, obtain the execution result, and return the execution result to the target client application through the TEE proxy isolation layer.

12. A trusted execution environment access control device, comprising: A receiving module, configured to receive a TEE access request of a target client application in at least one REE through a TEE proxy isolation layer; A determination module, configured to determine a target security service corresponding to the TEE access request from at least one target security service in the TEE proxy isolation layer according to the TEE access request; A conversion module, configured to determine a target conversion interface corresponding to the target security service, and perform format conversion on the TEE access request based on the target conversion interface to obtain a converted TEE access request; A sending module, configured to send the converted TEE access request to a target TEE in the at least one TEE; The target TEE is the TEE where the target trusted application corresponding to the target security service is located.

13. A trusted execution environment access control device, comprising: at least one processor and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the trusted execution environment access control method according to any one of claims 1 to 11.

14. A vehicle, comprising the trusted execution environment access control device according to claim 13.

15. A computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when a processor executes the computer-executable instructions, the trusted execution environment access control method according to any one of claims 1 to 11 is implemented.

16. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the trusted execution environment access control method according to any one of claims 1 to 11 is implemented.

Images