Heterogeneous TEE authentication method based on gateway

Abstract

The invention discloses a heterogeneous TEE authentication method based on a gateway, and the method comprises the steps: respectively deploying each client application in a non-TEE or at least one type of TEE, and respectively deploying each server application in at least one type of TEE or comprises the non-TEE and at least one type of TEE; configuring a client sub-gateway for each client application deployed in the TEE, connecting all the client sub-gateways and non-TEE client applications to a client main gateway, configuring a server sub-gateway for each server application deployed in the TEE, and connecting all the server sub-gateways and non-TEE server applications to a server main gateway; one-way heterogeneous TEE authentication is achieved between the client side and the server side based on the TLS or two-way heterogeneous TEE authentication is achieved based on the mTLS. According to the invention, heterogeneous TEE authentication based on TLS or mTLS can be realized under a heterogeneous authentication gateway framework, and a secure channel is established at the same time.

Description

Technical Field

[0001] The present invention belongs to the technical field of network gateway communications, and in particular relates to a gateway-based heterogeneous TEE authentication method. Background Art

[0002] With the development of information technology, in today's digital era, the security of cyberspace has not only become the focus of the technology field, but also has a profound impact on the stability and development of the social economy. With the explosive growth of data volume and the acceleration of data circulation, ensuring the security and privacy of network data has become a strategic task that cannot be ignored. Although technological progress has brought unprecedented convenience, the frequent occurrence of security incidents such as data leakage and privacy infringement has made individuals, enterprises and even the wider social level deeply aware of the importance of data protection, and has put forward higher requirements for encryption technology for data transmission and the security of data storage.

[0003] Driven by this trend, hardware-level security technologies have developed rapidly, such as Intel's SoftwareGuard Extensions (SGX), ARM's Trust Zone, Hygon's Crypto Secure Virtualization (CSV) and AMD's Secure Encrypted Virtualization (SEV), all of which are committed to building Trusted Execution Environments (TEEs). TEEs are widely used to enhance the security of different types of critical infrastructures, including trusted monitoring and secure node construction, by providing an isolated and protected computing area. At present, some work has been carried out to protect critical infrastructure using TEEs. These technologies have built a solid line of defense for user data and ensured the confidentiality and integrity of information during processing. However, in the face of a diverse and independently operating TEE ecosystem, users often face complex remote authentication processes when migrating or interacting across environments, which not only requires users to have certain technical knowledge, but also adds additional management and operational burdens. Although the principles of these TEE technologies are very similar, their details and authentication processes are quite different, and it is difficult to make TEEs from different manufacturers compatible. Trusted communication between different TEEs is a more obvious problem. Even if the devices use the same TEE technology, they may not work together. The reason is that an organization can establish an attestation service with its own root of trust to support all devices with TEE functions, but this attestation service cannot identify devices belonging to other organizations. How to complete the establishment of a secure communication channel between heterogeneous TEEs is an urgent problem to be solved.

[0004] At the same time, the Transport Layer Security (TLS) protocol, as a standard for ensuring data transmission security, plays a core role in protecting network communications from eavesdropping, tampering, and impersonation. However, how to efficiently integrate TLS with various TEEs to achieve end-to-end seamless security protection is still an area that needs to be explored.

[0005] Therefore, in the face of security challenges in the digital age, the development of TEE technology provides us with a powerful means of protection. However, to achieve the widespread application and in-depth integration of TEE technology, further research is needed on how to solve the problems of heterogeneous TEE authentication and secure channel establishment and integration with TLS protocols. Summary of the invention

[0006] In view of the above, the purpose of the present invention is to provide a gateway-based heterogeneous TEE authentication method, which ensures the privacy and security of user data transmission and storage in a serverless computing environment by designing and implementing a heterogeneous authentication gateway (HANG) for serverless computing. Specific objectives include: (1) Implementing a heterogeneous authentication gateway: deploying a gateway designed and open sourced by HANG on the client and server, including a sub-gateway and a main gateway structure, to support different types of TEEs; (2) Ensuring data privacy and security: utilizing TEE technology and open source code to ensure encryption and privacy protection of user data during transmission and storage; (3) Supporting serverless computing architecture: achieving seamless integration with the serverless computing framework, so that users can use the HANG gateway for secure communication without modifying existing applications; (4) Providing open source review: ensuring the security and credibility of the system by making the gateway code open source for community review.

[0007] In order to achieve the above-mentioned invention object, the technical solution provided by the present invention is as follows:

[0008] The embodiment of the present invention provides a gateway-based heterogeneous TEE authentication method, comprising the following steps:

[0009] Deploy each client application in a non-TEE or at least one type of TEE, and deploy each server application in at least one type of TEE, or deploy each server application in a non-TEE and at least one type of TEE;

[0010] Configure a client sub-gateway for each client application deployed in TEE, connect all client sub-gateways and client applications deployed in non-TEE to the same client main gateway, configure a server sub-gateway for each server application deployed in TEE, connect all service sub-gateways and server applications deployed in non-TEE to the same server main gateway;

