A cross-domain identity authentication method based on SGX

Abstract

A cross-domain identity authentication method based on SGX belongs to the field of Internet of Things identity authentication and solves the technical problems of edge terminal node identity privacy exposure, session insecurity, and high security authentication complexity. The central agent registers on the Intel online identity authentication server, completes trusted authentication, and obtains a remote authentication report as the trusted root of the entire inter-domain trusted network. Each trusted domain establishes a domain proxy server in its own security domain based on the relevant conditions within its own domain, and uses the edge domain agent and the central agent as nodes of the inter-domain trusted network. The edge trusted domain agent obtains trusted authentication by registering and remotely authenticating with the central agent. The two edge domain agents achieve mutual authentication of the trusted state through two-way remote authentication, thereby realizing trust transmission and privacy protection. Through the trusted and secure communication channel established by the two edge domain agents, the identity authentication and key negotiation process of the data requesting terminal node and the data owning node is completed.

Description

Technical Field

[0001] The present invention belongs to the field of Internet of Things identity authentication. Background Art

[0002] Traditional IoT authentication protocols are based on a cloud-based, terminal-device network architecture, but this architecture changes in edge computing environments. In edge computing, device computing and communication are primarily performed at the edge, enabling rapid data collection and transmission. User-side devices are more vulnerable to theft, man-in-the-middle attacks, impersonation, and compromise compared to cloud-based devices. Furthermore, edge computing nodes divide terminal devices into multiple security domains, which often require collaboration between domains. Risks of device eavesdropping, impersonation, and man-in-the-middle attacks exist between different security domains, and secure communication between devices in multiple domains requires cross-domain authentication and key negotiation.

[0003] Typically, multi-cloud inter-domain authentication solutions use a common authentication architecture. However, for heterogeneous inter-domain authentication, where multiple cloud domains each employ different authentication architectures, the authentication architectures of each domain must be redesigned to enable cross-domain authentication using the same authentication architecture. A cross-domain authentication architecture based on key distribution utilizes a public key cryptographic certificate system for authentication. This architecture generates and distributes keys through a key generation center, ensuring security through a series of key calculations and certificate verifications. Recently, designing distributed authentication solutions leveraging the decentralized and tamper-proof properties of blockchain technology has attracted widespread attention. Compared to traditional centralized authentication methods, this design achieves distributed trust authentication. By combining blockchain technology with a centralized authentication system, distributed sharing of identity and operational data is achieved, addressing authentication issues across different security domains.

[0004] Traditional cross-domain authentication architectures based on key distribution cannot ensure the security of key distribution agencies, thereby increasing the risk of privacy leakage and attacks. For example, in scenarios where the scale of devices is large, the centralized authentication server has a large workload and is prone to network congestion and delays. However, solutions based on blockchain technology directly record user operations, which seriously threatens user privacy. At the same time, the process of reaching consensus on the blockchain is cumbersome, the query time complexity for certificates stored on the chain is high, and the certificate revocation mechanism on the chain is not perfect. To solve the above problems, the present invention proposes a secure and reliable cross-domain identity authentication solution for heterogeneous domains. Summary of the Invention

[0005] In response to some of the shortcomings of the above-mentioned existing technologies, the present invention proposes a cross-domain identity authentication solution based on SGX technology to solve the problems of complex authentication mechanisms and large-scale security mechanisms that are difficult to deploy in existing technologies. The method of the present invention introduces edge domain proxy roles and SGX-based remote attestation technology to achieve trusted authentication between the two edge domains by performing remote attestation between the two edge domain proxies, solving the technical problems of edge terminal node identity privacy exposure, session insecurity, and high security authentication complexity.

