CN118631435A - Cluster key negotiation method based on consensus mechanism and trusted execution environment - Google Patents

Abstract

A cluster key negotiation method based on a consensus mechanism and a trusted execution environment. The method comprises the steps of creating an initial TEE cluster and deploying a block chain network based on a consensus mechanism; uploading the root certificate to the blockchain network through a trusted bridge function call intelligent contract; safely issuing the secret key; uploading the remote proving result to the blockchain network through a consensus mechanism; performing local certification; uploading the local proving result to the blockchain network through a consensus mechanism; and carrying out safe data transmission, communication and the like. The invention has the following effects: communication complexity is reduced: the block chain consensus mechanism is combined with the TEE technology and used for key negotiation in a cluster environment, so that a novel security assurance method is provided. The dynamic management and updating of the key can be realized, and the safety and stability of the system in the dynamic change of the node are ensured. The decentralization feature of the hardware-level security and consensus mechanism provided by the TEE reduces reliance on external trust.

Description

Cluster key negotiation method based on consensus mechanism and trusted execution environment

Technical Field

The invention belongs to the technical field of privacy computation and hardware security in network security, and particularly relates to a cluster key negotiation method based on a consensus mechanism and a trusted execution environment.

Background

With the rapid development of cloud computing and internet of things (IoT) technology, distributed systems are becoming increasingly important in processing massive amounts of data and providing computing services. However, this also presents new challenges for data security and privacy protection. Particularly in a cluster environment, how to ensure the communication safety between nodes and efficiently carry out key negotiation becomes a problem to be solved.

In the traditional TEE cluster, mutual authentication and remote verification are needed between the TEE nodes, secret keys are negotiated, but when a system is initialized, the interaction complexity is high, the complexity of O (n-2) is achieved, and meanwhile, each TEE node needs to maintain other node information, including secret keys for remote authentication, code measurement of a trusted program and the like, so that the node maintenance cost is high.

Disclosure of Invention

In order to solve the above problems, an object of the present invention is to provide a cluster key negotiation method based on a consensus mechanism and a trusted execution environment.

In order to achieve the above objective, the cluster key negotiation method based on the consensus mechanism and the trusted execution environment provided by the present invention comprises the following steps performed in sequence:

Step 1, an initial TEE cluster is established through Kubernets, a blockchain network based on a consensus mechanism is deployed, and then the initial TEE cluster is divided into three roles of a TEE-Server, a TEE-Sentinel and a TEE-Worker, and corresponding authorities are configured;

Step 2, generating a root certificate and a secret key in a trusted execution environment of the TEE-Server, sealing and storing the root certificate, and uploading the root certificate to a blockchain network through a trusted bridge function call intelligent contract;

Step 3, the TEE-Sentinel actively initiates a key negotiation request to the TEE-Server for remote certification to ensure that the TEE-Sentinel is trusted, and then the TEE-Server safely issues the key to the TEE-Sentinel;

Step 4, the block chain network node verifies the remote proving process, and uploads the remote proving result to the block chain network through a consensus mechanism;

Step 5, the TEE-workbench actively initiates a key negotiation request to the TEE-sentel to carry out local certification so as to ensure that the TEE-workbench is credible, and then the TEE-sentel safely transmits the key to the TEE-workbench;

Step 6, the local proving process is verified by the block chain network node, and the local proving result is uploaded to the block chain network through a consensus mechanism;

And 7, carrying out secure data transmission and communication.

In step 1, the specific method for creating an initial TEE cluster and deploying a blockchain network based on a consensus mechanism through Kubernets, and then dividing the initial TEE cluster into three roles of TEE-Server, TEE-sentel and TEE-Worker and configuring corresponding authorities is as follows:

step 1.1, using Kubernetes API call kubectl apply, importing a cluster configuration file, creating an initial TEE cluster;

Step 1.2, deploying a blockchain network based on a consensus mechanism, wherein the consensus mechanism supports Bayesian fault tolerance, and deploying four alliance chain nodes in the blockchain network, and performing consensus by using PBFT;

Step 1.3, defining three different roles of a TEE-Server, a TEE-Sentinel and a TEE-Worker in an initial TEE cluster, and configuring corresponding rights;

The TEE-Server is a centralized authentication service realized based on the TEE, and is used for centrally managing keys and authorizations and responsible for issuing and managing keys related to the TEE-Sentinel and the TEE-Worker;

the TEE-Sentinel is a Sentinel service realized based on the TEE, performs remote certification with the TEE-Server to obtain a key, and distributes the key to the TEE-workbench;

The TEE-Worker is a cooperative computing node that actually communicates and executes business logic, obtains a key by performing local certification with the TEE-Sentinel, and communicates and executes business logic using the key.