[0011] One-way heterogeneous TEE authentication is implemented between the client and the server based on TLS, or two-way heterogeneous TEE authentication is implemented based on mTLS. During the authentication process, the TEE remote attestation related information of the TEE where each application is located is embedded into TLS or mTLS through the server sub-gateway or the client sub-gateway, and is listened and forwarded through the client main gateway and the server main gateway. The client sub-gateway or the server sub-gateway verifies the received TEE remote attestation related information. After the verification is passed, the heterogeneous TEE authentication and secure channel establishment are completed; the TEE remote attestation related information includes TEE quote and evidence. TEE quote contains hardware information used to prove the authenticity and security of the server-side TEE hardware device, and evidence contains the status information of the application running in the TEE.

[0012] Specifically, in the one-way heterogeneous TEE authentication scenario, the client gateway is deployed, including:

[0013] For single-client application scenarios, the client gateway is deployed in the same environment as the client application. The client gateway here includes the functions of the client main gateway and the client sub-gateway. For multi-client application scenarios, the client main gateway is deployed in an environment that is trustworthy to multiple client applications.

[0014] After the environment deployment of the client main gateway is completed, configuration is performed in the client main gateway. The configuration information includes: the TEE supported by the application running on the server, the evidence of the application running under the TEE, and the network address of the server sub-gateway.

[0015] Specifically, in the one-way heterogeneous TEE authentication scenario, the server gateway is deployed, including:

[0016] For single-server application scenarios, the server gateway is deployed in the same TEE environment as the server application. The server gateway includes the functions of the server main gateway and the server sub-gateway. For multi-server application scenarios, the server main gateway is deployed in any environment, and the server sub-gateway is deployed in the same TEE environment as the corresponding server application.

[0017] After completing the environment deployment of the server-side main gateway and sub-gateway, configure it in the server-side sub-gateway. The configuration information includes: the TEE where the server-side application is located.

[0018] Specifically, the authentication process of the one-way heterogeneous TEE authentication scenario includes:

[0019] The client user initiates a connection establishment request. The traffic starts from the client application, passes through the client main gateway, and is forwarded to the server main gateway in the client main gateway. The server main gateway further forwards the traffic to the corresponding server sub-gateway. After receiving the connection establishment request, the server sub-gateway returns the traffic containing the TEE remote attestation related information of the server application to the client main gateway. After receiving the return traffic, the client main gateway compares the evidence in the received TEE remote attestation related information of the server application with the configured evidence, and submits the TEE quote to the TEE hardware manufacturer for verification. After the verification is passed, the remaining TLS handshake connection is completed, and the client and server jointly negotiate a symmetric key for subsequent session communications.

[0020] Specifically, in the bidirectional heterogeneous TEE authentication scenario, the client gateway is deployed, including:

[0021] For single-client application scenarios, the client gateway is deployed in the same TEE environment as the client application. The client gateway includes the functions of the client main gateway and the client sub-gateway. For multi-client application scenarios, the client main gateway is deployed in any environment, and the client sub-gateway is deployed in the same TEE environment as the corresponding client application.

[0022] After completing the environment deployment of the client main gateway and sub-gateway, configure it in the client sub-gateway. The configuration information includes: the TEE supported by the application running on the server, the evidence of the application running under the TEE, the network address of the server sub-gateway, and the TEE where the client application is located.

[0023] Specifically, in the bidirectional heterogeneous TEE authentication scenario, the server gateway is deployed, including:

[0024] For single-server application scenarios, the server gateway is deployed in the same TEE environment as the server application. The server gateway includes the functions of the server main gateway and the server sub-gateway. For multi-server application scenarios, the server main gateway is deployed in any environment, and the server sub-gateway is deployed in the same TEE environment as the corresponding server application.

[0025] After completing the environment deployment of the server-side main gateway and sub-gateway, configure it in the server-side sub-gateway. The configuration information includes: TEE supported by the server and TEE where the server application is located.

[0026] Specifically, the authentication process of the bidirectional heterogeneous TEE authentication scenario includes:

[0027] The client user initiates a connection establishment request. The traffic starts from the client application and passes through the client sub-gateway. The client sub-gateway forwards the traffic to the client main gateway, which then forwards the traffic to the server main gateway. The server main gateway further forwards the traffic to the corresponding server sub-gateway. After receiving the connection establishment request, the server sub-gateway returns the traffic containing the TEE remote attestation related information of the server application to the client sub-gateway. After receiving the return traffic, the client sub-gateway compares the evidence in the received TEE remote attestation related information of the server application with the configured evidence, and submits the TEE quote to the TEE hardware manufacturer for verification. After the verification is successful, the client sub-gateway returns the TEE remote attestation related information of the client application to the server sub-gateway. The traffic returns to the server sub-gateway via the client main gateway and the server main gateway. After receiving the return traffic, the server sub-gateway submits the TEE quote in the received TEE remote attestation related information of the client application to the TEE hardware manufacturer for verification. After the verification is successful, the remaining mTLS handshake connection is completed, and the client and the server jointly negotiate a symmetric key for subsequent session communication.

