A decentralized trust construction method for distributed sgx enclave

Abstract

The application discloses a kind of decentralized trust construction methods for distributed SGX enclave, for establishing mutual trust relationship between distributed enclave, and provide strong channel binding and freshness guarantee mechanism for the evidence used in remote authentication process.The method divides all nodes in network domain into two types, and defines three special enclaves, and realizes the trust management of distributed SGX enclave by the protocol of four stages of preparation stage, supply stage, authentication stage and revocation stage.Compared with prior art, the method provided by the application can improve the efficiency of establishing trust of distributed SGX enclave, thereby further improving the security of SGX distributed autonomous system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of trusted execution environment, in particular to a decentralized trust construction method for distributed SGX enclave. BACKGROUND

[0002] Intel SGX provides two kinds of authentication mechanisms, local attestation and remote attestation. Local attestation allows one enclave to generate a signature structure, called report, which can be verified by another enclave on the same hardware platform with the help of hardware. The report contains two measurement values MRENCLAVE and MRSIGNER, other attributes of the enclave, the trustworthiness of the hardware TCB and a string of user data. Remote attestation utilizes the process of local attestation, after Intel QE successfully verifies the report from other enclaves on the same hardware platform, it signs a quote using EPID group signature algorithm. The quote is then passed to the remote entity by the enclave, and the remote entity requests the attestation service to verify the quote, and makes a trust decision on the enclave by returning the verification report.

[0003] In order to protect the communication between enclaves from man-in-the-middle attack, Knauth et al. proposed to combine the remote attestation process with the existing TLS protocol by using the TLS handshake process. The method is to create a pair of public and private keys when the enclave is started, bind the public key in this set of keys with the report in the local attestation process, request the IAS attestation verification report using the quote material, and use the X.509 certificate embedded with the attestation verification report as the channel certificate between enclaves.

[0004] Although the scheme proposed by Knauth et al. can effectively build the mutual trust between enclaves, the current remote attestation scheme has the following problems: ① The trust decision of the relying party on the enclave depends on the specific verification service deployed by the manufacturer of the trusted execution environment, once the verification service causes trust monopoly, it is likely to deceive the relying party and make the wrong trust decision. ② The evidence used in the remote attestation process may be pre-generated or allowed to be reused. Attackers may intercept and replay the evidence in the trust establishment process through man-in-the-middle attack or other network-level attack means, and deceive the trust of the relying party. ③ With the continuous expansion of the scale of distributed systems, the number of trust relationships that the centralized verification service needs to handle increases dramatically, which greatly improves the complexity of trust management, and even causes performance bottleneck. SUMMARY

[0005] The present application proposes a method for constructing mutual trust between SGX enclaves in a decentralized manner, which solves the problem of how to securely and efficiently establish mutual trust between distributed SGX enclaves, and makes up for the shortcomings of the prior art.

[0006] Technical solutions: To achieve the purpose of the application, the technical solutions adopted by the application are:

[0007] A decentralized trust construction method for distributed SGX enclaves, the steps are as follows: first, all nodes in the network are divided according to the following rules: the entire network is divided into multiple independent network domains, and the nodes in each network domain are divided into two types, namely authentication nodes and user nodes; in the independent network domain, the authentication node exists uniquely, and the user node exists one or more; then define the following enclave types: authentication enclave, deployed on the authentication node, there is only one authentication enclave on each authentication node, used to provide authentication required basic services for all attestation enclaves, including creating a unified EPID group, issuing membership identity for attestation enclaves and synchronizing revocation values; attestation enclave, deployed on the user node, there is only one attestation enclave on each user node, used to provide quote generation and quote verification services for all user enclaves; user enclave, deployed on the user node, there is one or more user enclaves on each user node, used to execute computing tasks.

[0008] The decentralized trust construction method includes four stages of preparation stage, supply stage, authentication stage and revocation stage; the preparation stage starts all the authentication enclaves, establishes trust between all the authentication enclaves, and creates a unified EPID group; the supply stage initializes all the attestation enclaves, establishes mutual trust between the attestation enclaves and the authentication enclaves in the network domain where the attestation enclaves are located, and becomes a member of the EPID group; the authentication stage initializes all the user enclaves, the user enclaves request quotes signed by the attestation enclaves, each user enclave exchanges quotes with each other, and establishes trust for each other; the revocation stage is used to revoke the quotes used by the user enclaves when establishing trust, so that they cannot be used again by the above authentication stage.