In step 2, the specific method for generating the root certificate and the secret key in the trusted execution environment of the TEE-Server, sealing and storing the root certificate and uploading the root certificate to the blockchain network through the trusted bridge function call intelligent contract is as follows:

step 2.1, configuring a trusted execution environment in a TEE-Server, and starting a root certificate Cert _Root generation program;

step 2.2, a custom trust root is established, a pair of keys (SK _Root,PK_Root) is generated by using an RSA encryption algorithm, in which SK _Root is a private key of the root and PK _Root is a corresponding public key, then the root signs its own public key PK _Root by using its private key SK _Root, and generates a root certificate Cert _Root to ensure its trustworthiness and unpredictability, and a function of generating the root certificate Cert _Root is represented by CA _sign, and the process is represented as:

Cert_Root←CA_sign(PK_Root,SK_Root)

step 2.3, generating a TEE key pair (SK _TEE,PK_TEE) in the initial TEE cluster by using an RSA encryption algorithm, wherein the SGX_ tsgxSSL library used by the RSA encryption algorithm is based on the SGX hardware inherent key, so that the credibility of key generation in the initial TEE cluster is ensured; the process of generating the TEE key pair is expressed as:

(SK_TEE,PK_TEE)＝SGX_tagxSSL.RSA()

Step 2.4, the trusted program obtains a report by calling SGXEREPORT an instruction, wherein the report contains a code metric Metics and other information info _Enclave of the current running software, and then the trusted program encrypts the report by using a private key SK _TEE to obtain a ciphertext E _report, and the process is expressed as follows:

E_report←Encrypt(report＝{metrics,info_Enclave…},SK_TeE)

Step 2.5, the trusted program transfers the public key PK _TEE and the ciphertext E _report into the customized trust root by invoking the trusted bridge function Ocall of Enclave, the customized trust root decrypts the ciphertext E _report into the original report through the public key PK _TEE, obtains the code metric Metics of the current Enclave and other information of the Enclave, if decryption is successful, the public key PK _TEE is proved to be the trusted public key generated by the current Enclave, the report is the trusted code metric of the current Enclave, the result Res is generated, and the verification process of the result Res is expressed as follows:

Res←Verify(PK_TEE,E_report)

Step 2.6, if the root certificate Cert _Root passes verification, a trusted certificate Cert _Enclave is issued to the Encalve, the trusted certificate Cert _Enclave comprises two parts, namely signature and plaintext information msg, and the plaintext information msg comprises the root certificate Cert _Root, the validity Time of the trusted certificate, the report of the trusted execution environment and the public key PK _TEE of the trusted execution environment; the plaintext information msg is expressed as:

msg＝{Cert_Root,Time,report,PK_TEE}

Step 2.7, performing hash operation on the plaintext information msg by using SHA256 algorithm through the root certificate Cert _Root to obtain a hash value hash _msg, and then encrypting the hash value hash _msg by using the private key SK _Root of the root certificate Cert _Root to obtain a signature _msg, which is expressed as:

sign_msg←Encrypt(hash_msg＝sha256(msg),SK_Root)

The trusted certificate Cert _Enclave is expressed as:

Cert_Enclave＝{msg,sign_msg}

Step 2.8, performing sealing treatment on the generated root certificate Cert _Root and the secret key to protect the security from being accessed by an external environment;

Step 2.9, securely uploading the root certificate Cert _Root to the blockchain network by trusted bridge function invoking the smart contract.

In step 3, the TEE-sentel actively initiates a key negotiation request to the TEE-Server for remote attestation to ensure that the TEE-sentel is trusted, and then the specific method for the TEE-Server to securely issue the key to the TEE-sentel is as follows:

Step 3.1, a handshake request is initiated to the TEE-Server by the TEE-Sentinel, and the request parameters comprise random character strings RandomStr;

step 3.2, after the TEE-Server receives the handshake request, responding to the TEE-Sentinel, wherein the response resp comprises signature sig2 of hash values of random string RandomStr2, certificate certTEE-Server and private key pair (RandomStr + RandomStr 2) of certificate certTEE-Server, and the response resp is defined as:

Resp＝{Randommtr2，certKeyServer，sig2}

Then, the hash value of (RandomStr 1+ RandomStr 2) is signed by using the private key of the certificate certTEE-Server to generate a signature sig2, and the process is as follows:

sig2＝sign(hash(RandomStr1+RandomStr2)，SK)