[0028] Specifically, during the authentication process, by modifying the extension field of the X509 certificate in TLS or mTLS, the field containing TEE quote related information is embedded into the extension field of the X509 certificate according to different authentication scenarios, and then the TEEquote related information is extracted from the extension field of the X509 certificate to complete the relevant verification.

[0029] Specifically, in the one-way heterogeneous TEE authentication scenario, the source code of the client main gateway and sub-gateway is open source for auditing.

[0030] Specifically, in the bidirectional heterogeneous TEE authentication scenario, the source code of the client main gateway and sub-gateway as well as the server main gateway and sub-gateway are open sourced for auditing.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] By deploying open source heterogeneous authentication gateways on the client and server, imperceptible communication with high security and privacy protection can be achieved. Users do not need to modify existing applications. They can complete remote attestation and data encryption transmission by sending and receiving messages through the HANG gateway structure that includes the deployed sub-gateway and the main gateway. By modifying the extension field of the X509 certificate, the TEE remote attestation related information is embedded in it to ensure that the client and the server can verify the validity and authenticity of each other's TEE through the certificate. In the two-way authentication scenario, the use of TEE technology and mTLS two-way authentication can achieve a zero-trust architecture to ensure the security and integrity of data transmission. At the same time, by open-sourcing the gateway code for review, the credibility of the system can be enhanced, and by optimizing the gateway performance, efficient and stable operation and flexible expansion capabilities can be ensured in a serverless computing environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0034] Figure 1 It is a flow chart of a gateway-based heterogeneous TEE authentication method provided by an embodiment of the present invention;

[0035] Figure 2 It is a HANG high-level architecture design diagram provided by an embodiment of the present invention;

[0036] Figure 3 It is a HANG architecture design diagram for a one-way authentication scenario provided by an embodiment of the present invention;

[0037] Figure 4 It is a HANG architecture design diagram for a two-way authentication scenario provided by an embodiment of the present invention;

[0038] Figure 5 It is a schematic diagram of the mTLS process in the HANG two-way authentication provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0039] To make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific implementation methods described herein are only used to explain the present invention and do not limit the scope of protection of the present invention.

[0040] In view of the challenges existing in the existing technologies, the heterogeneous authentication gateway for serverless computing is a good way out. As an innovative solution, it deploys an open source gateway designed for simplifying TEE remote authentication on the client and server sides, providing users with unprecedented convenience and security. The introduction of the trusted gateway essentially builds a bridge between the user and the authentication infrastructure. This bridge is presented in the form of open source, which not only ensures the transparency of the authentication process, but also greatly reduces the learning and adaptation costs of users. The working mechanism of the trusted gateway is that users only need to install the client gateway to entrust all remote authentication links to the trusted gateway for processing, without having to deeply understand the specific implementation and technical details of the underlying TEE. This design not only greatly simplifies the user's operation process, but also enables the deployed applications to seamlessly connect to various TEEs without any code-level adjustments, achieving true plug-and-play. In this way, the trusted gateway not only strengthens the security collaboration across TEEs, but also promotes the openness and sharing of the security ecosystem, laying a solid foundation for building a more stable and reliable digital world.

[0041] Based on this, the inventive concept of the present invention is: in response to the problem of heterogeneous TEE authentication in the prior art and the difficulty of integrating various types of TEEs with TLS protocols, an embodiment of the present invention provides a gateway-based heterogeneous TEE authentication method. According to the environment in which the client application and the server application are located, corresponding client sub-gateways or server sub-gateways are deployed for applications under all TEEs to implement heterogeneous TEE authentication. The client main gateway and the server main gateway are deployed respectively for monitoring and forwarding traffic. Remote authentication is completed during the establishment of the communication channel based on TLS or mTLS, ensuring that the client application communicates securely with the server, thereby improving the response speed and efficiency of the system.

[0042] Figure 1 is a flow chart of a gateway-based heterogeneous TEE authentication method provided by an embodiment of the present invention, Figure 2 This is a high-level architecture design diagram of HANG (Heterogeneous Authentication Network Gateway) provided by an embodiment of the present invention. Figure 1 and Figure 2 As shown, a gateway-based heterogeneous TEE authentication method provided by an embodiment of the present invention is mainly implemented based on the designed HANG gateway architecture. The HANG core consists of three parts:

[0043] 1.TEE

[0044] In the entire HANG framework, server-side applications must be deployed in TEE. In cloud storage systems, users' private data is stored on the server side; in cloud computing systems, users need to transmit data to the server side for calculation; in cloud communication systems, the server side also backs up the data during user communication. These data are all private data of users and cannot be leaked, so server-side applications must run in TEE.