[0009] Further, the four stages of the decentralized trust construction method include:

[0010] The preparation stage starts all the authentication enclaves, establishes trust between all the authentication enclaves through the remote authentication protocol integrated into the TLS handshake, and creates a unified EPID group through a consensus algorithm.

[0011] The supply stage initializes all the attestation enclaves, establishes mutual trust between the attestation enclaves and the authentication enclaves in the network domain where the attestation enclaves are located through the remote authentication protocol integrated into the TLS handshake, and becomes a member of the EPID group through the EPID joining protocol.

[0012] In the authentication phase, all user enclaves are initialized, and after completing a local authentication protocol with the attestation enclave on its node, the user enclave requests a quote signed by the attestation enclave; then, each user enclave exchanges quotes with each other through a remote attestation protocol integrated into a TLS handshake to establish trust with each other.

[0013] In the revocation phase, the revocation is initiated by sending a signature on the quote to be revoked to the attestation enclave by the user enclave; the attestation enclave receiving the revocation request then forwards the signature carried by the revocation request to the authentication enclave in its network domain and synchronizes to all network domains through the consensus algorithm in the authentication enclave to complete the revocation.

[0014] Further, the remote attestation protocol integrated into the TLS handshake includes the following steps:

[0015] (1) The enclave initiating the TLS handshake embeds an SGX quote Q containing a hash value h1 = H(pk||n C ||n S ) into an X.509 certificate.

[0016] Where n C and n S represent random numbers in the Client Hello and Server Hello messages for the TLS handshake respectively, pk represents the public key of the X.509 certificate, H represents the SHA-256 hash function, and || represents the concatenation of binary strings.

[0017] (2) The enclave on the other side of the TLS handshake calculates a hash value h2 = H(pk||n C ||n S ) according to n C , n S and the public key pk of the certificate in the TLS handshake process when verifying the X.509 certificate.

[0018] Then check whether the hash value h1 contained in the SGX quote Q extracted from the X.509 certificate is the same as the recalculated hash value h2, if the same, continue the TLS handshake process, otherwise abort the TLS handshake process.

[0019] Further, in the preparation phase, the following steps are included:

[0020] (1) All authentication enclaves establish trust relationships with each other through a remote attestation protocol integrated into a TLS handshake, and elect a leader authentication enclave through a Raft algorithm.

[0021] (2) The elected leader authentication enclave generates a group public key pk g and a group private key sk g, create an EPID issuer and an empty revocation list, and send the public key pk g and the private key sk1 to all other attestation enclaves via a broadcast message.

[0022] (3) The attestation enclave receiving the broadcast message retrieves the public key pk G and the private key sk G , creates its local EPID issuer and an empty revocation list.

[0023] Further, in the provisioning phase, the following steps are included:

[0024] (1) All proving enclaves establish mutual trust relationship with the attestation enclave in their network domain by integrating a remote attestation protocol into the TLS handshake, and the proving enclave generates a random key f to represent its EPID membership.

[0025] (2) The proving enclave then requests a challenge containing a random number n I from the attestation enclave on its node, and creates a join request using n I and the key f as a response to the challenge, and sends it to the attestation enclave, which checks the response to the challenge in the join request and generates a membership certificate for the proving enclave as a return.

[0026] (3) The proving enclave requests the public key pk G of the EPID group from the attestation enclave, and initializes an EPID member and an EPID verifier inside it.

[0027] Further, in the attestation phase, the following steps are included:

[0028] (1) The user enclave completes local authentication with the proving enclave on its node, and requests the proving enclave to sign an SGX quote Q containing a hash value h1, and initiates a TLS handshake with another user enclave using an X.509 certificate embedded with the quote Q.

[0029] (2) The other side of the TLS handshake enclave extracts the quote Q from the X.509 certificate, calculates the hash value h2, checks whether the hash value h1 contained in the quote Q is the same as the recalculated hash value h2; if not, terminate the TLS handshake; if the same, forward the quote Q to the proving enclave on its node.

