A gateway-based heterogeneous TEE authentication method

Abstract

This invention discloses a gateway-based heterogeneous TEE authentication method, comprising: deploying each client application in a non-TEE or at least one type of TEE, and deploying each server application in at least one type of TEE or including both non-TEE and at least one type of TEE; configuring a client sub-gateway for each client application deployed in the TEE, connecting all client sub-gateways and non-TEE client applications to the client main gateway; configuring a server sub-gateway for each server application deployed in the TEE, connecting all server sub-gateways and non-TEE server applications to the server main gateway; and implementing one-way heterogeneous TEE authentication between the client and server based on TLS or two-way heterogeneous TEE authentication based on mTLS. This invention enables heterogeneous TEE authentication based on TLS or mTLS and simultaneously establishes a secure channel within a heterogeneous authentication gateway framework.

Description

Technical Field

[0001] This invention belongs to the field of network gateway communication technology, and specifically relates to a heterogeneous TEE authentication method based on a gateway. Background Technology

[0002] With the development of information technology, in today's digital age, cybersecurity has not only become a focal point in the technological field but also profoundly impacts the stability and development of society and the economy. With the explosive growth of data volume and the acceleration of data flow, ensuring the security and privacy of network data has become an indispensable strategic task. Although technological advancements have brought unprecedented convenience, frequent data breaches and privacy violations have made individuals, businesses, and society at large acutely aware of the importance of data protection, placing higher demands on encryption technologies for data transmission and the security of data storage.

[0003] Driven by this trend, hardware-level security technologies have developed rapidly. Technologies such as Intel's SoftwareGuard Extensions (SGX), ARM's Trust Zone, Hygon's Crypto Secure Virtualization (CSV), and AMD's Secure Encrypted Virtualization (SEV) are all dedicated to building Trusted Execution Environments (TEEs). TEEs, by providing an isolated and protected computing area, are widely used to enhance the security of various types of critical infrastructure, including trusted monitoring and secure node construction. Currently, some work has been carried out using TEEs to protect critical infrastructure. These technologies have built a solid defense for user data, ensuring the confidentiality and integrity of information during processing. However, facing a diverse and independently operating TEE ecosystem, users often encounter complex remote authentication processes when migrating or interacting across environments. This not only requires users to have certain technical knowledge but also adds additional management and operational burdens. Although these TEE technologies are very similar in principle, their details and authentication processes differ significantly, and it is difficult to make TEEs from different vendors compatible. Trusted communication between different TEEs is a significant problem. Even devices using the same TEE technology may fail to work together. This is because while an organization can establish its own root of trust authentication service to support all TEE-enabled devices, this service cannot identify devices belonging to other organizations. Establishing secure communication channels between heterogeneous TEEs is a pressing issue that needs to be addressed.

[0004] Meanwhile, 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 seamless end-to-end security remains an area that urgently needs exploration.

[0005] Therefore, in the face of security challenges in the digital age, the development of TEE technology has provided us with a powerful means of protection. However, to achieve the widespread application and deep integration of TEE technology, further research is needed on how to solve problems such as heterogeneous TEE authentication, secure channel establishment, and integration with the TLS protocol. Summary of the Invention

[0006] In view of the above, the purpose of this invention is to provide a gateway-based heterogeneous TEE authentication method. By designing and implementing a heterogeneous authentication network gateway (HANG) for serverless computing, the privacy and security of user data transmission and storage in a serverless computing environment are ensured. Specific objectives include: (1) Implementing a heterogeneous authentication gateway: Deploying gateways designed and open-sourced by HANG on both the client and server sides, including sub-gateway and main gateway structures, 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 serverless computing frameworks, enabling users to use the HANG gateway for secure communication without modifying existing applications; (4) Providing open-source review: Ensuring the security and trustworthiness of the system by open-sourcing the gateway code for community review.

[0007] To achieve the above-mentioned objectives, the present invention provides the following technical solution:

[0008] This invention provides a gateway-based heterogeneous TEE authentication method, comprising the following steps:

[0009] Each client application is deployed in a non-TEE or at least one type of TEE, and each server application is deployed in at least one type of TEE, or each server application is deployed in a TEE that includes both non-TEE and at least one type of TEE.

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