[0006] The present invention proposes a cross-domain identity authentication scheme based on SGX technology. The central agent registers on the Intel online identity authentication server, completes the trusted authentication and obtains the remote authentication report as the trusted root of the entire inter-domain trusted network. Each trusted domain establishes a domain proxy server in its own security domain according to the relevant conditions within its own domain, and uses the edge domain agent and the central agent as nodes of the inter-domain trusted network. The edge trusted domain agent obtains trusted authentication by registering and remotely authenticating with the central agent. The two edge domain agents achieve mutual authentication of the trusted state through two-way remote authentication, thereby realizing trust transmission and privacy protection. Through the trusted and secure communication channel established by the two edge domain agents, the identity authentication and key negotiation process of the data request terminal node and the data owning node is completed.

[0007] Based on the above solution ideas, the solution of the present invention is divided into three parts as a whole, namely domain agent identity registration, inter-domain agent authentication and cross-domain authentication and key agreement.

[0008] The three parts of the overall solution of the present invention are further explained:

[0009] 1. Domain agent identity registration part:

[0010] Newly added domain proxy EDP i Registration mainly refers to the domain agent first submitting a registration request to the central agent CP, and the two complete two-way authentication through SGX remote attestation to determine the credibility of the newly joined domain agent.

[0011] 2. Bidirectional authentication between domain agents:

[0012] The premise of cross-domain communication between two edge domains is that the domain agents of the two edge domains trust each other, that is, mutual trust between the domain agents must be established. Based on the cross-domain access model proposed by this invention, the trust between domain agents is mainly established through the remote authentication technology of SGX to achieve two-way authentication and establish a trust relationship. Assuming that the domain agent EDP A Proxy EDP to the domain B When making an access request, a trusted environment authentication is required for both parties. Since domain agent B is a service provider, it should have completed the trusted authentication and registration through the central agent CP. The domain agent EDP APerform remote authentication to CP to prove that it is running in a trusted environment, and then EDP A To EDP B Initiate a request to verify B's trusted status, EDP B First perform remote authentication to CP to confirm EDP B After running in a trusted environment, the trusted authentication result is returned to A to complete EDP A With EDP B Trusted establishment of two-way authentication.

[0013] 3. Cross-domain authentication and key negotiation:

[0014] Take domains A and B as an example to conduct cross-domain communication between edge terminal nodes. Assume that node D in domain A A Accessing node D in domain B B , through EDP B EDP A Certification indirectly implements EDP B To D A Authentication, thus achieving D A Cross-domain authentication. Edge node D A Proxy EDP to the domain B Send access request, EDP B Upon receipt of the access request, EDP A Initiate identity authentication request. EDP A With EDP B Trust authentication is performed according to the two-way authentication process between domain agents, and the session key is communicated through the ECDH key negotiation protocol. A Within the domain, D A Perform authentication and generate authentication results. EDP A Use session key pair D in the enclave A The authentication result is encrypted and sent to EDP B .EDP B EDP A Decrypt the sent authentication result to determine D A After being trusted, identity authentication is completed, D A Cross-domain communication is possible.

[0015] This paper proposes a cross-domain identity authentication scheme based on SGX technology. This scheme introduces an edge domain proxy role, enabling trusted authentication between two edge domains through remote attestation between them. Furthermore, it introduces a central proxy role, enabling trusted management of each edge domain proxy that joins the cross-domain authentication network and providing verification for remote attestation between edge domains, thereby enabling the construction of a trust chain and the transfer of trust on the cross-domain authentication network. The proposed scheme offers authentication security, session key security, and forward security, while also resisting impersonation and man-in-the-middle attacks and being lightweight and flexible.

[0016] After security analysis, the cross-domain identity authentication method provided by the present invention can resist impersonation attacks and man-in-the-middle attacks, and can ensure the security of the authentication process, the security of session key transmission, and the privacy of edge nodes is protected by the trusted platform. At the same time, the complexity of building a trust chain between domain networks is reduced compared to the previous blockchain-based authentication architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a schematic diagram of the cross-domain identity authentication solution architecture

[0018] Figure 2 Domain Proxy Identity Registration Flowchart