step 3.3, after the TEE-Sentinel receives the response, firstly verifying that the certificate certTEE-Server has the legal signature of the root certificate Cert _Root, simultaneously resolving the metric information Metrics from the certificate certTEE-Server, ensuring that the metric information Metrics is strictly equal to the metric information at the time of starting, and simultaneously verifying whether the signature sig2 is the legal signature of the hash value of (RandomStr 1+ RandomStr 2) by using the public key of the certificate certTEE-Server, and generating a verification result res, which is expressed as:

res＝VerifySign(certKeyServer,sig2,PK)

Step 3.4, the TEE-sentel initiates a session key request to the TEE-Server, and the request parameter Reqparms is composed of a signature sig3 of a hash value of a certificate certTEE-sentel and a private key pair (RandomStr 1+ RandomStr 2) of the certificate certTEE-sentel issued after the root certificate Cert _Root verifies that the TEE-sentel environment is legal, and is defined as:

Step 3.5, after receiving the session key request of the TEE-Sentinel, the TEE-Server verifies that the certificate certTEE-Sentinel has the legal signature of the root certificate Cert _Root, verifies the validity of the signature sig3, and parses the data encryption public key PK from the expansion field of the certTEE-Sentinel to generate a verification result Res, which is expressed as:

Res＝VerifySign(certKeyGuard,sig3,PK)

Step 3.6, the TEE-Server sends a response of the session key to the TEE-Sentinel, wherein the response content Resp comprises a code Metric of the certificate certRemote, TEE-Sentinel which is used by the TEE-Sentinel later and a session key SK encrypted by the data encryption public key PK; compared with certTEE-Sentinel, the certificate of certRemote is changed from the root certificate Cert _Root to TEE-Server, and the response content Resp is defined as:

Resp＝{cerRemote,Metric,SK}

and 3.7, after receiving the response of the TEE-Server, the TEE-Sentinel uses the private key of the TEE-Server to decrypt the session key SK, and if the decryption is successful, the remote certification is successful.

In step 4, the blockchain network node verifies the remote proving process, and uploads the remote proving result to the blockchain network through a consensus mechanism, wherein the specific method comprises the following steps:

Step 4.1, the block chain network node receives a remote attestation request of the TEE-Server and starts a verification process;

step 4.2, verifying the validity and the integrity of remote certification through a consensus mechanism among the block chain network nodes;

And 4.3, uploading the remote proving result to the blockchain network after the verification is passed.

In step 5, the TEE-Worker actively initiates a key negotiation request to the TEE-Sentinel for local certification, so as to ensure that the TEE-Worker is trusted, and then the TEE-Sentinel securely issues the key to the TEE-Worker by the specific method comprising:

Step 5.1, the TEE-workbench initiates an authentication request to the TEE-Sentinel, after the TEE-Sentinel receives the authentication request of the TEE-workbench, the TEE-workbench responds to the TEE-workbench, the response resp1 comprises a public key PK randomly generated by RSA and a code Metric of the TEE-Sentinel, and the response resp1 is defined as:

resp1＝GenResp1(PK＝RSA(),Metric)

after receiving the response, the TEE-workbench constructs a request req2 based on the response resp1, and the construction process of the request req2 is as follows: randomly generating a public key PK2 by using RSA, and defining an SGX report reportW and a unique identifier uuid; the process of constructing request req2 is expressed as:

req2＝GenReq2(uuid,version,PK2,reportW)

Step 5.3, using the request req2 as a request parameter, and requesting the TEE-Sentinel to distribute keys and certificates;

And 5.4, after receiving the request of distributing the secret key by the TEE-Septinel, calculating a shared public key PK3 by means of the public key PK and the public key PK2, verifying the validity of the request req2, and then issuing the shared public key PK3 to the TEE-Worker.

In step 6, the blockchain network node verifies the local proving process, and uploads the local proving result to the blockchain network through a consensus mechanism, wherein the specific method comprises the following steps:

Step 6.1, the block chain network node receives a local proving verification request of the TEE-Sentinel;

step 6.2, verifying the authenticity of the local certificate of the TEE-workbench through a consensus mechanism by the blockchain network node;

And 6.3, if the verification is successful, uploading the local proving result to the blockchain network.

The cluster key negotiation method based on the consensus mechanism and the trusted execution environment has the following beneficial effects:

1. the communication complexity is reduced: the invention reduces the complexity of the traditional key negotiation O (n≡2) to O (n), thereby greatly enhancing the performance of cluster key negotiation.

2. Combining consensus mechanism and TEE: the invention combines a block chain consensus mechanism with a TEE technology for key negotiation in a cluster environment, thereby providing a novel security assurance method.

3. Dynamic key management: by utilizing a consensus mechanism, the method can realize dynamic management and updating of the secret key, and ensures the safety and stability of the system when the node changes dynamically.