[0011] One-way heterogeneous TEE authentication is implemented between the client and server based on TLS, or two-way heterogeneous TEE authentication is implemented based on mTLS. During the authentication process, the TEE remote proof information of the TEE where each application is located is embedded into TLS or mTLS through the server sub-gateway or client sub-gateway. The client main gateway and server main gateway listen for and forward the information. Then, the client sub-gateway or server sub-gateway verifies the received TEE remote proof information. Once the verification is successful, the heterogeneous TEE authentication and secure channel establishment are completed. The TEE remote proof information includes TEE quote and evidence. The TEE quote contains hardware information used to prove the authenticity and security of the server TEE hardware device, and the evidence contains the application's running status information in the TEE.

[0012] Specifically, in a 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. Here, the client gateway includes the functions of the main client gateway and the client sub-gateway. For multi-client application scenarios, the main client gateway is deployed in an environment that is trusted by multiple client applications.

[0014] After completing the environment deployment on the client main gateway, configure it. The configuration information includes: the TEE supported by the user's application running on the server, the evidence that the application runs under that TEE, and the network address of the server sub-gateway.

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

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

[0017] After completing the environment deployment for the server-side main gateway and sub-gateways, configure the server-side sub-gateways. The configuration information includes the TEE where the server-side application resides.

[0018] Specifically, the authentication process in a unidirectional heterogeneous TEE authentication scenario includes:

[0019] The client user initiates a connection establishment request. Traffic originates from the client application, passes through the client's main gateway, and is then forwarded to the server's main gateway. The server's main gateway further forwards the traffic to the corresponding server sub-gateway. Upon receiving the connection establishment request, the server sub-gateway returns traffic containing the server application's TEE remote authentication information to the client's main gateway. Upon receiving the returned traffic, the client's main gateway compares the received evidence in the server application's TEE remote authentication information with the configured evidence and simultaneously submits the TEE quote to the TEE hardware vendor for verification. After successful verification, the remaining TLS handshake connection is completed, and the client and server jointly negotiate a symmetric key for subsequent session communication.

[0020] Specifically, in a 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, and the client gateway includes the functions of the main client gateway and the client sub-gateway; for multi-client application scenarios, the main client 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 for the client's main gateway and sub-gateways, configure the client's sub-gateway. The configuration information includes: the TEE supported by the user's application running on the server, the evidence that the application runs under that TEE, the network address of the server's sub-gateway, and the TEE where the client application is located.

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

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

[0025] After completing the environment deployment for the main gateway and sub-gateways on the server side, configure the sub-gateways on the server side. The configuration information includes: the TEEs supported by the server and the TEE on which the server application resides.

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

[0027] The client user initiates a connection establishment request. Traffic originates from the client application, passes through the client sub-gateway, and is forwarded to the client main gateway. The client main gateway then forwards the traffic to the server main gateway, which further forwards it to the corresponding server sub-gateway. Upon receiving the connection establishment request, the server sub-gateway returns the traffic containing the server application's TEE remote authentication information to the client sub-gateway. Upon receiving the returned traffic, the client sub-gateway compares the received evidence from the server application's TEE remote authentication information with the configured evidence and simultaneously submits the TEE quote to the TEE hardware vendor for verification. After successful verification, the client sub-gateway returns the client application's TEE remote authentication information to the server sub-gateway. The traffic then returns to the server sub-gateway via the client main gateway and the server main gateway. Upon receiving the returned traffic, the server sub-gateway submits the received TEE quote from the client application's TEE remote authentication information to the TEE hardware vendor for verification. After successful verification, the remaining mTLS handshake connection is completed, and the client and server jointly negotiate a symmetric key for subsequent session communication.

[0028] Specifically, during the authentication process, the extended fields of the X509 certificate in TLS or mTLS are modified. Depending on the authentication scenario, fields containing TEE quote information are embedded into the extended fields of the X509 certificate, and then the TEE quote information is extracted from the extended fields of the X509 certificate to complete the relevant verification.

[0029] Specifically, in a one-way heterogeneous TEE authentication scenario, the source code of the client's main gateway and sub-gateways will be open-sourced for auditing purposes.