[0030] (3) According to the quote Q and the attestation verification report returned by the proving enclave, compare whether the MRENCLAVE and MRSIGNER measurement values are the same as the expected values, and decide whether to trust the user enclave according to the comparison result.

[0031] Furthermore, the revocation phase includes the following steps:

[0032] (1) When a user enclave loses its network connection, the user enclave on the other side of the channel initiates a revocation request to the attestation enclave of its node, along with the signature of the evidence used to establish trust. The attestation enclave then forwards the revocation request to the authentication enclave of its network domain.

[0033] (2) The authentication enclave L that receives the revocation request γ sends a request to at least A cluster Q consisting of authenticated enclaves sends a five-tuple message <Acc,L,i L ,i L,I ,γ>, where Acc indicates that the message is the Accept message type in the Paxos consensus algorithm, L indicates the authentication enclave, i L Indicates the serial number of the authentication enclave L, i L,I Represents the revocation request sequence number initiated by the authentication enclave L, N represents the total number of authentication enclaves, Indicates rounding down.

[0034] (3) When any authentication enclave R receives the message <Acc,L,i L ,i L,I ,γ>, record a triple L ,i L,I ,γ>, and reply a response message to the authentication enclave L <AccOK,i L,I >, where AccOK indicates that the message is a response to the Accept message.

[0035] (4) When the authentication enclave L receives at least Response message <AccOK,i L,I >, the revocation request γ is recorded in the revocation list to complete the revocation, and the message is sent <Com,L,i L ,i L,I ,γ> to all other authentication enclaves, where Com indicates that the message is the Commit message type in the Paxos consensus algorithm.

[0036] (5) When any authentication enclave R receives the message <Com,L,i L ,i L,I ,γ>, the revocation request γ is recorded in the revocation list to complete the revocation, and a reply message is sent to the authentication enclave L. <Co K,i L,I >, where ComOK indicates that the message is a response to the Commit message.

[0037] Furthermore, a unified EPID group is created through a consensus algorithm, including the following steps: ​

[0038] (1) Each authentication enclave initializes a random timer t respectively, once the timer t of a certain authentication enclave A expires, the authentication enclave increases its internal term number term=trem+1, votes for itself, and sends an election request <Election, i A , term> to all other authentication enclaves in the cluster, where Election represents the election message type, i A represents the sequence number of the authentication enclave A;

[0039] (2) If the other authentication enclaves receiving the election request have not voted within the term, they will vote for the authentication enclave corresponding to the first received election request and send a message <Vote, term> to it, where Vote represents the vote message type;

[0040] (3) Once a certain authentication enclave A accumulates at least votes, it becomes the leader authentication enclave in the cluster; after becoming the leader authentication enclave, the authentication enclave A generates a group public key pk G and a group private key sk G , creates an EPID issuer, and sends a broadcast message <Notification, i A , term, pk G , sk G > to all other authentication enclaves, where N represents the total number of authentication enclaves, represents the ceiling, Notification represents the broadcast message type, i A represents the sequence number of the authentication enclave A, and term represents the elected term;

[0041] (4) The other authentication enclaves receiving the broadcast message retrieve and store the public key pk G and the private key sk G carried by the message, and create their respective EPID issuers.

[0042] Beneficial effects: Compared with the prior art, the technical scheme of the present application has the following beneficial technical effects:

[0043] This invention provides a decentralized SGX enclave trust-building method for establishing mutual trust between distributed enclaves. It also provides a strong channel binding and freshness assurance mechanism for evidence used in remote authentication, thereby enabling trust management within distributed enclaves. This method divides all nodes in a network domain into two types and defines three special enclaves. Trust management within distributed SGX enclaves is implemented through a four-phase protocol: preparation, provisioning, authentication, and revocation. Compared to existing technologies, the method provided by this invention improves the efficiency of trust establishment within distributed SGX enclaves, thereby further enhancing the security of the SGX distributed autonomous system. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 It is the overall framework diagram of the present invention.

[0045] Figure 2 It is a flow chart of the preparation stage of the present invention.

[0046] Figure 3 It is a flow chart of the supply phase of the present invention.

[0047] Figure 4 It is a flow chart of the authentication phase of the present invention. DETAILED DESCRIPTION