4. Reducing trust assumptions: while conventional key agreement methods typically rely on trusted third parties or preset security assumptions, the present invention reduces reliance on external trust through the decentralization nature of the hardware-level security and consensus mechanisms provided by the TEE.

Drawings

FIG. 1 is a flow chart of a cluster key negotiation method based on a consensus mechanism and a trusted execution environment provided by the invention;

FIG. 2 is a node architecture diagram of the present invention;

FIG. 3 is a schematic diagram of remote attestation of the present invention;

FIG. 4 is a schematic diagram of a local certificate of the present invention;

fig. 5 is a performance test chart of the present invention:

Detailed Description

The invention will now be described in detail with reference to the drawings and specific examples.

As shown in fig. 1 to fig. 4, the cluster key negotiation method based on the consensus mechanism and the trusted execution environment provided by the invention comprises the following steps performed in sequence:

Step 1, an initial TEE cluster is established through Kubernets, a blockchain network based on a consensus mechanism is deployed, and then the initial TEE cluster is divided into three roles of a TEE-Server, a TEE-Sentinel and a TEE-Worker, and corresponding authorities are configured;

The specific method comprises the following steps:

step 1.1, using Kubernetes API call kubectl apply, importing a cluster configuration file, creating an initial TEE cluster;

Step 1.2, deploying a blockchain network based on a consensus mechanism, wherein the consensus mechanism supports Bayesian fault tolerance, and deploying four alliance chain nodes in the blockchain network, and performing consensus by using PBFT;

Step 1.3, defining three different roles of a TEE-Server, a TEE-Sentinel and a TEE-Worker in an initial TEE cluster, and configuring corresponding rights;

As shown in fig. 2, the TEE-Server is a centralized authentication service implemented based on TEE, and is responsible for centrally managing keys and authorizations, issuing and managing TEE-sentel and TEE-Worker related keys;

the TEE-Sentinel is a Sentinel service realized based on the TEE, performs remote certification with the TEE-Server to obtain a key, and distributes the key to the TEE-workbench;

The TEE-Worker is a cooperative computing node that actually communicates and executes business logic, obtains a key by performing local certification with the TEE-Sentinel, and communicates and executes business logic using the key.

Step 2, generating a root certificate and a secret key in a trusted execution environment of the TEE-Server, sealing and storing the root certificate, and uploading the root certificate to a blockchain network through a trusted bridge function call intelligent contract;

The specific method comprises the following steps:

step 2.1, configuring a trusted execution environment in a TEE-Server, and starting a root certificate Cert _Root generation program;

step 2.2, a custom trust root is established, a pair of keys (SK _Root,PK_Root) is generated by using an RSA encryption algorithm, in which SK _Root is a private key of the root and PK _Root is a corresponding public key, then the root signs its own public key PK _Root by using its private key SK _Root, and generates a root certificate Cert _Root to ensure its trustworthiness and unpredictability, and a function of generating the root certificate Cert _Root is represented by CA _sign, and the process is represented as:

Cert_Root←CA_sign(PK_Root,SK_Root)

step 2.3, generating a TEE key pair (SK _TEE,PK_TEE) in the initial TEE cluster by using an RSA encryption algorithm, wherein the SGX_ tsgxSSL library used by the RSA encryption algorithm is based on the SGX hardware inherent key, so that the credibility of key generation in the initial TEE cluster is ensured; the process of generating the TEE key pair is expressed as:

(SK_TEE,PK_TEE)＝SGX_tsgxSSL.RSA()

Step 2.4, the trusted program obtains a report by calling SGX EREPORT an instruction, wherein the report contains a code metric MetiCs and other information info _Enclave of the current running software, and then the trusted program encrypts the report by using a private key SK _TEE to obtain a ciphertext E _report, and the process is expressed as follows:

E_report←Encrypt(report＝{metrics,info_Enclave…},SK_TEE)

Step 2.5, the trusted program transfers the public key PK _TEE and the ciphertext E _report into the customized trust root by invoking the trusted bridge function Ocall of Enclave, and the customized trust root decrypts the ciphertext E _report into the original report by the public key PK _TEE, and obtains the code metric Metics of the current Enclave and other information of the Enclave. Since public key PK _TEE and ciphertext E _report are passed through Enclave's trusted bridge function Ocall, security and trust in the transmission process can be ensured, and if decryption is successful, the trusted public key generated by public key PK _TEE for the current Enclave is proved, report is a trusted code metric of the current Enclave, a result Res is generated, and the verification process of the result Res is expressed as:

Res←Verify(PK_TEE,E_report)