[0045] 2. Gateway Proxy

[0046] In the HANG framework, both the server application and the client application communicate directly with the corresponding gateway; it is also with the help of the gateway that HANG can achieve imperceptible communication between the client application and the server application in heterogeneous TEE. The gateway of HANG is divided into two parts, one is the gateway for the client, and the other is the gateway for the server. For the server gateway, it is responsible for proxy transmission of messages from the server, and when establishing communication with the client gateway, it provides remote attestation related information of the TEE where the server is located; the client gateway is responsible for the proxy of messages from the client, and when establishing communication with the server gateway, it verifies the validity of the TEE remote attestation related information from the server gateway. HANG realizes the establishment of secure channels and imperceptible communication between client and server applications by integrating the process of TEE remote attestation with the establishment of a secure communication channel.

[0047] 3. X509 Certificate

[0048] In the HANG framework, the establishment of a secure channel depends on TEE remote attestation, which includes TEE quote and evidence. TEE quote contains hardware information used to prove the authenticity and security of the server-side TEE hardware device, and evidence contains status information of the application running in the TEE. This step is achieved by modifying the extension field of the X509 certificate, embedding the TEE quote related information into the X509 certificate extension field by the server / client gateway, and then extracting it from the X509 certificate extension field by the client / server gateway and completing the relevant verification.

[0049] The HANG gateway designed in the present invention is designed for two scenarios: a one-way authentication scenario where only the server is in the TEE environment and a two-way authentication scenario where both the client and the server are in the TEE environment.

[0050] (I) One-way authentication scenario

[0051] In the embodiment, Figure 3The figure shows the HANG architecture design for a one-way authentication scenario. In this scenario, only the server application is located in the TEE, and the HANG default client application and client gateway are located in a trusted environment.

[0052] 1. Client communication model

[0053] In the HANG architecture, one or more client applications communicate with the client main gateway. There is no requirement for the communication protocol from the client application to the client main gateway. As long as the communication protocol is supported by the client main gateway and the client application, it can be used. For single-client application scenarios, the client main gateway can be directly deployed in the environment where the client application is located; for multi-client application scenarios, the client main gateway is deployed in an environment that is trusted by multiple client applications. The security considerations of this part need to be completed by the user. Both the client application and the client main gateway need to be deployed by the user, and the verification of the server TEE is included in the client main gateway.

[0054] After completing the environment deployment of the client main gateway, configure it in the client main gateway. The configuration information includes: the TEE supported by the application running on the server, the evidence that the application runs under the TEE, and the network address of the server sub-gateway. The application running under the server TEE provides its evidence to the user so that the user can verify that the application running on the server is the application expected by the user and has not been modified. TEE quote is generated by the TEE manufacturer to tell the user that the server application is running on this TEE device. TEE quote can be verified by the TEE manufacturer for its validity to ensure that the application run by the user is indeed in the real TEE produced by the TEE manufacturer.

[0055] The deployment of the client main gateway is completed by the user. The source code of this part of the gateway is open source and available for user audit in an auditable manner to ensure that the client gateway is trustworthy to the user and will not do anything malicious to the user data.

[0056] 2. Server communication model

[0057] In the HANG structure, one or more server applications communicate with the server main gateway and the server sub-gateway. There is no requirement for the communication protocol from the server application to the server main gateway and the server sub-gateway. As long as the communication protocol is supported by the server main gateway, the server sub-gateway and the server application, it can be used. For a single server application scenario, the server gateway is deployed in the TEE where the server application is located; for multiple server application scenarios, a server main gateway needs to be deployed. There is no requirement for the deployment of the server main gateway, as long as it can communicate well with multiple server applications. Each server application needs to be deployed in a separate TEE, and each server application needs to deploy an additional server sub-gateway to implement remote authentication related functions.

[0058] After the deployment is complete, the server-side main gateway needs to configure the communication protocol with each service-side sub-gateway, and the service-side sub-gateway needs to configure its own TEE, so as to facilitate subsequent communication with the client gateway and the provision of TEE remote attestation related information.

[0059] The main gateway and sub-gateway of the server are open source for users to audit to ensure that there is no malicious behavior. Users can audit the server gateway code and verify whether the server gateway is the open source gateway that the user expects. If not, the user can choose to refuse to communicate with it.

[0060] 3. Detailed communication process

[0061] like Figure 3 As shown in the figure, for a one-way authentication scenario, there are two users A and B, and a service provider C. For user A, he expects to run two applications in the service provider, one application A-1 needs to run in the SGX environment, and one application A-2 runs in any environment; for user B, he expects to run one application in the service provider, and the application B-1 needs to run in the TDX environment. And in this scenario, it is assumed that all gateways are open source.