[0048] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0049] This invention provides a decentralized trust-building method for distributed SGX enclaves. This method divides all nodes in a network domain into two types: authentication nodes and user nodes. Each network domain can have a unique authentication node and one or more user nodes. Two special enclaves are defined: the authentication enclave and the attestation enclave. Enclaves specific to specific computing functions are named user enclaves. The authentication enclave is deployed on the authentication node, while the attestation enclave and user enclave are deployed on the user node. The process specifically includes a preparation phase, a provisioning phase, an authentication phase, and a revocation phase.

[0050] The preparation phase activates all authentication enclaves, establishes trust between them through the remote authentication protocol integrated into the TLS handshake, and creates a unified EPID group through a consensus algorithm. The provisioning phase initializes all attestation enclaves, establishes mutual trust between the attestation enclave and the authentication enclave within its network domain through the remote authentication protocol integrated into the TLS handshake, and becomes a member of the EPID group through the EPID joining protocol. The authentication phase initializes all user enclaves. After completing the local authentication protocol with the attestation enclave within its node, the user enclave requests a quote signed by the attestation enclave. Each user enclave then exchanges quotes through the remote authentication protocol integrated into the TLS handshake, thereby establishing trust in each other. The revocation phase revokes the quote used by the user enclave to establish trust, preventing it from being used again in the authentication phase. This phase is initiated by the user enclave sending the signature of the quote to be revoked to the attestation enclave. Upon receiving the revocation request, the attestation enclave then forwards the signature carried in the revocation request to the authentication enclave within its network domain. The signature is then synchronized to all network domains through the consensus algorithm within the authentication enclave, completing the revocation.

[0051] The remote authentication protocol integrated into the TLS handshake consists of the following steps:

[0052] (1) After startup, the enclave generates a key pair, including a public key pk and a private key sk, to identify itself. Then, based on the public key pk and the random number n in the Client Hello message used for the TLS handshake, C and the random number n in the ServerHello message used in the TLS handshake S Calculate a hash value h1=H(pk||n C ||n S ), where H represents the SHA-256 hash function and || represents the concatenation of binary strings.

[0053] The present invention integrates the remote authentication protocol of the SGX enclave into the existing TLS handshake protocol. The integration method is that the SGX remote authentication quote Q contains the public key pk of the X.509 certificate and the hash value of the concatenation of the above-mentioned Client Hello message and Server Hello message.

[0054] (2) The enclave uses h1 as user data and requests the hardware to create a report R about itself. If the enclave is an authentication enclave or a proof enclave, it sends the report R to the Intel QE on its node to sign a quote. Otherwise, if the enclave is a user enclave, it sends the report R to the proof enclave on its node to sign a quote. The quote is uniformly denoted as Q.

[0055] (3) The enclave uses the public key pk to create an X.509 certificate structure, embeds the quote Q as an extension field into the X.509 certificate structure, signs the X.509 certificate structure using the private key sk, and passes the signed X.509 certificate as the TLS handshake certificate to the enclave on the other side of the channel along with the TLS handshake protocol.

[0056] (4) During the TLS certificate verification process, the enclave on the other side of the channel retrieves the X.509 certificate and extracts the extension field. The extracted content is recorded as Q. If this enclave is an authentication enclave or a certification enclave, it sends the quote Q to the IAS to obtain the authentication verification report generated by the IAS. Otherwise, if this enclave is a user enclave, it sends the quote Q to the certification enclave on its node to obtain the authentication verification report generated by the certification enclave.

[0057] (5) The enclave on the other side of the channel uses n in the TLS handshake process C 、n S And the public key pk of the certificate calculates a hash value h2=H(pk||n C ||n S ), where H represents the SHA-256 hash function and || represents binary string concatenation. It then checks whether the hash value h1 contained in the quote Q extracted from the X.509 certificate is identical to the newly calculated hash value h2. If so, the TLS handshake continues. Otherwise, the TLS handshake is aborted.

[0058] The process of creating a unified EPID group through a consensus algorithm utilizes the election algorithm in the distributed consensus protocol Raft, including the following steps:

[0059] (1) Each authentication enclave initializes a random timer t. Once the timer t of an authentication enclave A times out, the authentication enclave increases its internal term number term=trem+1, votes for itself, and sends an election request to all other authentication enclaves in the cluster. <Election,i A ,term>, where Election represents the election message type, i A Represents the serial number of the authentication enclave A.