[0019] Figure 3 This is the authentication flow chart between domain agents

[0020] Figure 4 This is the flow chart of remote authentication of inter-domain platforms

[0021] Figure 5 This is the cross-domain authentication and key negotiation flow chart DETAILED DESCRIPTION

[0022] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0023] Reference Figure 1, the architecture applicable to the cross-domain identity solution proposed in the present invention is shown in the figure, which is mainly composed of an edge terminal node (Edge Terminal Node, ETP), an edge domain proxy (Edge Domain Proxy, EDP), and a central proxy (CentralProxy, CP). The central proxy is a proxy node that has completed registration on the Intel Attestation Server (Intel Attestation Server, IAS). It is mainly responsible for the registration of each domain, the authentication of the trusted execution environment, and the secure storage of the identity information of each domain agent. The edge domain proxy is an entity that acts as an agent for all edge nodes in a security domain to send authentication requests to other security domains. It is mainly responsible for performing inter-domain trusted authentication and processing identity authentication requests of edge nodes. It is also the main object for security protection and trusted status verification.

[0024] Reference Figure 2 The process of domain agent registration with central agent in the present invention will be described in detail. The central agent is an entity registered on the Intel authentication server to ensure its complete trustworthiness. Both the newly added domain agent and the existing domain agent can verify the trustworthiness of the domain agent through remote attestation of the central agent. Based on the above assumptions, the newly added domain agent EDP i Registration mainly refers to the domain agent first submitting a registration request to the central agent CP. The two complete a two-way authentication through SGX remote attestation to confirm the credibility of the newly joined domain agent. The specific process steps are as follows:

[0025] 1) Newly added domain proxy EDP i Submit a registration request to the central agent

[0026] 2) Central agent CP to newly joined domain agent EDP i Verify the software and hardware environment to confirm that it can meet the environmental requirements for SGX application operation

[0027] 3) Newly added domain agent EDP i Create a local Enclave and send a remote authentication report to the central proxy CP

[0028] 4) The central agent CP sends the newly joined domain agent EDP to the Intel authentication server IAS i After authenticating with the remote authentication report, obtain the verification report to confirm that the newly joined domain agent EDP i Is running on a trusted platform

[0029] 5) Central agent CP and newly added domain agent EDP i Use the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm to negotiate the session key and establish a secure information transmission channel

[0030] 6) Newly added domain agent EDP i Send its own identity information to the central agent CP through the session channel

[0031] 7) The central agent CP acts as an agent for the newly joined domain EDP in the Enclave i The identity information of the newly added domain agent EDP is summarized and the summary is sealed and saved. i Join the domain agent registry and complete the new domain agent EDP i Registration.

[0032] Reference Figure 3 Based on the trust construction between the two domain agents in the present invention, the remote attestation technology provided by SGX is used for the domain agent EDP. A Proxy EDP to the domain B When making an access request, a trusted environment authentication is required for both parties. B The service provider should have completed the trusted authentication and registration through the central agent CP, the domain agent EDP A Perform remote authentication to the central agent CP to prove that it is running in a trusted environment, and then the domain agent EDP A Proxy EDP to the domain B Initiate verification domain proxy EDP B Trusted state request, domain proxy EDP B First, perform remote authentication with the central agent CP to determine the domain agent EDP B After running in a trusted environment, it will proxy EDP to the domain A Return the trusted authentication result and complete the domain proxy EDP A EDP ​​with Domain Proxy B Trusted establishment of two-way authentication.

[0033] Reference Figure 4 In the solution proposed by the present invention, the domain agent EDP in domain A A The process of remote authentication to the central proxy CP and the domain proxy EDP in domain B B The process of remote authentication to the central agent CP is the same as that of the domain agent EDP A Taking the authentication process with the central agent CP as an example, the specific steps are as follows:

[0034] 1) Domain Proxy EDP AThe local enclave sends an initial request to the central proxy CP, which includes the Enhanced Privacy Identification (EPID) group that the platform claims to be a member of. The central proxy CP requests the Intel authentication server IAS to update the signature revocation list SigRL to provide services for the members of the declared group. Then, the central proxy CP constructs a challenge message and sends it to the domain proxy EDP. A Application to certify Domain Proxy EDP A Running on an SGX-protected platform, the challenge message consists of a service provider ID (SPID), a random dynamic code nonce, an updated signature revocation list SigRL, and an optional basename parameter (the random basename parameter is used to ensure the anonymity of the report).

[0035] 2) Domain Proxy EDP A The application passes the challenge message to the domain proxy EDP A Enclave.

[0036] 3) Domain Proxy EDP A The Enclave will call the EREPORT instruction to create a local verifiable REPORT for the platform reporting Enclave (Quoting Enclave, QE). A An authenticated secure channel is established between the Enclave and the domain proxy CP, and the newly generated temporary public key can be added to the user data field of the local verifiable report REPORT.

[0037] 4) Domain Proxy EDP A The application passes both the local verifiable report REPORT and the challenge message from the central proxy CP to the domain proxy EDP A Report Enclave QE.

[0038] 5) Domain Proxy EDP AThe reporting enclave QE calls the EGETKEY instruction to obtain the local verifiable report key REPORT KEY and verify the report REPORT to determine whether the enclave is running on the same platform. If successful, the reporting enclave QE will call the EGETKEY instruction again to receive the platform's authentication key sealing key Provisioning SealKey, which is used to decrypt the platform's remote authentication key (EPID private key). And generate a report QUOTE based on the corresponding signature mode and the public key of the Intel authentication server IAS. The report QUOTE contains the identity of the authentication enclave, execution mode details, and other data.

[0039] 6) Domain Proxy EDP A The application forwards the report QUOTE to the central proxy CP for verification.

[0040] 7) The central agent CP forwards the report QUOTE to the Intel authentication server IAS for verification.

[0041] 8) Intel authentication server IAS first verifies the Enhanced Privacy ID EPID certificate based on the identity signature of the report QUOTE. Then, the validity check of the platform is completed by authenticating the identity signature. Then Intel e The authentication server IAS creates a new authentication verification report as a response to the central agent CP. The authentication verification report includes the report QUOTE structure generated by the platform for the authentication enclave. A correct authentication verification report confirms that the platform is running in a trusted environment on SGX, and the central agent CP is then responsible for verifying the domain agent EDP. A Enclave identification and EDP to the domain proxy A Send authentication results.

[0042] Reference Figure 5 In the design of cross-domain authentication and key negotiation in the solution proposed by the present invention, cross-domain communication between edge terminal nodes is performed by taking domains A and B as an example. Assume that node D in domain A A Access the B domain node DB through the domain proxy EDP B Domain Proxy EDP A Authentication indirectly implements domain proxy EDP B Domain node D A Authentication of domain node D A The specific steps for cross-domain authentication are as follows:

[0043] 1) Domain node D in domain A A Proxy EDP to domain B B Send access request

[0044] 2) Domain Proxy EDP B After receiving the access request, it sends the request to the domain proxy EDP. A Initiate an authentication request

[0045] 3) Domain Proxy EDP A EDP ​​with Domain Proxy B Trust authentication is performed according to the two-way authentication process between domain agents, and the session key is communicated through the Elliptic Curve Diffie-Hellman (ECDH) key negotiation protocol.

[0046] 4) Domain Proxy EDP A In the domain, the domain node D A Perform authentication and generate authentication results

[0047] 5) Domain Proxy EDP A Use the session key to the domain node D in the Enclave A The authentication result is encrypted and sent to the domain proxy EDP B

[0048] 6) Domain Proxy EDP B Domain Proxy EDP A Decrypt the sent authentication result to determine the domain node D A After being trusted, complete identity authentication