Step 2.6, if the root certificate Cert _Root passes verification, a trusted certificate Cert _Enclave is issued to the Encalve, the trusted certificate Cert _Enclave comprises two parts, namely signature and plaintext information msg, and the plaintext information msg comprises the root certificate Cert _Root, the validity Time of the trusted certificate, the report of the trusted execution environment and the public key PK _TEE of the trusted execution environment; the plaintext information msg is expressed as:

msg＝{Cert_Root,Time,report,PK_TEE}

Step 2.7, performing hash operation on the plaintext information msg by using SHA256 algorithm through the root certificate Cert _Root to obtain a hash value hash _msg, and then encrypting the hash value hash _msg by using the private key SK _Root of the root certificate Cert _Root to obtain a signature _msg, which is expressed as:

sign_msg←Encrypt(hash_msg＝sha256(msg),SK_Root)

The trusted certificate Cert _Enclave is expressed as:

Cert_Enclave＝{msg,sign_msg}

Step 2.8, performing sealing treatment on the generated root certificate Cert _Root and the secret key to protect the security from being accessed by an external environment;

Step 2.9, securely uploading the root certificate Cert _Root to the blockchain network by trusted bridge function invoking the smart contract.

Step 3, as shown in fig. 3, the TEE-sentel actively initiates a key negotiation request to the TEE-Server for remote certification to ensure that the TEE-sentel is trusted, and then the TEE-Server securely issues the key to the TEE-sentel;

The specific method comprises the following steps:

Step 3.1, a handshake request is initiated to the TEE-Server by the TEE-Sentinel, and the request parameters comprise random character strings RandomStr;

step 3.2, after the TEE-Server receives the handshake request, responding to the TEE-Sentinel, wherein the response resp comprises signature sig2 of hash values of random string RandomStr2, certificate certTEE-Server and private key pair (RandomStr + RandomStr 2) of certificate certTEE-Server, and the response resp is defined as:

Resp＝{RandomStr2，certKeyServer，sig2}

Then, the hash value of (RandomStr 1+ RandomStr 2) is signed by using the private key of the certificate certTEE-Server to generate a signature sig2, and the process is as follows:

sig2＝sign(hash(RandomStr1+RandomStr2)，SK)

step 3.3, after the TEE-Sentinel receives the response, firstly verifying that the certificate certTEE-Server has the legal signature of the root certificate Cert _Root, simultaneously resolving the metric information Metrics from the certificate certTEE-Server, ensuring that the metric information Metrics is strictly equal to the metric information at the time of starting, and simultaneously verifying whether the signature sig2 is the legal signature of the hash value of (RandomStr 1+ RandomStr 2) by using the public key of the certificate certTEE-Server, and generating a verification result res, which is expressed as:

res＝VerifySign(certKeyServer,sig2,PK)

Step 3.4, the TEE-sentel initiates a session key request to the TEE-Server, and the request parameter Reqparms is composed of a signature sig3 of a hash value of a certificate certTEE-sentel and a private key pair (RandomStr 1+ RandomStr 2) of the certificate certTEE-sentel issued after the root certificate Cert _Root verifies that the TEE-sentel environment is legal, and is defined as:

Step 3.5, after receiving the session key request of the TEE-Sentinel, the TEE-Server verifies that the certificate certTEE-Sentinel has the legal signature of the root certificate Cert _Root, verifies the validity of the signature sig3, and parses the data encryption public key PK from the expansion field of the certTEE-Sentinel to generate a verification result Res, which is expressed as:

Res＝VerifySign(certKeyGuard,sig3,PK)

Step 3.6, the TEE-Server sends a response of the session key to the TEE-Sentinel, and the response content Resp includes the code Metric of the certificate certRemote, TEE-Sentinel that the TEE-Sentinel should use subsequently and the session key SK encrypted by the data encryption public key PK. Compared with certTEE-Sentinel, the certificate of certRemote is changed from the root certificate Cert _Root to TEE-Server, and the response content Resp is defined as:

Rsep＝{certRemote,Metric,SK}

and 3.7, after receiving the response of the TEE-Server, the TEE-Sentinel uses the private key of the TEE-Server to decrypt the session key SK, and if the decryption is successful, the remote certification is successful.

Step 4, the block chain network node verifies the remote proving process, and uploads the remote proving result to the block chain network through a consensus mechanism;

The specific method comprises the following steps:

Step 4.1, the block chain network node receives a remote attestation request of the TEE-Server and starts a verification process;

step 4.2, verifying the validity and the integrity of remote certification through a consensus mechanism among the block chain network nodes;

And 4.3, uploading the remote proving result to the blockchain network after the verification is passed.

Step 5, as shown in fig. 5, the TEE-Worker actively initiates a key negotiation request to the TEE-sentel to perform local certification, ensure that the TEE-Worker is trusted, and then the TEE-sentel safely issues the key to the TEE-Worker;