[0060] (2) If other authentication enclaves that have received the election request have not voted within the term, they will vote for the authentication enclave corresponding to the first election request received and send it<Vote,term> , where Vote represents the voting message type.

[0061] (3) Once a certified enclave A accumulates at least Zhang votes, it becomes the leader certification enclave in the cluster. After becoming the leader certification enclave, certification enclave A generates a group public key pk G and a group private key sk G , creates an EPID issuer, and sends a broadcast message <Notification, i A , term, pk G , sk G > to all other certification enclaves, where N represents the total number of certification enclaves, represents the ceiling, Notification represents the broadcast message type, i A represents the serial number of certification enclave A, and term represents the elected term.

[0062] (4) Other certification enclaves receiving the broadcast message retrieve and store the public key pk G and the private key sk G carried by the message, and create their own EPID issuers.

[0063] Synchronization of signatures to be revoked through a consensus algorithm includes the following steps:

[0064] (1) A certification enclave L receives a revocation request for a value γ, and sends a five-tuple message <Acc, L, i L , i L,I , γ> to a cluster Q consisting of at least certification enclaves. Among them, Acc represents the Accept message type in the Paxos consensus algorithm, L represents the certification enclave, i L represents the serial number of the certification enclave L, i L,I represents the serial number of the revocation request initiated by the certification enclave L, and N represents the total number of certification enclaves, represents the floor.

[0065] (2) When any certification enclave R receives the message <Acc, L, i L , i L,I , γ>, it records the three-tuple <i L , i L,I , γ> and replies to the certification enclave L with a response message <AccOk, i L,I >, where AccOK represents the response to the Accept message, and i L,I represents the serial number of the revocation request initiated by the certification enclave L.

[0066] (3) When the certification enclave L receives at least <AccOK, i L,I > responses, it records γ in the revocation list to complete the revocation, and sends a message <Com, L, i L , iL,I ,γ> to all other attestation enclaves, where N denotes the total number of attestation enclaves, denotes the floor function, Com denotes that the message is a Commit message type in the Paxos consensus algorithm, L denotes an attestation enclave, i L denotes the sequence number of the attestation enclave L, i L,I denotes the revocation request sequence number initiated by the attestation enclave L.

[0067] (4) When any attestation enclave R receives the message <Com, L, i L ,γ>, records γ to the revocation list to complete the revocation, and replies to the attestation enclave L with the message <ComOK, i L,I >, where ComOK denotes that the message is a response to the Commit message, i L,I denotes the sequence number of the attestation enclave L, and i L,I denotes the revocation request sequence number initiated by the attestation enclave L.

[0068] A decentralized trust construction method for distributed SGX enclaves, as shown in Figure 1 , the overall process is mainly divided into a preparation stage, a supply stage, an authentication stage and a revocation stage. Next, the four stages will be introduced in detail.

[0069] I. Preparation stage

[0070] As shown in Figure 2 , all attestation enclaves are started on the authentication node, connected to peer entities in other network domains, and establish trust relationship with each other through the remote authentication protocol integrated into the TLS handshake. When all attestation enclaves have completed the establishment of trust relationship, each attestation enclave initializes a random timer t respectively. If the timer t of a certain attestation enclave A times out, the attestation enclave increases its internal term sequence number term=trem+1, votes for itself, and sends an election request <Election, i A ,term> to all other attestation enclaves in the cluster. If a certain attestation enclave receiving the election request has not voted within the term, it will vote for the attestation enclave corresponding to the first received election request, and send <Vote, term> to it. Once a certain attestation enclave A accumulates at least votes, it becomes the leader attestation enclave in the cluster. Then, the leader attestation enclave generates a group public key pk G and a group private key sk G , creates an EPID issuer and an empty revocation list, and broadcasts the public key pk G and the private key sk G through the message <Notification, i A,term,pk G ,sk G >sent to all other authenticated enclaves, where N represents the total number of authenticated enclaves, Indicates rounding up, Notification represents the broadcast message type, i A Represents the serial number of the authentication enclave A, and term represents the elected term. The authentication enclave that receives the broadcast message retrieves the public key pk carried in the message G and private key sk G , creating its local EPID issuer and an empty revocation list.