[0062] In this scenario, the service provider needs to prepare three HANG gateways. One main gateway is located on the server side, and its main function is to complete the basic functions of the gateway, such as traffic forwarding and rate control. Two sub-gateways are located under TEEs such as SGX and TDX. In addition, the service provider needs to obtain the user's application in advance and run it in the corresponding environment according to the user's needs. And the service provider also needs to tell the user the type of TEE in advance, so that the user knows the type of TEE in which his application is located, in order to verify the authenticity of the TEE.

[0063] In this scenario, users need to deploy a client gateway in advance. Users also need to configure the TEE type provided by the service provider in the gateway so that the gateway can verify the authenticity of the TEE later. In addition, users also need to configure the application evidence information running on the server so that the gateway can verify the integrity of the application running in the TEE.

[0064] After the preparation is completed, the next step is communication. For users, according to the specific application scenario, you can choose to configure a forward or reverse proxy in the gateway. I will not elaborate on this here and will directly summarize it with the objects of user communication.

[0065] User A wants to interact part of his data with application A-1 in the SGX environment, and the other part of his data with A-2. For the data interacting with A-1, the traffic flow of user A is as follows:

[0066] User A first initiates a connection establishment request. The traffic starts from application A and passes through the client main gateway. The traffic is matched and forwarded in the client main gateway and forwarded to the server main gateway. The server main gateway identifies the communication object corresponding to the traffic and forwards the traffic to the SGX environment where A-1 is located, and is received by the server sub-gateway in SGX. After receiving the connection establishment request, the server sub-gateway returns the TEE remote attestation related information of the server application containing SGX information to user A, and the traffic is transmitted back to the client main gateway. After the client main gateway receives the message from application A-1, it first verifies the TEE remote attestation related information of the server application. At this time, the client main gateway verifies the TEE type (SGX) and the evidence of application A-1, including the authenticity of SGX and the integrity of the application. After the verification is passed, the remaining TLS handshake link is completed. This part is the same as the normal TLS protocol. The client and the server jointly negotiate a symmetric key for subsequent session communications.

[0067] For the data exchanged between user A and A-2, the traffic flow is similar to the above process, which is basically consistent with the TLS protocol process, but does not involve the authentication process in the HANG architecture. User B is similar. In this scenario, you only need to match the traffic forwarding rules on the server main gateway. In this scenario, the real connection is actually established between the client main gateway and the server sub-gateway, and the server main gateway only performs the function of traffic forwarding.

[0068] (II) Two-way authentication scenario

[0069] In the embodiment, Figure 4 The figure shows the HANG architecture design for a two-way authentication scenario, in which both the server application and the client application are located in the TEE.

[0070] 1. Client communication model

[0071] In the HANG architecture, one or more client applications communicate with the client main gateway and the client sub-gateway. There is no requirement for the communication protocol from the client application to the client main gateway and the client sub-gateway. As long as the communication protocol is supported by the client main gateway, the client sub-gateway and the client application, it can be used. For single-client application scenarios, the client gateway can be directly deployed in the TEE where the client application is located; for multi-client application scenarios, users need to deploy a client main gateway, and each client application needs to deploy a client sub-gateway. The security of this part is guaranteed by the TEE. Each client application is protected by the TEE, and the client main gateway can be located in any environment and only has the function of traffic forwarding. Both the client application and the client gateway need to be deployed by the user, and the verification of the server TEE is included in the client sub-gateway.

[0072] After the deployment is complete, the user needs to configure it in the client sub-gateway. The configuration information includes: the TEE type of the application running on the server, the evidence of the application running under the TEE, the network address of the server sub-gateway, and the TEE type of the client application, so as to facilitate the TEE remote authentication of subsequent communications with the server sub-gateway. The application running under the server TEE provides its evidence to the user so that the user can verify that the application running on the server is the application expected by the user and has not been modified. TEE quote is generated by the TEE manufacturer to tell the user that the server application is running on this TEE device. The TEE quote can be verified by the TEE manufacturer for its validity to ensure that the application run by the user is indeed in the real TEE produced by the TEE manufacturer.

[0073] The deployment of the client gateway is done by the user. The source code of the client sub-gateway is open source and auditable for users to audit, ensuring that the client gateway is trustworthy to users and will not have any malicious behavior on user data. There is no requirement for the client main gateway, as long as it can complete the traffic forwarding function with high performance.

[0074] 2. Server communication model

[0075] In the HANG structure, one or more server applications communicate with the server main gateway and the server sub-gateway. There is no requirement for the communication protocol from the server application to the server main gateway and the server sub-gateway. As long as the communication protocol is supported by the server main gateway, the server sub-gateway and the server application, it can be used. For a single server application scenario, the server gateway is deployed in the TEE where the server application is located; for multiple server application scenarios, a server main gateway needs to be deployed. There is no requirement for the deployment of the server main gateway, as long as it can communicate well with multiple server applications. Each server application needs to be deployed in a separate TEE, and each server application needs to deploy an additional server sub-gateway to implement remote authentication related functions.