The specific method comprises the following steps:

Step 5.1, the TEE-workbench initiates an authentication request to the TEE-Sentinel, after the TEE-Sentinel receives the authentication request of the TEE-workbench, the TEE-workbench responds to the TEE-workbench, the response resp1 comprises a public key PK randomly generated by RSA and a code Metric of the TEE-Sentinel, and the response resp1 is defined as:

resp1＝GenResp1(PK＝RSA(),Metric)

after receiving the response, the TEE-workbench constructs a request req2 based on the response resp1, and the construction process of the request req2 is as follows: randomly generating a public key PK2 by using RSA, and defining an SGX report reportW and a unique identifier uuid; the process of constructing request req2 is expressed as:

req2＝GenReq2(uuid,version,PK2,reportW)

Step 5.3, using the request req2 as a request parameter, and requesting the TEE-Sentinel to distribute keys and certificates;

And 5.4, after receiving the request of distributing the secret key by the TEE-Septinel, calculating a shared public key PK3 by means of the public key PK and the public key PK2, verifying the validity of the request req2, and then issuing the shared public key PK3 to the TEE-Worker.

And 6, verifying the local proving process by the blockchain network node, and uploading the local proving result to the blockchain network through a consensus mechanism.

The specific method comprises the following steps:

Step 6.1, the block chain network node receives a local proving verification request of the TEE-Sentinel;

step 6.2, verifying the authenticity of the local certificate of the TEE-workbench through a consensus mechanism by the blockchain network node;

And 6.3, if the verification is successful, uploading the local proving result to the blockchain network.

And 7, carrying out secure data transmission and communication.

Experiment:

The method is used for carrying out pressure test by JMeter, and the inflection point of the method performance is found by gradually increasing concurrent pressure, so that the optimal processing capacity is obtained. When the concurrency number is increased from 200 to 800 gradually, the pressure measurement mode is pressure measurement for 5 minutes, the average response time is increased linearly, when the concurrency amount reaches 800, the average successful transaction number per second reaches 187 strokes/s, the average algorithm complexity is O (n), and the average successful transaction number per second and the average response time of the test result of the cluster key negotiation method are shown in a histogram in fig. 5.

Claims (7)

1. A cluster key negotiation method based on a consensus mechanism and a trusted execution environment is characterized in that: the cluster key negotiation method comprises the following steps in sequence:

Step 1, an initial TEE cluster is established through Kubernets, a blockchain network based on a consensus mechanism is deployed, and then the initial TEE cluster is divided into three roles of a TEE-Server, a TEE-Sentinel and a TEE-Worker, and corresponding authorities are configured;

Step 2, generating a root certificate and a secret key in a trusted execution environment of the TEE-Server, sealing and storing the root certificate, and uploading the root certificate to a blockchain network through a trusted bridge function call intelligent contract;

Step 3, the TEE-Sentinel actively initiates a key negotiation request to the TEE-Server for remote certification to ensure that the TEE-Sentinel is trusted, and then the TEE-Server safely issues the key to the TEE-Sentinel;

Step 4, the block chain network node verifies the remote proving process, and uploads the remote proving result to the block chain network through a consensus mechanism;

Step 5, the TEE-workbench actively initiates a key negotiation request to the TEE-sentel to carry out local certification so as to ensure that the TEE-workbench is credible, and then the TEE-sentel safely transmits the key to the TEE-workbench;

Step 6, the local proving process is verified by the block chain network node, and the local proving result is uploaded to the block chain network through a consensus mechanism;

And 7, carrying out secure data transmission and communication.

2. The cluster key agreement method based on a consensus mechanism and a trusted execution environment according to claim 1, wherein: in step 1, the specific method for creating an initial TEE cluster and deploying a blockchain network based on a consensus mechanism through Kubernets, and then dividing the initial TEE cluster into three roles of TEE-Server, TEE-sentel and TEE-Worker and configuring corresponding authorities is as follows:

step 1.1, using Kubernetes API call kubectl apply, importing a cluster configuration file, creating an initial TEE cluster;

Step 1.2, deploying a blockchain network based on a consensus mechanism, wherein the consensus mechanism supports Bayesian fault tolerance, and deploying four alliance chain nodes in the blockchain network, and performing consensus by using PBFT;

step 1.3, defining three different roles of a TEE-Server, a TEE-Sentinel and a TEE-Work in an initial TEE cluster, and configuring corresponding rights;

The TEE-Server is a centralized authentication service realized based on the TEE, and is used for centrally managing keys and authorizations and responsible for issuing and managing keys related to the TEE-Sentinel and the TEE-Worker;

the TEE-Sentinel is a Sentinel service realized based on the TEE, performs remote certification with the TEE-Server to obtain a key, and distributes the key to the TEE-workbench;