[0071] 2. Supply stage.

[0072] like Figure 3 As shown, all attestation enclaves are started on the user node, connected to the authentication enclave in its network domain, and establish a mutual trust relationship through the remote authentication protocol integrated into the TLS handshake. The attestation enclave generates a random private key f to represent its EPID member identity. It then requests a random number n from the authentication enclave on its node. I The challenge, and use n I The authentication enclave creates a join request with the private key f as a response to the challenge and sends it to the authentication enclave. "Challenge" is a cryptographic term that can be understood as a question message containing a random number, and is replied with a "response". The authentication enclave checks the response to the challenge contained in the join request and generates a membership certificate for the certification enclave in return. The certification enclave requests the public key pk of the EPID group from the authentication enclave. G , and initializes an EPID member and an EPID verifier within it.

[0073] 3. Certification stage.

[0074] (1) All user enclaves are started on the user node.

[0075] (2) The user enclave obtains the MRENCLAVE metric of the attestation enclave on its platform and uses this metric as user data to request the hardware to create a report R1 about itself and send it to the attestation enclave. The attestation enclave verifies the user data contained in the report R1 to ensure that the user enclave is running on the same node.

[0076] (3) Figure 4 As shown, the user enclave uses the public key pk created when it is started and the random number n in the ClientHello message used for TLS handshake C and the random number n in the Server Hello message S Calculate a hash value h1=H(pk||n C ||nS ), where H represents the SHA-256 hash function and || represents binary string concatenation. It then uses h1 as user data, again requests the hardware to create a report R2 for it, and requests the attestation enclave to sign report R2, resulting in a quote Q. It then inserts quote Q into the X.509 certificate used for the TLS handshake, self-signs it, and sends it to the user enclave on the other side of the handshake.

[0077] (4) The user enclave on the other side of the handshake extracts the quote Q from the received certificate and sends it to the attestation enclave on its node. The attestation enclave obtains the latest revocation list from the authentication enclave, using the group public key pk G Verify the signature in the offer Q and generate a verification report V for the user enclave.

[0078] (5) The user enclave on the other side of the handshake receives the n C 、n S And the public key pk of the certificate calculates a hash value h2=H(pk||n C ||n S ), where H represents the SHA-256 hash function and || represents the concatenation of binary strings. It then checks whether the hash value h1 contained in the quote Q extracted from the X.509 certificate is the same as the hash value h2 it recalculated. It then decides whether to trust the user enclave based on whether the MRENCLAVE and MRSIGNER metrics in the verification report V and quote Q are the same as expected.

[0079] (6) The user enclaves on both sides of the handshake exchange their identities and repeat steps (3) to (5) to establish trust in the other direction.

[0080] 4. Cancellation stage.

[0081] When a user enclave loses its network connection, the user enclave on the other side of the channel initiates a revocation request to the attestation enclave of its node, along with the signature of the evidence used to establish trust. The attestation enclave then forwards the revocation request to the authentication enclave of its network domain to initiate a revocation proposal. The authentication enclave L that receives the revocation request γ sends a request to at least A cluster of authenticated enclaves sends a message <Acc,L,i L ,i L,I ,γ>, where Acc indicates that the message is the Accept message type in the Paxos consensus algorithm, i L Indicates the serial number of the authentication enclave L, i L,I Represents the revocation request sequence number initiated by the authentication enclave L, N represents the total number of authentication enclaves, denotes the floor function. When any authentication enclave R receives a message <Acc, L, i L ,i L,I ,r>, it records a triple <i L ,i L,I ,γ> and replies to authentication enclave L with a response message <AccOK, i L,I >, where AccOK denotes that the message is a response to the Accept message. When authentication enclave L receives at least response messages <AccOK, i L,I >, it records γ to the revocation list to complete the revocation and sends a message <Com, L, i L ,i L,I ,γ> to all other authentication enclaves, where Com denotes that the message is a Commit message type in the Paxos consensus algorithm. When any authentication enclave R receives a message <Com, L, i L ,i L,I ,γ>, it records γ to the revocation list to complete the revocation and replies to authentication enclave L with <ComOK, i L,I >.

Claims