[0076] After the deployment is complete, the server-side main gateway needs to configure the communication protocol with each service-side sub-gateway, and the service-side sub-gateway needs to configure its own TEE, so as to facilitate the subsequent communication with the client gateway and the provision of TEE remote attestation related information. The service-side sub-gateway also needs to configure the TEE type of its client to facilitate the subsequent verification of the client TEE.

[0077] The server-side sub-gateway is open source for user audit to ensure that there is no malicious behavior. Users can audit the server-side gateway code and verify whether the server-side gateway is the open source gateway that the user expects. If not, the user can choose to refuse to communicate with it. There is no requirement for the server-side main gateway, as long as it can complete the traffic forwarding function with high performance.

[0078] 3. Zero Trust Application Layer Protocol

[0079] like Figure 5 The figure shows a schematic diagram of the two-way mTLS process based on remote authentication in the HANG gateway designed by the present invention.

[0080] In one-way TEE authentication, the highest security that can be achieved is that both the client and server gateways are open source and auditable to ensure that there is no malicious behavior in their operating logic, but it cannot prevent the leakage of private data after the gateway is hacked, or the service provider maliciously leaking the user's plaintext private data. To avoid this, in two-way TEE authentication, an application layer protocol is designed for HANG to implement a zero-trust model. Its basic principle is similar to the TLS protocol. In the HANG model, the CA center is the TEE manufacturer, and the public key used is the public key in the TEE.

[0081] Specifically, the private key and public key inside the TEE are used as an asymmetric key pair. The private key is stored inside the TEE and cannot be obtained by anyone except the TEE. Its security is guaranteed by the TEE. The public key is partially public and signed by the TEE private key. It can be submitted to the TEE manufacturer for validity verification, which is the case for both the client and the server. The process is as follows:

[0082] (1) The HANG client initiates a mTLS handshake request to the HANG server. In this handshake, the client provides mTLS general information such as random numbers.

[0083] (2) After receiving the handshake request from the client, the server provides the client with mTLS general information such as the public key, certificate information, and random number of the TEE where the server is located;

[0084] (3) After receiving the return information from the server, the client verifies with the TEE manufacturer whether the TEE to which the server belongs is authentic and valid. If so, the client takes out the TEE public key provided by the server and uses the public key to encrypt the data to be transmitted by the client. The data transmitted by the client at this time includes the public key and certificate information of the TEE to which it is located, as well as the general information of mTLS. Otherwise, the client terminates the connection establishment.

[0085] (4) After receiving the message from the client, the server verifies with the TEE manufacturer whether the TEE to which the client belongs is authentic and valid. If so, it retrieves the TEE public key provided by the client and uses the public key to encrypt the data to be transmitted by the server. At this time, the data transmitted by the server includes mTLS general information.

[0086] The entire mTLS process uses the asymmetric key pair of TEE to establish a connection, thereby ensuring that the data transmitted in the gateway is still ciphertext data. These data can only be encrypted and decrypted in TEE, thus eliminating the risk of leakage during data transmission. HANG's application layer protocol follows the design of the mTLS protocol as a whole, replacing the original mTLS asymmetric key pair with the asymmetric key pair in TEE, and embedding TEE remote attestation related information into the X509 certificate extension. During the establishment of the mTLS handshake, TEE remote attestation related work is completed to achieve zero trust, that is, the client only trusts the TEE manufacturer and the application under the TEE, but not the client and server gateways. By using the TEE public key to encrypt user data, it is ensured that the data in the data link transmission is encrypted data rather than plaintext data, and the decryption of the data can only be performed in TEE. Even if there is a problem during data transmission, it will not cause user data leakage. HANG based on mTLS can achieve secure zero-trust network communication when both the client and the server are under TEE, solving the communication and trust issues between heterogeneous TEEs. It not only ensures the establishment of a secure channel during the communication process, but also ensures that user data will not be exposed outside the trusted environment in any form.

[0087] 4. Detailed communication process

[0088] like Figure 4 As shown in the figure, for a two-way authentication scenario, there are two users A and B, and a service provider C. For user A, he runs an application A locally in the TDX environment. He expects to run two applications in the service provider, one application A-1 needs to run in the SGX environment, and one application A-2 runs in any environment; for user B, he runs two applications B-1 and B-2 locally, in the SGX and TDX environments respectively. He expects to run one application in the service provider, and the application B-3 needs to run in the TDX environment.

[0089] In this scenario, the service provider needs to prepare three HANG gateways. One main gateway is located on the server side, and its main function is to complete the basic functions of the gateway, such as traffic forwarding and rate control. The two sub-gateways are located under TEEs such as SGX and TDX. In addition, the service provider needs to obtain the user's application in advance and run it in the corresponding environment according to the user's needs. The service provider also needs to provide the TEE type to the user so that the user can verify the authenticity of the TEE. At the same time, the service provider needs to configure the client's TEE type in the service terminal gateway for subsequent verification of the client's TEE.