The TEE-Worker is a cooperative computing node that actually communicates and executes business logic, obtains a key by performing local certification with the TEE-Sentinel, and communicates and executes business logic using the key.

3. The cluster key agreement method based on a consensus mechanism and a trusted execution environment according to claim 1, wherein: in step 2, the specific method for generating the root certificate and the secret key in the trusted execution environment of the TEE-Server, sealing and storing the root certificate and uploading the root certificate to the blockchain network through the trusted bridge function call intelligent contract is as follows:

step 2.1, configuring a trusted execution environment in a TEE-Server, and starting a root certificate Cert _Root generation program;

step 2.2, a custom trust root is established, a pair of keys (SK _Root,PK_Root) is generated by using an RSA encryption algorithm, in which SK _Root is a private key of the root and PK _Root is a corresponding public key, then the root signs its own public key PK _Root by using its private key SK _Root, and generates a root certificate Cert _Root to ensure its trustworthiness and unpredictability, and a function of generating the root certificate Cert _Root is represented by CA _sign, and the process is represented as:

Cert_Root←CA_sign(PK_Root,SK_Root)

step 2.3, generating a TEE key pair (SK _TEE,PK_TEE) in the initial TEE cluster by using an RSA encryption algorithm, wherein the SGX_ tsgxSSL library used by the RSA encryption algorithm is based on the SGX hardware inherent key, so that the credibility of key generation in the initial TEE cluster is ensured; the process of generating the TEE key pair is expressed as:

(SK_TEE,PK_TEE)＝SGX_tsgxSSL.RSA()

step 2.4, the trusted program obtains a report by calling SGX EREPORT an instruction, wherein the report contains a code metric Metics and other information info _Enclave of the current running software, and then the trusted program encrypts the report by using a private key SK _TEE to obtain a ciphertext E _report, and the process is expressed as follows:

E_report←Encrypt(report＝{metrics,info_Enclave...},SK_TEE)

Step 2.5, the trusted program transfers the public key PK _TEE and the ciphertext E _report into the customized trust root by invoking the trusted bridge function Ocall of Enclave, the customized trust root decrypts the ciphertext E _report into the original report through the public key PK _TEE, obtains the code metric Metics of the current Enclave and other information of the Enclave, if decryption is successful, the public key PK _TEE is proved to be the trusted public key generated by the current Enclave, the report is the trusted code metric of the current Enclave, the result Res is generated, and the verification process of the result Res is expressed as follows:

Res←Verify(PK_TEE,E_report)

Step 2.6, if the root certificate Cert _Root passes verification, a trusted certificate Cer _Enclave is issued to the Encalve, the trusted certificate Cert _Enclave comprises two parts, namely signature and plaintext information msg, and the plaintext information msg comprises the root certificate Cert _Root, the validity Time of the trusted certificate, the report of the trusted execution environment and the public key PK _TEE of the trusted execution environment; the plaintext information msg is expressed as:

msg＝{Cert_Root,Time,report,PK_TEE}

Step 2.7, performing hash operation on the plaintext information msg by using SHA256 algorithm through the root certificate Cert _Root to obtain a hash value hash _msg, and then encrypting the hash value hash _msg by using the private key SK _Root of the root certificate Cert _Root to obtain a signature _msg, which is expressed as:

sign_msg←Encrypt(hash_msg＝sha256(msg),SK_Root)

The trusted certificate Cert _Enclave is expressed as:

cert_Enclave＝{msg,sign_msg}

Step 2.8, performing sealing treatment on the generated root certificate Cert _Root and the secret key to protect the security from being accessed by an external environment;

Step 2.9, securely uploading the root certificate Cert _Root to the blockchain network by trusted bridge function invoking the smart contract.

4. The cluster key agreement method based on a consensus mechanism and a trusted execution environment according to claim 1, wherein: in step 3, the TEE-sentel actively initiates a key negotiation request to the TEE-Server for remote attestation to ensure that the TEE-sentel is trusted, and then the specific method for the TEE-Ser to securely issue the key to the TEE-sentel is as follows:

Step 3.1, a handshake request is initiated to the TEE-Server by the TEE-Sentinel, and the request parameters comprise random character strings RandomStr;

step 3.2, after the TEE-Server receives the handshake request, responding to the TEE-Sentinel, wherein the response resp comprises signature sig2 of hash values of random string RandomStr2, certificate certTEE-Server and private key pair (RandomStr + RandomStr 2) of certificate certTE E-Server, and the response resp is defined as:

Resp＝{RandomStr2，certKeyServer，sig2}