1. A decentralized trust building method for distributed SGX enclaves, characterized in that, The method steps are as follows: First, all nodes in the network are divided according to the following rules: Divide the entire network into multiple independent network domains, and divide the nodes in each network domain into two types, namely authentication nodes and user nodes; In the independent network domain, the authentication node exists uniquely, and the user node exists one or more; Then define the following enclave types: Authentication enclave, deployed on the authentication node, only one authentication enclave exists on each authentication node, which provides authentication services required by all attestation enclaves, including creating a unified EPID group, issuing membership to attestation enclaves, and synchronizing revocation values; Attestation enclave, deployed on the user node, only one attestation enclave exists on each user node, which provides quote generation and quote verification services for all user enclaves; User enclave, deployed on the user node, one or more user enclaves exist on each user node, which is used to execute computing tasks; The decentralized trust construction method includes four stages: preparation stage, supply stage, authentication stage and revocation stage; The preparation stage starts all authentication enclaves, establishes trust between all authentication enclaves, and creates a unified EPID group; The supply stage initializes all attestation enclaves, establishes mutual trust between attestation enclaves and authentication enclaves in the network domain where the attestation enclaves are located, and becomes a member of the EPID group; The authentication stage initializes all user enclaves, and the user enclaves request quotes signed by the attestation enclaves, and each user enclave exchanges quotes with each other to establish trust with each other; The revocation stage is used to revoke the quotes used by the user enclaves when establishing trust, so that they cannot be used again in the above authentication stage.

2. The method of claim 1, wherein, The four stages of the decentralized trust construction method include: The preparation stage starts all authentication enclaves, establishes trust between all authentication enclaves through the remote authentication protocol integrated into the TLS handshake, and creates a unified EPID group through a consensus algorithm; The supply stage initializes all attestation enclaves, establishes mutual trust between attestation enclaves and authentication enclaves in the network domain where the attestation enclaves are located through the remote authentication protocol integrated into the TLS handshake, and becomes a member of the EPID group through the EPID joining protocol; The authentication stage initializes all user enclaves, and after completing the local authentication protocol with the attestation enclave on the node, the user enclave requests a quote signed by the attestation enclave; then, each user enclave exchanges quotes with each other through the remote authentication protocol integrated into the TLS handshake to establish trust with each other; The revocation stage is started by the user enclave sending a signature on the quote that needs to be revoked to the attestation enclave; the attestation enclave receiving the revocation request then forwards the signature carried by the revocation request to the authentication enclave in the network domain where it is located, and synchronizes to all network domains through the consensus algorithm in the authentication enclave, completing the revocation.