[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, will be open-sourced for auditing purposes.

[0031] Compared with the prior art, the beneficial effects of the present invention include at least the following:

[0032] By deploying open-source heterogeneous authentication gateways on both the client and server sides, seamless communication with high security and privacy protection is achieved. Users do not need to modify existing applications; they only need to send and receive messages through a HANG gateway structure that includes the deployment of sub-gateways and the main gateway to complete remote authentication and encrypted data transmission. By modifying the extended fields of the X.509 certificate, TEE remote authentication information is embedded, ensuring that the client and server can verify the validity and authenticity of each other's TEEs through certificates. In two-way authentication scenarios, TEE technology and mTLS two-way authentication can achieve a zero-trust architecture, ensuring the security and integrity of data transmission. Furthermore, by open-sourcing the gateway code for review, system trust is enhanced, and by optimizing gateway performance, efficient and stable operation and flexible scalability are ensured in serverless computing environments. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart illustrating a heterogeneous TEE authentication method based on a gateway provided in an embodiment of the present invention;

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

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

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

[0038] Figure 5 This is a schematic diagram of the mTLS process in HANG two-way authentication provided in an embodiment of the present invention. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the scope of protection of this invention.

[0040] Addressing the challenges of existing technologies, a heterogeneous authentication gateway for serverless computing offers a promising solution. As an innovative solution, it deploys open-source gateways on both the client and server sides, specifically designed to simplify remote authentication via TEEs, providing users with unprecedented convenience and security. The introduction of the trusted gateway essentially builds a bridge between users and the authentication infrastructure. This bridge, presented in an open-source format, ensures transparency in the authentication process while significantly reducing the learning and adaptation costs for users. The trusted gateway operates by allowing users to delegate all remote authentication steps to it simply by installing the client gateway, without needing to delve into the specific implementation and technical details of the underlying TEE. This design not only greatly simplifies the user's workflow but also enables existing applications to seamlessly integrate with various TEEs without any code-level adjustments, achieving true plug-and-play functionality. In this way, the trusted gateway not only strengthens secure collaboration across TEEs but also promotes the openness and sharing of the security ecosystem, laying a solid foundation for building a more robust and trustworthy digital world.

[0041] Based on this, the inventive concept of this invention is as follows: Addressing the challenges of heterogeneous TEE authentication and the integration of various TEEs with TLS protocols in existing technologies, this invention provides a gateway-based heterogeneous TEE authentication method. Depending on the environment of the client and server applications, corresponding client sub-gateways or server sub-gateways are deployed for all applications under each TEE to implement heterogeneous TEE authentication. Client main gateways and server main gateways are deployed for traffic monitoring and forwarding. Remote authentication is completed during the communication channel establishment process based on TLS or mTLS, ensuring secure communication between the client application and the server, and improving system response speed and efficiency.

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

[0043] 1. TEE

[0044] Within the entire HANG framework, server-side applications must be deployed within a TEE (Threaded Equipment). In cloud storage systems, user privacy data is stored on the server; in cloud computing systems, users need to transmit data to the server for computation; in cloud communication systems, the server also backs up user communication data. This data is all user privacy data and cannot be leaked; therefore, server-side applications must run within a TEE.

[0045] 2. Gateway Proxy

[0046] In the HANG framework, both server-side and client-side applications communicate directly with their respective gateways. It is precisely through these gateways that HANG enables seamless communication between client-side and server-side applications located in heterogeneous TEEs. HANG's gateway consists of two parts: a client-side gateway and a server-side gateway. The server-side gateway is responsible for proxying messages from the server and providing remote authentication information for the TEE where the client resides when establishing communication with the client gateway. The client-side gateway is responsible for proxying messages from the client and verifying the validity of the TEE remote authentication information from the server gateway when establishing communication with the server gateway. By integrating the TEE remote authentication process with the secure communication channel establishment process, HANG achieves secure channel establishment and seamless communication between client and server applications.

[0047] 3. X509 Certificate

[0048] In the HANG framework, the establishment of a secure channel relies on TEE remote authentication, which includes a TEE quote and evidence. The TEE quote contains hardware information used to prove the authenticity and security of the server-side TEE hardware device, while the evidence contains the application's running status information within the TEE. This step involves modifying the extended fields of the X.509 certificate, embedding the TEE quote information into the X.509 certificate extended fields by the server / client gateway, and then having the client / server gateway extract the information from the X.509 certificate extended fields and complete the relevant verification.

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

[0050] (I) One-way authentication scenario

[0051] In the embodiments, such as Figure 3The diagram shown is a HANG architecture design for a one-way authentication scenario. In this scenario, only the server application is located in the TEE, while the default HANG client application and client gateway are located in the trusted environment.

[0052] 1. Client Communication Model

[0053] In the HANG architecture, one or more client applications communicate with the main client gateway. The communication protocol between the client application and the main client gateway is not critical; any protocol supported by both is acceptable. For single-client application scenarios, the main client gateway can be deployed directly in the same environment as the client application. For multi-client application scenarios, the main client gateway should be deployed in an environment trusted by all client applications. Security considerations for this part are the user's responsibility. Both the client applications and the main client gateway need to be deployed by the user; authentication of the server-side TEE is included within the main client gateway.

[0054] After completing the environment deployment on the client-side main gateway, configuration is performed on the client-side main gateway. Configuration information includes: the TEE supported by the user's application running on the server, the evidence that the application runs under that TEE, and the network address of the server-side sub-gateway. Applications running under the server-side TEE provide their evidence to the user so that the user can verify that the application running on the server is the application the user expected and has not been modified. The TEE quote is generated by the TEE vendor to inform the user that the server-side application is running on this TEE device. The TEE quote can be submitted to the TEE vendor for verification of its validity to ensure that the application running by the user is indeed running on a genuine TEE produced by the TEE vendor.

[0055] The deployment of the client-side main gateway is completed by the user. The source code of this part of the gateway is open source and is available for user auditing in an auditable manner to ensure that the client-side gateway is trustworthy to the user and will not engage in any malicious behavior towards user data.

[0056] 2. Server-side communication model

[0057] In the HANG architecture, one or more server-side applications communicate with the main server gateway and server-side sub-gateways. The communication protocol between the server-side application and the main server gateway / sub-gateways is not required; any protocol supported by both the main server gateway, server-side sub-gateways, and server-side application is acceptable. For a single server-side application scenario, the server gateway is deployed on the TEE where the server-side application resides. For a multi-server-side application scenario, a main server gateway needs to be deployed. The deployment of the main server gateway is not required, as long as it can communicate well with multiple server-side applications. Each server-side application needs to be deployed on a separate TEE, and each server-side application requires an additional server-side sub-gateway to implement remote authentication functionality.

[0058] After deployment, the server-side main gateway needs to be configured with the communication protocol between itself and each server-side sub-gateway, and the server-side sub-gateways need to be configured with their respective TEEs to facilitate subsequent communication with client gateways and the provision of TEE remote verification information.

[0059] The main gateway and sub-gateways on the server side are open-source for user auditing to ensure no malicious activity occurs. Users can audit the server-side gateway code and verify whether it is the open-source gateway they expect; if not, users can choose to refuse communication with it.

[0060] 3. Detailed Communication Process

[0061] like Figure 3 As shown, in a one-way authentication scenario, there are two users, A and B, and one service provider, C. User A wants to run two applications on the service provider's platform: application A-1 in an SGX environment and application A-2 in any environment. User B wants to run one application on the service provider's platform, application B-1, in a TDX environment. This scenario assumes all gateways are open-source.

[0062] In this scenario, the service provider needs to prepare three HANG gateways: a main gateway located on the server side, primarily responsible for basic gateway functions such as traffic forwarding and rate control; and two sub-gateways located under TEEs such as SGX and TDX. Furthermore, the service provider needs to obtain the user's application in advance and run it in the appropriate environment according to the user's requirements. The service provider also needs to inform the user of the TEE type beforehand, allowing the user to know the TEE type of their application and verifying 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. Furthermore, users need to configure the evidence information of the applications running on the server so that the gateway can verify the integrity of the applications running in the TEE.

[0064] After the preparation is complete, the next step is communication. For users, depending on the specific application scenario, they can choose to configure forward or reverse proxy in the gateway. We will not go into too much detail here, but will simply use the objects that users communicate with as an example.

[0065] User A wants to interact with application A-1 located in the SGX environment on some data, and with application A-2 on other data. For the data interacting with A-1, User A's traffic flow is as follows:

[0066] User A initiates a connection establishment request. Traffic originates from application A, passes through the client's main gateway, where it is matched and forwarded to the server's main gateway. The server's main gateway identifies the communication object corresponding to the traffic and forwards it to the SGX environment where A-1 resides, where it is received by the server's sub-gateway. Upon receiving the connection establishment request, the server's sub-gateway returns the TEE remote authentication information of the server application, including SGX information, to user A. The traffic is then transmitted back to the client's main gateway. After receiving the message from application A-1, the client's main gateway first verifies the TEE remote authentication information of the server application. At this point, the client's main gateway verifies the TEE type (SGX) and the evidence of application A-1, including the authenticity of the SGX and the integrity of the application. After successful verification, the remaining TLS handshake connection is completed. This part is the same as the normal TLS protocol, where the client and server jointly negotiate a symmetric key for subsequent session communication.

[0067] For the data exchanged between users A and A-2, the traffic flow is similar to the process described above, basically consistent with the TLS protocol process, but without involving the authentication process in the HANG architecture. The same applies to user B; in this scenario, only the traffic forwarding rules need to be matched on the server-side main gateway. In this scenario, the actual connection is established between the client-side main gateway and the server-side sub-gateway; the server-side main gateway merely performs the function of traffic forwarding.

[0068] (II) Two-way authentication scenario

[0069] In the embodiments, such as Figure 4 The diagram shown is a HANG architecture design for a two-way authentication scenario, in which both the server-side application and the client-side application reside in the TEE.

[0070] 1. Client Communication Model

[0071] In the HANG architecture, one or more client applications communicate with both the main client gateway and the sub-client gateways. The communication protocol between the client application and these gateways is not critical; any protocol supported by the main gateway, sub-gateways, and client application is acceptable. For single-client applications, the client gateway can be deployed directly on the TEE (Telecommunication Equipment Environment) where the client application resides. For multi-client applications, users need to deploy a main client gateway, and each client application needs a sub-gateway. Security in this part is guaranteed by the TEE; each client application is protected by the TEE. The main client gateway can be located in any environment and only has traffic forwarding functionality. Both client applications and client gateways need to be deployed by the user; authentication of the server-side TEE is included in the sub-client gateways.

[0072] After deployment, users need to configure the client sub-gateway. Configuration information includes: the TEE type of the user's application running on the server, evidence of the application running on that TEE, the network address of the server sub-gateway, and the TEE type of the client application. This is for TEE remote authentication during subsequent communication with the server sub-gateway. Applications running on the server-side TEE provide their evidence to the user so that the user can verify that the application running on the server is the intended application and has not been modified. The TEE quote is generated by the TEE vendor to inform the user that the server-side application is running on this TEE device. The TEE quote can be verified by the TEE vendor to ensure its validity, guaranteeing that the application running by the user is indeed running on a genuine TEE produced by the vendor.

[0073] The client gateway deployment is handled by the user. The source code of the client sub-gateway is open source and auditable by the user to ensure that the client gateway is trustworthy and will not engage in any malicious behavior towards user data. The client main gateway is not required to perform high-performance traffic forwarding.

[0074] 2. Server-side communication model

[0075] In the HANG architecture, one or more server-side applications communicate with the main server gateway and server-side sub-gateways. The communication protocol between the server-side application and the main server gateway / sub-gateways is not required; any protocol supported by both the main server gateway, server-side sub-gateways, and server-side application is acceptable. For a single server-side application scenario, the server gateway is deployed on the TEE where the server-side application resides. For a multi-server-side application scenario, a main server gateway needs to be deployed. The deployment of the main server gateway is not required, as long as it can communicate well with multiple server-side applications. Each server-side application needs to be deployed on a separate TEE, and each server-side application requires an additional server-side sub-gateway to implement remote authentication functionality.

[0076] After deployment, the main server gateway needs to be configured with the communication protocols between itself and each sub-server gateway, and the sub-server gateways need to be configured with their respective TEEs to facilitate subsequent communication with client gateways and the provision of TEE remote verification information. The sub-server gateways also need to be configured with the TEE type of their clients to facilitate subsequent verification of client TEEs.

[0077] The server-side sub-gateways are open-source for user auditing to ensure no malicious activity occurs. Users can audit the server-side gateway code and verify whether it is the open-source gateway they expect. If not, users can choose to refuse communication with it. The main server-side gateway is not required; it only needs to perform high-performance traffic forwarding.

[0078] 3. Zero-trust application layer protocol

[0079] like Figure 5 The diagram shown is a schematic of the bidirectional mTLS process based on remote authentication in the HANG gateway designed in this invention.

[0080] In one-way TEE authentication, the highest level of security achievable is that both the client and server gateways are open-source and auditable, ensuring the absence of malicious behavior in their operational logic. However, this cannot prevent the leakage of private data if the gateway is compromised, or the service provider maliciously leaking users' plaintext private data. To avoid this, a zero-trust model is designed for HANG in two-way TEE authentication. Its basic principle is similar to the TLS protocol. In the HANG model, the CA center is the TEE vendor, and the public key used is the public key in the TEE.

[0081] Specifically, the private and public keys inside the TEE are used as an asymmetric key pair. The private key is stored inside the TEE and cannot be obtained by anyone other than the TEE. Its security is guaranteed by the TEE. The public key is partially public and is signed using the TEE's private key. The signature can be submitted to the TEE vendor for validity verification. This process applies to both the client and server sides. The procedure is as follows:

[0082] (1) The HANG client initiates an mTLS handshake request to the HANG server. During this handshake, the client provides mTLS routine 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 vendor whether the TEE to which the server belongs is genuine and valid. If it is, the client retrieves the TEE public key provided by the server and uses the public key to encrypt the data that the client is about to transmit. The data transmitted by the client at this time includes the public key and certificate information of the TEE to which it belongs, as well as mTLS general information; otherwise, the client terminates the establishment of the connection.

[0085] (4) After receiving the message returned by the client, the server verifies with the TEE vendor whether the TEE to which the client belongs is genuine and valid. If it is, the server retrieves the TEE public key provided by the client and uses the public key to encrypt the data that the server is about to transmit. At this time, the data transmitted by the server includes mTLS regular information.

[0086] The entire mTLS process establishes a connection using the TEE's asymmetric key pair, ensuring that data transmitted through the gateway remains encrypted. Encryption and decryption can only be performed within the TEE, eliminating the risk of data leakage during transmission. HANG's application layer protocol largely adopts the mTLS design, replacing the original mTLS asymmetric key pair with one from the TEE. TEE remote authentication information is embedded in the X.509 certificate extension, completing the TEE remote authentication process during the mTLS handshake to achieve zero trust. The client only trusts the TEE vendor and the application running under the TEE, not the client or the server gateway. By encrypting user data using the TEE public key, it ensures that data transmitted over the data link is encrypted, not plaintext. Decryption can only occur within the TEE, preventing data leakage even if problems occur during data transmission. HANG based on mTLS enables secure zero-trust network communication where both the client and server are under a TEE, solving the communication and trust issues between heterogeneous TEEs. It not only ensures the establishment of secure channels during communication but also guarantees 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 a two-way authentication scenario, there are two users, A and B, and one service provider, C. User A runs application A locally in a TDX environment and wants to run two applications on the service provider's platform: application A-1 in an SGX environment and application A-2 in any environment. User B runs two applications, B-1 and B-2, locally in SGX and TDX environments respectively. User B wants to run one application on the service provider's platform, application B-3, in a TDX environment.

[0089] In this scenario, the service provider needs to prepare three HANG gateways: a main gateway located on the server side, primarily responsible for basic gateway functions such as traffic forwarding and rate control; and two sub-gateways located under TEEs such as SGX and TDX. Furthermore, the service provider needs to obtain the user's application in advance and run it in the appropriate environment according to the user's requirements. The service provider also needs to provide the user with the TEE type so that the user can verify the TEE's authenticity. Simultaneously, the service provider needs to configure the client's TEE type in the server's sub-gateways for subsequent client TEE verification.

[0090] In this scenario, User B needs to pre-deploy three HANG gateways: one main gateway located on the client side, and two sub-gateways located under the TEEs of the two applications, respectively. User B can verify the integrity of the client gateway using a checksum. Furthermore, User B needs to configure the service provider's TEE type in the two sub-gateways so that the sub-gateways can subsequently verify the authenticity of the TEE. User B also needs to configure the evidence of the application running on the server side so that the sub-gateways can subsequently verify the integrity of the application running in the TEE. Finally, User B needs to provide the service provider with the TEE type of the application so that the server can verify the authenticity of the client TEE.

[0091] After the preparation is complete, the next step is communication. For users, depending on the specific application scenario, they can choose to configure forward or reverse proxy in the gateway. We will not go into too much detail here, but will simply use the objects that users communicate with as an example.

[0092] User B's application B-1, located in the SGX environment, wants to interact with application B-3, located in the TDX environment. Similarly, application B-2, located in the TDX environment, wants to interact with application B-3 in the TDX environment. The data flow for the interaction between B-1 and B-3 is as follows:

[0093] Application B-1 initiates a connection establishment request. Traffic originates from application B-1, passes through B-1's client sub-gateway, and is forwarded to the client main gateway. The client main gateway matches and forwards the traffic to the server main gateway. The server main gateway identifies the communication object corresponding to the traffic and forwards it to the TDX environment where B-3 resides, where the server sub-gateway in the TDX environment receives it. After receiving the connection establishment request, the server sub-gateway returns the TEE remote authentication information of the server application, containing TDX information, to application B-1. The traffic is then transmitted in reverse to the client sub-gateway under the SGX environment. Upon receiving the message from application B-1 under the TDX environment, the client sub-gateway first verifies the TEE remote authentication information of the server application. At this point, the client subnet... The gateway verifies the TEE type (TDX) and the evidence for application B-3, including the authenticity of the TEE and the integrity of the application. After successful verification, the client sub-gateway of application B-1 returns the TEE remote authentication information of the client application containing the SGX to application B-3. The traffic is then transmitted to the server sub-gateway of application B-3 under the TEE, which verifies the TEE remote authentication information of the client application from the client sub-gateway. At this time, the server sub-gateway will submit the TEE type (SGX) to the TEE vendor for verification. After successful verification, the server 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, where the client and server jointly negotiate a symmetric key for subsequent session communication.

[0094] For the data exchanged between users A and A-2, the traffic flow is similar to the process described above, basically consistent with the mTLS protocol process, and does not involve the remote authentication process in the HANG architecture. The same applies to user B; in this scenario, only the traffic forwarding rules need to be matched on the server-side main gateway. In this scenario, the actual connection is established between the client gateway and the server-side sub-gateways; the server-side main gateway merely performs traffic forwarding.

[0095] The specific embodiments described above illustrate the technical solution and beneficial effects of the present invention in detail. It should be understood that the above description is only the most preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, additions, and equivalent substitutions made within the scope of the principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A gateway-based heterogeneous TEE authentication method, characterized in that, Includes the following steps: Each client application is deployed in a non-TEE or at least one type of TEE, and each server application is deployed in at least one type of TEE, or each server application is deployed in a TEE that includes both non-TEE and at least one type of TEE. Configure a client sub-gateway for each client application deployed on TEE, and connect all client sub-gateways and client applications deployed on non-TEE to the same client main gateway. Configure a server sub-gateway for each server application deployed on TEE, and connect all server sub-gateways and server applications deployed on non-TEE to the same server main gateway. One-way heterogeneous TEE authentication based on TLS or two-way heterogeneous TEE authentication based on mTLS is implemented between the client and the server. During the authentication process, the TEE remote proof information of the TEE where each application is located is embedded into TLS or mTLS through the server sub-gateway or client sub-gateway. The client main gateway and server main gateway listen and forward the information. Then, the client sub-gateway or server sub-gateway verifies the received TEE remote proof information. Once the verification is successful, the heterogeneous TEE authentication and secure channel establishment are completed. The TEE remote verification information includes TEE quote and evidence. The TEE quote contains hardware information used to verify the authenticity and security of the server-side TEE hardware device, and the evidence contains the status information of the application running in the TEE.

2. The gateway-based heterogeneous TEE authentication method according to claim 1, characterized in that, In a unidirectional 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. Here, the client gateway includes the functions of the main client gateway and the client sub-gateway. For multi-client application scenarios, the main client gateway is deployed in an environment that is trusted by multiple client applications. After completing the environment deployment on the client main gateway, configure it. The configuration information includes: the TEE supported by the user's application running on the server, the evidence that the application runs under that 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 a one-way heterogeneous TEE authentication scenario, the server-side gateway is deployed, including: For single-server application scenarios, the server gateway is deployed in the same TEE environment as the server application, and the server gateway includes the functions of the main server gateway and the sub-server gateways; for multi-server application scenarios, the main server gateway is deployed in any environment, and the sub-server gateways are deployed in the same TEE environment as the corresponding server application. After completing the environment deployment for the server-side main gateway and sub-gateways, configure the server-side sub-gateways. The configuration information includes the TEE where the server-side application resides.

4. The gateway-based heterogeneous TEE authentication method according to claim 3, characterized in that, In the authentication process of a unidirectional heterogeneous TEE authentication scenario, the following are included: The client user initiates a connection establishment request. Traffic originates from the client application, passes through the client's main gateway, and is then forwarded to the server's main gateway. The server's main gateway further forwards the traffic to the corresponding server sub-gateway. Upon receiving the connection establishment request, the server sub-gateway returns traffic containing the server application's TEE remote authentication information to the client's main gateway. Upon receiving the returned traffic, the client's main gateway compares the received evidence in the server application's TEE remote authentication information with the configured evidence and simultaneously submits the TEE quote to the TEE hardware vendor for verification. After successful verification, the remaining TLS handshake connection is completed, and the client and server jointly negotiate a symmetric key for subsequent session communication.

5. The gateway-based heterogeneous TEE authentication method according to claim 1, characterized in that, In a 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, and the client gateway includes the functions of the main client gateway and the client sub-gateway; for multi-client application scenarios, the main client 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 for the client's main gateway and sub-gateways, configure the client's sub-gateway. The configuration information includes: the TEE type of the user's application running on the server, the evidence that the application is running under that TEE, the network address of the server's 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 a bidirectional heterogeneous TEE authentication scenario, the server-side gateway is deployed, including: For single-server application scenarios, the server gateway is deployed in the same TEE environment as the server application, and the server gateway includes the functions of the main server gateway and the sub-server gateways; for multi-server application scenarios, the main server gateway is deployed in any environment, and the sub-server gateways are deployed in the same TEE environment as the corresponding server application. After completing the environment deployment for the main gateway and sub-gateways on the server side, configure the sub-gateways on the server side. The configuration information includes: the TEE type of the client and the TEE where the server application is located.

7. The gateway-based heterogeneous TEE authentication method according to claim 6, characterized in that, In the authentication process of bidirectional heterogeneous TEE authentication scenarios, the following are included: The client user initiates a connection establishment request. Traffic originates from the client application, passes through the client sub-gateway, and is forwarded to the client main gateway. The client main gateway then forwards the traffic to the server main gateway, which further forwards it to the corresponding server sub-gateway. Upon receiving the connection establishment request, the server sub-gateway returns the traffic containing the server application's TEE remote authentication information to the client sub-gateway. Upon receiving the returned traffic, the client sub-gateway compares the received evidence from the server application's TEE remote authentication information with the configured evidence and simultaneously submits the TEE quote to the TEE hardware vendor for verification. After successful verification, the client sub-gateway returns the client application's TEE remote authentication information to the server sub-gateway. The traffic then returns to the server sub-gateway via the client main gateway and the server main gateway. Upon receiving the returned traffic, the server sub-gateway submits the received TEE quote from the client application's TEE remote authentication information to the TEE hardware vendor for verification. After successful verification, the remaining mTLS handshake connection is completed, and the client and 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, the extended fields of the X.509 certificate in TLS or mTLS are modified. Depending on the authentication scenario, fields containing TEE quote information are embedded into the extended fields of the X.509 certificate. Then, the TEE quote information is extracted from the extended fields of the X.509 certificate to complete the relevant verification.

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

10. The gateway-based heterogeneous TEE authentication method according to claim 6, characterized in that, In bidirectional heterogeneous TEE authentication scenarios, the source code of the client's main gateway and sub-gateways, as well as the server's main gateway and sub-gateways, will be open-sourced for auditing purposes.

Images