Then, the hash value of (RandomStr 1+ RandomStr 2) is signed by using the private key of the certificate certTEE-Server to generate a signature sig2, and the process is as follows:

sig2＝sign(hash(RandomStr1+RandomStr2)，SK)

step 3.3, after the TEE-Sentinel receives the response, firstly verifying that the certificate certTEE-Server has the legal signature of the root certificate Cert _Root, simultaneously resolving the metric information Metrics from the certificate certTEE-Server, ensuring that the metric information Metrics is strictly equal to the metric information at the time of starting, and simultaneously verifying whether the signature sig2 is the legal signature of the hash value of (RandomStr 1+ RandomStr 2) by using the public key of the certificate certTEE-Server, and generating a verification result res, which is expressed as:

res＝VerifySign(certKeyServer，sig2，PK)

Step 3.4, the TEE-sentel initiates a session key request to the TEE-Server, and the request parameter Reqparms is composed of a signature sig3 of a hash value of a certificate certTEE-sentel and a private key pair (RandomStr 1+ RandomStr 2) of the certificate certTEE-sentel issued after the root certificate Cert _Root verifies that the TEE-sentel environment is legal, and is defined as:

Step 3.5, after receiving the session key request of the TEE-Sentinel, the TEE-Server verifies that the certificate certTEE-Sentinel has the legal signature of the root certificate Cert _Root, verifies the validity of the signature sig3, and parses the data encryption public key PK from the expansion field of the certTEE-Sentinel to generate a verification result Res, which is expressed as:

Res＝VerifySign(certKeyGuard，sig3,PK)

Step 3.6, the TEE-Server sends a response of the session key to the TEE-Sentinel, wherein the response content Resp comprises a code Metric of the certificate certRemote, TEE-Sentinel which is used by the TEE-Sentinel later and a session key SK encrypted by the data encryption public key PK; compared with certTEE-Sentinel, the certificate of certRemote is changed from the root certificate Cert _Root to TEE-Server, and the response content Resp is defined as:

Resp＝{certRemote，Metric，SK}

and 3.7, after receiving the response of the TEE-Server, the TEE-Sentinel uses the private key of the TEE-Server to decrypt the session key SK, and if the decryption is successful, the remote certification is successful.

5. The cluster key agreement method based on a consensus mechanism and a trusted execution environment according to claim 1, wherein: in step 4, the blockchain network node verifies the remote proving process, and uploads the remote proving result to the blockchain network through a consensus mechanism, wherein the specific method comprises the following steps:

Step 4.1, the block chain network node receives a remote attestation request of the TEE-Server and starts a verification process;

step 4.2, verifying the validity and the integrity of remote certification through a consensus mechanism among the block chain network nodes;

And 4.3, uploading the remote proving result to the blockchain network after the verification is passed.

6. The cluster key agreement method based on a consensus mechanism and a trusted execution environment according to claim 1, wherein: in step 5, the TEE-Worker actively initiates a key negotiation request to the TEE-Sentinel for local certification, so as to ensure that the TEE-Worker is trusted, and then the TEE-Sentinel securely issues the key to the TEE-Worker by the specific method comprising:

Step 5.1, the TEE-workbench initiates an authentication request to the TEE-Sentinel, after the TEE-Sentinel receives the authentication request of the TEE-workbench, the TEE-workbench responds to the TEE-workbench, the response resp1 comprises a public key PK randomly generated by RSA and a code Metric of the TEE-Sentinel, and the response resp1 is defined as:

resp1＝GenResp1(PK＝RSA()，Metric)

after receiving the response, the TEE-workbench constructs a request req2 based on the response resp1, and the construction process of the request req2 is as follows: randomly generating a public key PK2 by using RSA, and defining an SGX report reportW and a unique identifier uuid; the process of constructing request req2 is expressed as:

req2= GenReq2 (uuid, version, PK2, reportW) step 5.3, requesting TEE-Sentinel to distribute keys and certificates with the request req2 as a request parameter;

And 5.4, after receiving the request of distributing the secret key by the TEE-Septinel, calculating a shared public key PK3 by means of the public key PK and the public key PK2, verifying the validity of the request req2, and then issuing the shared public key PK3 to the TEE-Worker.

7. The cluster key agreement method based on a consensus mechanism and a trusted execution environment according to claim 1, wherein: in step 6, the blockchain network node verifies the local proving process, and uploads the local proving result to the blockchain network through a consensus mechanism, wherein the specific method comprises the following steps:

Step 6.1, the block chain network node receives a local proving verification request of the TEE-Sentinel;

step 6.2, verifying the authenticity of the local certificate of the TEE-workbench through a consensus mechanism by the blockchain network node;

And 6.3, if the verification is successful, uploading the local proving result to the blockchain network.