3. The method of claim 2, wherein, The remote authentication protocol integrated into the TLS handshake includes the following steps: (1) The enclave that initiates the TLS handshake will embed the SGX quote Q containing the hash value h1 = H(pk||n C ||n S ) into the X.509 certificate; where n C and n S respectively represent the random numbers in the Client Hello and Server Hello messages for TLS handshake, pk represents the public key of the X.509 certificate, H represents the SHA-256 hash function, and || represents the concatenation of binary strings. (2) The enclave on the other side of the TLS handshake computes a hash value h2 = H(pk || n C , n S , and the public key pk of the certificate according to n C , n S in the TLS handshake process; Then check if the hash value h1 contained in the SGX quote Q extracted from the X.509 certificate is the same as the re-computed hash value h2, if the same, continue the TLS handshake process, otherwise, abort the TLS handshake process.

4. The method of claim 2 or 3, wherein, The preparation phase comprises the following steps: (1) All authentication enclaves establish trust relationship with each other through remote attestation protocol integrated into the TLS handshake, and elect a leader authentication enclave through the Raft algorithm; (2) The elected leader authenticates the enclave to generate a group public key pk G and a group private key sk G , creates an EPID issuer and an empty revocation list, and sends the group public key pk G and the group private key sk G to all other authenticating enclaves through a broadcast message; (3) The authenticated enclave that received the broadcast message retrieves the group public key pk and the group private key sk carried by the message G and creates its local EPID issuer and empty revocation list. G and creates its local EPID issuer and empty revocation list.

5. The method of claim 2 or 3, wherein, The supply phase comprises the following steps: (1) All attestation enclaves establish mutual trust relationship with the authentication enclaves in the network domain through remote attestation protocol integrated into the TLS handshake, and the attestation enclave generates a random key f to represent its EPID membership; (2) the attestation enclave subsequently requests a challenge from the authentication enclave on the node it resides on, containing a random number n I , and creates a join request using n I and the key f as a response to the challenge, which is sent to the authentication enclave, which checks the response to the challenge contained in the join request and generates a membership certificate for the attestation enclave as a return; (3) The enclave proves to the attestation enclave that it requested the group public key pk of the EPID group G and initializes an EPID member and an EPID verifier inside it.

6. The method of claim 2 or 3, wherein, The authentication phase comprises the following steps: (1) The user enclave completes local authentication with the attestation enclave on the node, and requests the attestation enclave to sign the SGX quote Q containing the hash value h1, and initiates the TLS handshake with another user enclave using the X.509 certificate embedded with the quote Q; (2) The other side of the TLS handshake enclave extracts the quote Q from the X.509 certificate, calculates the hash value h2, and checks if the hash value h1 contained in the quote Q is the same as the re-computed hash value h2; if different, terminate the TLS handshake; if the same, forward the quote Q to the attestation enclave on the node; (3) According to the quote Q and the attestation verification report returned by the attestation enclave, compare the MRENCLAVE measurement value and the MRSIGNER measurement value with the expected value, and decide whether to trust the user enclave according to the comparison result.

7. The method of claim 2 or 3, wherein, The revocation phase comprises the following steps: (1) When a user enclave is disconnected from the network, the user enclave on the other side of the channel initiates a revocation request to the attestation enclave on the node, and attaches the signature on the evidence used to establish trust, then the attestation enclave forwards the revocation request to the authentication enclave in the network domain; (2) The authentication enclave L that receives the revocation request γ sends a five-tuple message <Acc, L, i, γ> to the cluster P consisting of at least one authentication enclave. L L,I ,i L,I ,γ> wherein Acc represents that the message is an Accept message type in the Paxos consensus algorithm, i L represents the sequence number of the authentication enclave L, i L,I represents the sequence number of the revocation request initiated by the authentication enclave L, and N represents the total number of authentication enclaves, represents the floor function; (3) When any authentication enclave R receives the message <Acc,L,i L ,i L,I ,γ>, record a triple L ,i L,I ,γ>, and reply a response message to the authentication enclave L <AccOK,i L,I >​ Wherein, AccOK represents that the message is a response to the Accept message; (4) When the authentication enclave L receives at least Response message <AccOK,i L,I >, the revocation request γ is recorded in the revocation list to complete the revocation, and the message is sent <Com,L,i L ,i L,I ,γ> to all other authentication enclaves; Wherein, Com represents that the message is a Commit message type in the Paxos consensus algorithm; (5) When any authentication enclave R receives the message <Com, L, i L , L,I , γ>, it records the revocation request γ to the revocation list to complete the revocation, and replies to the authentication enclave L with the message <Com OK, i L,I >; Wherein, ComOK represents that the message is a response to the Commit message.

8. The method of claim 2 or 3, wherein, Create a unified EPID group through a consensus algorithm, comprising the steps of: (1) Each authentication enclave initializes a random timer t individually. Once the timer t of a certain authentication enclave A expires, the authentication enclave increases its internal term number term = term + 1, votes for itself, and sends an election request <Election, i A , term> to all other authentication enclaves in the cluster, where Election represents the election message type, i A represents the sequence number of the authentication enclave A; (2) If the other authentication enclaves receiving the election request have not voted within the term, they will vote for the authentication enclave corresponding to the first received election request, and send a message <Vote, term> to it, wherein Vote represents the vote message type; (3) Once a certain authentication enclave A accumulates at least votes, it becomes the leader authentication enclave in the cluster; after becoming the leader authentication enclave, the authentication enclave A generates a group public key pk G and a group private key sk G , creates an EPID issuer, and sends a broadcast message <Notification, i A , term, pk G , sk G > to all other authentication enclaves, where N represents the total number of authentication enclaves, represents the ceiling, Notification represents the broadcast message type, i A represents the serial number of the authentication enclave A, and term represents the term; (4) Other authenticated enclaves that receive the broadcast message retrieve and store the group public key pk carried by the message G and the group private key sk G and create their respective EPID issuer.

Images