[0090] In this scenario, user B needs to deploy three HANG gateways in advance, one main gateway is located on the client, and two sub-gateways are located under the TEEs of the two applications. User B can verify the integrity of the client gateway through the verification value. In addition, user B also needs to configure the service provider TEE type in the two sub-gateways respectively, so that the sub-gateways can verify the authenticity of the TEE; user B also needs to configure the evidence of the application running on the server, so that the sub-gateways can verify the integrity of the application running in the TEE. At the same time, user B needs to provide the TEE type of the application to the service provider so that the server can verify the authenticity of the client TEE.

[0091] After the preparation is completed, the next step is communication. For users, according to the specific application scenario, you can choose to configure a forward or reverse proxy in the gateway. I will not elaborate on this here and will directly summarize it with the objects of user communication.

[0092] User B, whose application B-1 in SGX wants to interact with application B-3 in TDX, and application B-2 in TDX wants to interact with application B-3 in TDX. The traffic flow of data interacting with B-1 and B-3 is as follows:

[0093] Application B-1 first initiates a connection establishment request. The traffic starts from application B-1 and passes through the client sub-gateway of B-1. The client sub-gateway will forward the traffic to the client main gateway, which will match and forward it to the server main gateway. The server main gateway identifies the communication object corresponding to the traffic and forwards the traffic to the TDX environment where B-3 is located, and it is received by the server sub-gateway in TDX. After receiving the connection establishment request, the server sub-gateway returns the TEE remote attestation related information of the server application containing TDX information to application B-1, and the traffic is transmitted back to the client sub-gateway under SGX. After receiving the message from application B-1 under TDX, the client sub-gateway first verifies the TEE remote attestation related information of the server application. At this time, the client sub-gateway The gateway will verify the evidence of TEE type (TDX) and application B-3, including the authenticity of TDX and the integrity of the application; after the verification, the client sub-gateway of application B-1 will return the TEE remote attestation related information of the client application containing SGX to application B-3; the traffic is transmitted to the service sub-gateway of B-3 application under TDX again, which will verify the TEE remote attestation related information of the client application from the client sub-gateway. At this time, the service sub-gateway will hand over the TEE type (SGX) to the TEE manufacturer for verification; after the verification, the service sub-gateway of application B-3 will continue to complete the remaining mTLS handshake connection. This part is the same as the normal mTLS protocol. The client and the server jointly negotiate a symmetric key for subsequent session communications.

[0094] For the data exchanged between user A and A-2, the traffic flow is similar to the above process, which is basically consistent with the mTLS protocol process and does not involve the remote attestation process in the HANG architecture. User B is similar. In this scenario, it is only necessary to match the traffic forwarding rules on the server-side main gateway. In this scenario, the real connection is actually established between the client gateway and the server-side sub-gateway, and the server-side main gateway only performs the function of traffic forwarding.

[0095] The specific implementation methods described above provide a detailed description of the technical solutions and beneficial effects of the present invention. It should be understood that the above is only the most preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, supplements and equivalent substitutions made within the scope of the principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A gateway-based heterogeneous TEE authentication method, characterized in that: The following steps are involved: Deploy each client application in a non-TEE or at least one type of TEE, and deploy each server application in at least one type of TEE, or deploy each server application in a non-TEE and at least one type of TEE; Configure a client sub-gateway for each client application deployed in TEE, connect all client sub-gateways and client applications deployed in non-TEE to the same client main gateway, configure a server sub-gateway for each server application deployed in TEE, connect all service sub-gateways and server applications deployed in non-TEE to the same server main gateway; One-way heterogeneous TEE authentication is implemented between the client and the server based on TLS or two-way heterogeneous TEE authentication is implemented based on mTLS. During the authentication process, the TEE remote attestation related information of the TEE where each application is located is embedded into TLS or mTLS through the service sub-gateway or the client sub-gateway, and is monitored and forwarded through the client main gateway and the server main gateway. The client sub-gateway or the service sub-gateway verifies the received TEE remote attestation related information. After the verification is passed, the heterogeneous TEE authentication and secure channel establishment are completed; The TEE remote attestation related information includes TEE quote and evidence. TEE quote contains hardware information used to prove the authenticity and security of the server-side TEE hardware device, and evidence contains status information of the application running in TEE.

2. The gateway-based heterogeneous TEE authentication method according to claim 1, characterized in that: In the one-way heterogeneous TEE authentication scenario, the client gateway is deployed, including: For single-client application scenarios, the client gateway is deployed in the same environment as the client application. The client gateway here includes the functions of the client main gateway and the client sub-gateway. For multi-client application scenarios, the client main gateway is deployed in an environment that is trustworthy to multiple client applications. After the environment deployment of the client main gateway is completed, configuration is performed in the client main gateway. The configuration information includes: the TEE supported by the application running on the server, the evidence of the application running under the TEE, and the network address of the server sub-gateway.