[0049] 7) Domain Node D A After completing the identity authentication, cross-domain communication can be carried out. If the domain node D A With domain node D B For secure communication, key negotiation is required. This paper proposes to use the SM2 algorithm to implement key negotiation.

[0050] 8) Domain Node D A Generate a private random number a and generate a private key g through the SM2 algorithm a And the private key g a The signed message is sent to D B

[0051] 9) Domain Node D B After receiving the message, verify the signature and get g a , generate a private random number b, and generate a private key g through the SM2 algorithm b , and the private key g b The signed message is sent to domain node D A

[0052] 10) Domain Node D A After receiving the message, verify the signature and get g b , domain node D A Calculated by SM2 algorithm (ga ) b Get the session key KS

[0053] 11) Domain Node D B Calculated by SM2 algorithm (g b ) a Get the session key KS and domain node D A Same, up to this domain node D A With domain node D B The secure session is established.

Claims

1. A cross-domain identity authentication method based on SGX, characterized in that: The process of domain agent registration with central agent is as follows: the central agent is an entity registered on the Intel authentication server to ensure its complete trustworthiness. Both new domain agents and existing domain agents can verify the trustworthiness of the domain agent through remote attestation of the central agent; the newly added domain agent EDP i Registration means that the domain agent first submits a registration request to the central agent CP. The two parties complete a two-way authentication through SGX remote attestation to determine the credibility of the newly joined domain agent. The specific process steps are as follows: 1) Newly added domain proxy EDP i Submit a registration request to the central agent 2) Central agent CP to newly joined domain agent EDP i Verify the software and hardware environment to confirm that it can meet the environmental requirements for SGX application operation 3) Newly added domain agent EDP i Create a local Enclave and send a remote authentication report to the central proxy CP 4) The central agent CP sends the newly joined domain agent EDP to the Intel authentication server IAS i After authenticating with the remote authentication report, obtain the verification report to confirm that the newly joined domain agent EDP i Is running on a trusted platform 5) Central agent CP and newly added domain agent EDP i Use the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm to negotiate the session key and establish a secure information transmission channel 6) Newly added domain agent EDP i Send its own identity information to the central agent CP through the session channel 7) The central agent CP acts as an agent for the newly joined domain EDP in the Enclave i The identity information of the newly added domain agent EDP is summarized and the summary is sealed and saved. i Join the domain agent registry and complete the new domain agent EDP i Registration Trust between two domain agents is established using remote attestation technology provided by SGX. A Proxy EDP to the domain B When making an access request, a trusted environment authentication is required for both parties. B The service provider should have completed the trusted authentication and registration through the central agent CP, the domain agent EDP A Perform remote authentication to the central agent CP to prove that it is running in a trusted environment, and then the domain agent EDP A Proxy EDP to the domain B Initiate verification domain proxy EDP B Trusted state request, domain proxy EDP B First, perform remote authentication with the central agent CP to determine the domain agent EDP B After running in a trusted environment, it will proxy EDP to the domain A Return the trusted authentication result and complete the domain proxy EDP A EDP ​​with Domain Proxy B Trusted establishment of two-way authentication; For the domain proxy EDP in domain A A The process of remote authentication to the central proxy CP and the domain proxy EDP in domain B B The process of remote authentication to the central agent CP is the same as that of the domain agent EDP A Taking the authentication process with the central agent CP as an example, the specific steps are as follows: 1) Domain Proxy EDP A The local enclave sends an initial request to the central proxy CP, which includes the enhanced privacy ID group that the platform claims to be a member of. The central proxy CP requests an updated signature revocation list SigRL from the Intel authentication server IAS to provide services for members of the declared group. Then, the central proxy CP constructs a challenge message and sends it to the domain proxy EDP. A Application to certify Domain Proxy EDP A When running on an SGX-protected platform, the challenge message consists of the service provider ID, a random dynamic code nonce, an updated signature revocation list SigRL, and an optional basename parameter; 2) Domain Proxy EDP A The application passes the challenge message to the domain proxy EDP A Enclave; 3) Domain Proxy EDP A Enclave will call EREPORT instruction to create a local verifiable report REPORT for platform report Enclave QE; in order to proxy EDP in the domain A An authenticated secure channel is established between the Enclave and the domain proxy CP, and the newly generated temporary public key is added to the user data field of the local verifiable report REPORT; 4) Domain Proxy EDP A The application passes both the local verifiable report REPORT and the challenge message challengemessage from the central proxy CP to the domain proxy EDP A Report Enclave QE; 5) Domain Proxy EDP A The reporting enclave QE calls the EGETKEY instruction to obtain the local verifiable report key REPORTKEY and verify the report REPORT to determine whether the enclave is running on the same platform. If successful, the reporting enclave QE will call the EGETKEY instruction again to receive the platform's authentication key sealing key Provisioning Seal Key, which is used to decrypt the platform's remote authentication key j, i.e., the EPID private key. The report QUOTE is generated based on the corresponding signature mode and the public key of the Intel Attestation Server IAS. The report QUOTE contains the identity of the authenticating enclave, execution mode details, and other data. 6) Domain Proxy EDP A The application forwards the report QUOTE to the central proxy CP for verification; 7) The central agent CP forwards the report QUOTE to the Intel authentication server IAS for verification; 8) The Intel authentication server IAS first verifies the Enhanced Privacy ID EPID certificate based on the identity signature of the report QUOTE; then, the platform validity check is completed by authenticating the identity signature; then the Intel authentication server IAS creates a new authentication verification report as a response to the central agent CP; the authentication verification report includes the report QUOTE structure generated by the platform for the authentication enclave; the correct authentication verification report confirms that the platform is running in a trusted environment on SGX, and then the central agent CP is responsible for verifying the domain agent EDP A Enclave identification and EDP to the domain proxy A Send authentication results; For the design of cross-domain authentication and key negotiation, the cross-domain communication between edge terminal nodes is carried out in domains A and B. Assume that node D in domain A A Access the B domain node DB through the domain proxy EDP B Domain Proxy EDP A Authentication indirectly implements domain proxy EDP B Domain node D A Authentication of domain node D A The specific steps for cross-domain authentication are as follows: 1) Domain node D in domain A A Proxy EDP to domain B B Send access request 2) Domain Proxy EDP B After receiving the access request, it sends the request to the domain proxy EDP. A Initiate an authentication request 3) Domain Proxy EDP A EDP ​​with Domain Proxy B Trust authentication is performed according to the two-way authentication process between domain agents, and the session key is communicated through the Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol. 4) Domain Proxy EDP A In the domain, the domain node D A Perform authentication and generate authentication results 5) Domain Proxy EDP A Use the session key to the domain node D in the Enclave A The authentication result is encrypted and sent to the domain proxy EDP B 6) Domain Proxy EDP B Domain Proxy EDP A Decrypt the sent authentication result to determine the domain node D A After being trusted, complete identity authentication 7) Domain Node D A After completing identity authentication, cross-domain communication can be carried out; if domain node D A With domain node D B For secure communication, further key negotiation is required, and the SM2 algorithm is used to implement key negotiation; 8) Domain Node D A Generate a private random number a and generate a private key g through the SM2 algorithm a And the private key g a The signed message is sent to D B 9) Domain Node D B After receiving the message, verify the signature and get g a , generate a private random number b, and generate a private key g through the SM2 algorithm b , and the private key g b The signed message is sent to domain node D A 10) Domain Node D A After receiving the message, verify the signature and get g b , domain node D A Calculated by SM2 algorithm (g a ) b Get the session key KS 11) Domain Node D B Calculated by SM2 algorithm (g b ) a Get the session key KS and domain node D A Same, up to this domain node D A With domain node D B The secure session is established.

Images