3. The gateway-based heterogeneous TEE authentication method according to claim 2, characterized in that: In the one-way heterogeneous TEE authentication scenario, the server gateway is deployed, including: For single-server application scenarios, the server gateway is deployed in the same TEE environment as the server application. The server gateway includes the functions of the server main gateway and the server sub-gateway. For multi-server application scenarios, the server main gateway is deployed in any environment, and the server sub-gateway is deployed in the same TEE environment as the corresponding server application. After completing the environment deployment of the server-side main gateway and sub-gateway, configure it in the server-side sub-gateway. The configuration information includes: the TEE where the server-side application is located.

4. The gateway-based heterogeneous TEE authentication method according to claim 3 is characterized in that: The authentication process in the one-way heterogeneous TEE authentication scenario includes: The client user initiates a connection establishment request. The traffic starts from the client application, passes through the client main gateway, and is forwarded to the server main gateway in the client main gateway. The server main gateway further forwards the traffic to the corresponding server sub-gateway. After receiving the connection establishment request, the server sub-gateway returns the traffic containing the TEE remote attestation related information of the server application to the client main gateway. After receiving the return traffic, the client main gateway compares the evidence in the received TEE remote attestation related information of the server application with the configured evidence, and submits the TEE quote to the TEE hardware manufacturer for verification. After the verification is passed, the remaining TLS handshake connection is completed, and the client and server jointly negotiate a symmetric key for subsequent session communications.

5. The gateway-based heterogeneous TEE authentication method according to claim 1, characterized in that: In the bidirectional heterogeneous TEE authentication scenario, the client gateway is deployed, including: For single-client application scenarios, the client gateway is deployed in the same TEE environment as the client application. The client gateway includes the functions of the client main gateway and the client sub-gateway. For multi-client application scenarios, the client main gateway is deployed in any environment, and the client sub-gateway is deployed in the same TEE environment as the corresponding client application. After completing the environment deployment of the client main gateway and sub-gateway, configure it in the client sub-gateway. The configuration information includes: the TEE type of the application running on the server, the evidence of the application running under the TEE, the network address of the server sub-gateway, and the TEE where the client application is located.

6. The gateway-based heterogeneous TEE authentication method according to claim 5, characterized in that: In the bidirectional heterogeneous TEE authentication scenario, the server gateway is deployed, including: For single-server application scenarios, the server gateway is deployed in the same TEE environment as the server application. The server gateway includes the functions of the server main gateway and the server sub-gateway. For multi-server application scenarios, the server main gateway is deployed in any environment, and the server sub-gateway is deployed in the same TEE environment as the corresponding server application. After completing the environment deployment of the server-side main gateway and sub-gateway, configure it in the server-side sub-gateway. The configuration information includes: the TEE type of the client and the TEE where the server-side application is located.

7. The gateway-based heterogeneous TEE authentication method according to claim 6, characterized in that: The authentication process in the bidirectional heterogeneous TEE authentication scenario includes: The client user initiates a connection establishment request. The traffic starts from the client application and passes through the client sub-gateway. The client sub-gateway forwards the traffic to the client main gateway, which then forwards the traffic to the server main gateway. The server main gateway further forwards the traffic to the corresponding server sub-gateway. After receiving the connection establishment request, the server sub-gateway returns the traffic containing the TEE remote attestation related information of the server application to the client sub-gateway. After receiving the return traffic, the client sub-gateway compares the evidence in the received TEE remote attestation related information of the server application with the configured evidence, and submits the TEE quote to the TEE hardware manufacturer for verification. After the verification is successful, the client sub-gateway returns the TEE remote attestation related information of the client application to the server sub-gateway. The traffic returns to the server sub-gateway via the client main gateway and the server main gateway. After receiving the return traffic, the server sub-gateway submits the TEE quote in the received TEE remote attestation related information of the client application to the TEE hardware manufacturer for verification. After the verification is successful, the remaining mTLS handshake connection is completed, and the client and the server jointly negotiate a symmetric key for subsequent session communication.

8. The gateway-based heterogeneous TEE authentication method according to claim 1, characterized in that: During the authentication process, by modifying the extension field of the X509 certificate in TLS or mTLS, the field containing TEE quote related information is embedded into the extension field of the X509 certificate according to different authentication scenarios, and then the TEE quote related information is extracted from the extension field of the X509 certificate to complete the relevant verification.

9. The gateway-based heterogeneous TEE authentication method according to claim 2, characterized in that: In the one-way heterogeneous TEE authentication scenario, the source code of the client main gateway and sub-gateway is open source for auditing.

10. The gateway-based heterogeneous TEE authentication method according to claim 6, characterized in that: In the bidirectional heterogeneous TEE authentication scenario, the source code of the client main gateway and sub-gateway as well as the server main gateway and sub-gateway are open source for audit.

Images