A blockchain privacy contract key system, key generation method, and usage method

Abstract

This invention discloses a blockchain privacy contract key system and its key generation and usage methods. The system includes a certificate coordination service module, a guard service module, and a privacy contract execution module. The certificate coordination service module is deployed independently in a trusted execution environment and is used to issue, manage, and store related keys and certificates. The guard service module corresponds one-to-one with a blockchain node and communicates and negotiates with the certificate coordination service module to obtain and cache keys and certificates. The guard service module and the certificate coordination service module perform remote authentication to ensure execution security between them. The privacy contract execution module is a virtual machine on the blockchain, providing a secure and private computing environment. The privacy contract execution module obtains relevant data by communicating with the certificate coordination service module through the guard service module. This invention allows multiple trusted environments to share the same key to decrypt encrypted data, simplifying key management and improving efficiency.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a blockchain privacy contract key system and a key generation and usage method. Background Technology

[0002] TEE (Trusted Execution Environment): A TEE is an independent processing environment with computation and storage capabilities, providing security and integrity protection. Its basic idea is to allocate a separate, isolated memory block within the hardware for sensitive data. All computations on sensitive data are performed within this memory block, and no other part of the hardware can access the information in this isolated memory block except through authorized interfaces, thereby achieving privacy-preserving computations on sensitive data.

[0003] In existing technologies, a single-point trusted environment is typically deployed. Each blockchain node executes privacy contract transactions and obtains the results by accessing this trusted environment. Traditional encryption systems require assigning different keys to each trusted environment, which leads to the complexity of key management and a waste of resources.

[0004] Meanwhile, the existing technical solution (CN110060054A) discloses a method, node, system, and storage medium for achieving privacy protection in a blockchain. This solution uses a TEE (Trusted Execution Environment) to complete the decryption, verification, execution, and encrypted reading and writing of transactions. However, in this solution, each node has its own TEE for executing encrypted transactions, which fails to address the problem that multiple trusted computing environments cannot use the same key to decrypt user encrypted input. Summary of the Invention

[0005] In view of the above-mentioned technical problems, the present invention provides a blockchain privacy contract key system and key generation and usage method that at least solves some of the above-mentioned technical problems, allowing multiple trusted environments to share the same key to decrypt encrypted data, thereby simplifying key management and improving system efficiency.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] In a first aspect, the present invention provides a blockchain privacy contract key system, the system comprising: a certificate coordination service module, a guard service module, and a privacy contract execution module, wherein:

[0008] The certificate coordination service module is a centralized coordination service module, deployed separately in a trusted execution environment. It is used to issue, manage and store the keys and certificates related to the guard service module and the privacy contract execution module, and to perform remote authentication with the guard service module.

[0009] The guard service module corresponds one-to-one with a blockchain node and is used to communicate and negotiate with the certificate coordination service module to obtain the key and certificate of the privacy contract execution module and cache them; the guard service module and the certificate coordination service module perform remote authentication to ensure the execution security of each other;

[0010] The privacy contract execution module is a virtual machine part on the blockchain, a resident service used to provide a secure and private computing environment. The privacy contract execution module obtains on-chain data through gRPC and communicates with the certificate coordination service module through the guard service module to obtain relevant data, rather than communicating directly with the certificate coordination service module.

[0011] Furthermore, a blockchain node contains multiple privacy contract execution modules.

[0012] Furthermore, one guard service module corresponds to multiple privacy contract execution modules on one blockchain node.

[0013] Furthermore, the same privacy contract execution module can only run one user's privacy contract.

[0014] Secondly, this invention also provides a method for generating blockchain privacy contract keys, applied to the aforementioned blockchain privacy contract key system, to complete mutual authentication between various modules and generate a corresponding private key and certificate for each module. The method includes the following steps:

[0015] 1) Remote authentication between the certificate coordination service module and the guard service module;

[0016] 2) Local authentication between the Guardian Service Module and the Privacy Contract Execution Module;

[0017] 3) Certificate issuance process.

[0018] Furthermore, the remote authentication between the certificate coordination service module and the guard service module includes:

[0019] (a) After the certificate coordination service module is initialized, the CA and Report will be uploaded to the blockchain;

[0020] (b) Hash MRENCLAVE and put it on the blockchain so that the certificate coordination service module can only accept access from the specified machine;

[0021] (c) When the Guard Service module is initialized, it generates a CSR and a pair of public and private keys (pk|sk), abbreviated as G_pk and G_sk;

[0022] (d) The Guardian Service Module requests access to the Certificate Reconciliation Service Module. First, it obtains the CA and Report from the on-chain Certificate Reconciliation Service Module. Then, it obtains the Proof returned by the Certificate Reconciliation Service Module and verifies the signature in the Proof using the public key in the CA, comparing it with the Report. Next, it obtains the public key in the CA and encrypts the random number and MRENCLAVE into an S_A, which, along with the Guardian Service Module's public key and CSR file, is transmitted to the Certificate Reconciliation Service Module. The Certificate Reconciliation Service Module decrypts S_A using its private key and retrieves the hash data of MRENCLAVE from the on-chain for comparison. It issues a certificate for the CSR, encrypts the random number using the Guardian Service Module's public key, signs the issued certificate using the Certificate Reconciliation Service Module's private key, and sends it back to the Guardian Service Module. The Guardian Service Module verifies the signature using the Certificate Reconciliation Service Module's public key and decrypts the random number using its private key, comparing it with the previously generated random number. If all verification steps pass, the remote authentication is successful.

[0023] Furthermore, the local authentication between the guard service module and the privacy contract execution module includes:

[0024] (a) The privacy contract execution module requests verification from the guard service module;

[0025] (b) The guard service module provides the first information as a response;

[0026] (c) The privacy contract execution module constructs the second information based on the first information and requests the guard service module to distribute the key and certificate;

[0027] (d) After receiving the second information, the guard service module calculates the shared public key based on the ECDH protocol and the first information; and verifies the legality of the second information.

[0028] (e) Construct a third piece of information as a response;

[0029] (f) The privacy contract execution module receives third-party information and verifies the legality of the report in the third-party information.

[0030] Furthermore, the certificate issuance process includes:

[0031] The privacy contract execution module submits a private key and certificate request to the guard service module.

[0032] The Guardian Service Module submits an application to the Certificate Coordination Service Module based on the unique identifier of the Privacy Contract Execution Module, and the application contains the digital signature of the Certificate Coordination Service Module.

[0033] After receiving the application, the Certificate Reconciliation Service module checks if there is a local cache. If there is, it returns the cache; otherwise, it generates a certificate public-private key pair (x,X) and a data encryption key (y,Y), and stores them in encryption. Then, it constructs a Certificate Signature (CSR) using x as the private key, X as the certificate public key, Y and other information as certificate extension fields, issues the CSR with the private key to obtain the certificate, and caches it.

[0034] The certificate coordination service module uses the session key to encrypt (x,X) and (y,Y) to obtain ciphertext, and sends the ciphertext and certificate back to the guard service module; upon receiving the ciphertext, the guard service module returns the public and private keys and certificate obtained from the application to the privacy contract execution module.

[0035] Thirdly, the present invention also provides a method for using a blockchain privacy contract key, applied to the aforementioned blockchain privacy contract key system, the method comprising:

[0036] (a) Overall execution process: The blockchain-side startup manager maintains the number of privacy contract execution modules to prevent excessive privacy contract execution modules from consuming node resources; all privacy transactions are cached in a queue, waiting to be executed or invoked; it checks whether the current contract has been loaded by an existing privacy contract execution module, and if it has been loaded, it enters the queue to wait; if it has not been loaded, a new privacy contract execution module is created to execute the contract task; when a privacy contract execution module is inactive and the transaction waiting queue is empty, the manager shuts down the privacy contract execution module service to save resources;

[0037] (b) Execution flow of privacy contracts within privacy contract execution modules: During the initialization phase, each privacy contract execution module possesses a unique pair of private keys and certificates, as well as a pair of identical working private keys and public keys. After the working public key is uploaded to the blockchain, it is used to encrypt the input of the privacy contract. When each privacy contract call arrives, the privacy contract execution module uses the working public key to decrypt the data and runs the contract using a virtual machine portion within the trusted execution environment to obtain the execution result. Finally, the result is signed using the certificate public and private keys of the privacy contract execution module and returned to the blockchain.

[0038] Compared with the prior art, the present invention has at least the following beneficial technical effects:

[0039] 1. This invention provides a blockchain privacy contract key system, key generation method, and usage method, which can ensure the verification of trusted execution environments, allow multiple trusted environments to share the same key to decrypt encrypted data, simplify key management, and improve system efficiency.

[0040] 2. This invention includes a key distribution and authorization mechanism to ensure that only authorized trusted environment nodes can obtain and use the keys; it can effectively control access permissions and prevent unauthorized nodes from decrypting and accessing data. While ensuring data privacy and security, this invention enables collaborative computation and analysis of multi-party data, improving data utilization efficiency and value.

[0041] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0042] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

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

[0044] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0045] Figure 1 This is a schematic diagram of the overall architecture of a blockchain privacy contract key system provided in an embodiment of the present invention.

[0046] Figure 2 This is a timing diagram of the initialization phase provided in an embodiment of the present invention.

[0047] Figure 3 This is a schematic diagram of the overall process of a privacy contract provided in an embodiment of the present invention.

[0048] Figure 4 This is a schematic diagram illustrating the execution flow of a privacy contract within a Worker, as provided in an embodiment of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0050] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0051] In the specific embodiments and accompanying drawings of the present invention:

[0052] TEE (Trusted Execution Environment): A TEE is an independent processing environment with computation and storage capabilities, providing security and integrity protection. Its basic idea is to allocate a separate, isolated memory block within the hardware for sensitive data. All computations on sensitive data are performed within this memory block, and no other part of the hardware can access the information in this isolated memory block except through authorized interfaces, thereby achieving privacy-preserving computations on sensitive data.

[0053] Smart Contracts: A smart contract is an automated contract that executes on a blockchain, containing predefined rules and conditions. Smart contracts exist in the form of code and are executed and verified through the consensus mechanism of the blockchain network, enabling various types of transactions and protocols. Their characteristics include automatic execution, decentralization, immutability, and transparency. They provide a more efficient, secure, and reliable way to conduct transactions and execute contracts.

[0054] Privacy Contracts: Privacy contracts are an extension of smart contracts designed to protect the privacy and sensitive data of participants. Unlike traditional smart contracts, privacy contracts provide mechanisms for encrypting and hiding transactions and contract content, ensuring that only authorized parties can decrypt and view the data within the contract. Privacy contracts are designed to address privacy issues on blockchains. In traditional public blockchains, all transaction and contract details are public, including transaction amounts, contract parameters, and states. This transparency can expose sensitive user information in certain scenarios; for example, the public disclosure of transaction amounts may reveal financial privacy. With privacy contracts, participants can conduct transactions and execute contracts without exposing their private information. Privacy contracts typically use cryptographic techniques to protect transactions and contract content. They can use cryptographic tools such as symmetric encryption, asymmetric encryption, and zero-knowledge proofs to encrypt, hide, and verify data. In this paper, the privacy contract functionality is provided by a privacy contract environment based on a trusted execution environment.

[0055] Certificate Coordination Service (Key-Server): A concept in the technical solution of this invention. A centralized coordination service (similar to the root certificate service in a CA service), deployed separately in a trusted execution environment, is responsible for issuing, managing, and storing keys and certificates related to the Guard and Workers, and can perform remote authentication with the Guard.

[0056] Guard Service: A concept in this invention's technical solution. Corresponding one-to-one with a blockchain node, it is responsible for communicating and negotiating with the Key-Server to obtain and cache the Worker's keys and certificates. The Guard can perform remote authentication with the Key-Server, ensuring execution security between them. One Guard can correspond to multiple workers on a single blockchain node.

[0057] Privacy Contract Execution Instance (Worker): A concept in this invention's technical solution. A Guard and a blockchain node can contain multiple Workers, executing multiple privacy contracts simultaneously. Workers are virtual machines on the blockchain, serving as persistent services and providing a secure and privacy-preserving computing environment. Workers obtain on-chain data via gRPC and communicate with the Key-Server through the Guard to retrieve relevant data, rather than communicating directly with the Key-Server. Furthermore, a single Worker can only run one type of user's privacy contract (i.e., an executable file of that privacy contract).

[0058] Enclave: In the field of computer security, it refers to a secure execution environment that provides protection for code and data, preventing access and modification by malware or other unauthorized entities. Enclaves can be implemented in hardware, such as Intel SGX (Software Guard Extensions), or in software, such as software-emulated secure execution environments. Key features include secure isolation, encryption protection, integrity protection, and secure communication.

[0059] MRENCLAVE: A 256-bit hash value used to protect and verify the identity of an Enclave. Each Enclave generates a unique MRENCLAVE value upon creation, and this value remains constant throughout the Enclave's lifetime. The MRENCLAVE value can be used to verify the identity and integrity of the Enclave.

[0060] Example 1:

[0061] Reference Figure 1As shown, this embodiment of the invention provides a blockchain privacy contract key system that, while ensuring verification of a trusted execution environment, enables the use of the same key within the cluster to decrypt the user's encrypted input. The system includes: a certificate coordination service module (Key-Server), a guard service module (Guard), and a privacy contract execution module (Worker).

[0062] The module functions of the above systems are explained in detail below:

[0063] The Key-Server is a centralized coordination service (similar to the root certificate service in a CA service). It is deployed separately in a trusted execution environment and is responsible for issuing, managing and storing keys and certificates related to the Guard and Worker. It can also perform remote authentication with the Guard.

[0064] A Guard corresponds one-to-one with a blockchain node and is responsible for communicating and negotiating with the Key-Server to obtain and cache the Worker's keys and certificates. The Guard can perform remote authentication with the Key-Server, ensuring execution security for both parties. One Guard can correspond to multiple workers on a single blockchain node.

[0065] A single Guard and blockchain node can contain multiple Workers. Workers are virtual machines on the blockchain, and they are resident services providing a secure and private computing environment. Workers obtain on-chain data via gRPC and communicate with the Key-Server through the Guard to retrieve relevant data, rather than communicating directly with the Key-Server. Furthermore, a single Worker can only run one type of user's privacy contract (i.e., an executable file of that privacy contract).

[0066] Example 2:

[0067] This invention also provides a blockchain privacy contract key generation method, applied to the system of Embodiment 1, to complete mutual authentication between various modules and generate a corresponding private key and certificate for each module, combined with... Figure 1 and Figure 2 As shown, this method mainly consists of three steps: remote authentication, local authentication, and issuance of working certificates. Specifically:

[0068] 1) Remote authentication between the Key-Server and the Guard: The core is that the Guard challenges the Key-Server to verify its correctness. This includes:

[0069] (a) After the Key-Server is initialized, the CA and Report are uploaded to the blockchain.

[0070] (b) Hash MRENCLAVE and put it on the chain so that KeyServer can only accept access from the specified machine.

[0071] (c) During Guard initialization, a CSR and a public-private key pair (pk|sk) are generated, abbreviated as G_pk and G_sk. (d) Guard requests access to KeyServer, first obtaining the KeyServer's CA and Report on the chain, then obtaining the Proof returned by KeyServer, and verifying the signature in the Proof using the public key in the CA, and comparing it with the Report. Next, the public key in the CA is obtained, and a random number and MRENCLAVE are encrypted to form S_A, which, along with Guard's public key (G_pk) and the CSR file, is transmitted to KeyServer. KeyServer decrypts S_A using its private key, obtains the hash data of MRENCLAVE from the chain, and compares it. A certificate named Guard_Cert is issued for the CSR, the random number is encrypted using G_pk, and Guard_Cert is signed using KeyServer's private key, and sent back to Guard. Guard uses KeyServer's public key to verify the signature, and decrypts the random number using G_sk, comparing it with the random number generated in the previous steps. If all the above verification steps pass, remote authentication is successful.

[0072] 2) Local authentication between Guard and Worker:

[0073] (a) The Worker requests the Guard for verification;

[0074] (b) The Guard responds with feedback message 1 (msg1). msg1 contains two pieces of data: a randomly generated public key g^a and key information about the Guard itself, used to construct a report (ReportW) that only the Guard can verify.

[0075] (c) The Worker constructs message 2 (msg2) based on msg1, requesting the Guard to distribute the key and certificate. msg2 contains the following data: UUID, version number, randomly generated public key g^b, and reportW. Its custom 64-byte data segment has the following value: the first 32 bytes equal to H(g^a|g^b|UUID|version), where version uses big-endian encoding, and the last 32 bytes are set to 0.

[0076] (d) After receiving msg2, Guard calculates the shared public key aek based on the ECDH protocol using a and g^b; it verifies the legitimacy of msg2, including the following: verifying the legitimacy of the MAC address in ReportW, which is the security foundation of the entire local proof. It parses H(g^a|g^b|UUID|version) from ReportW and verifies its legitimacy.

[0077] (e) Construct msg3 as the response. msg3 contains the following data: the Aek-encrypted signing private key sealed_signing_key, the Aek-encrypted data decryption private key sealed_dek, the Worker certificate cert, and the report ReportG, whose custom 64-byte data segment value is: the first 32 bytes equal to H(g^a|g^b|UUID|version|cert), and the last 32 bytes set to 0. The critical dependency information is constructed based on ReportW, allowing the Worker to verify it.

[0078] (f) The Worker receives msg3 and verifies the validity of ReportG, including the following points: ReportG's custom 64-byte data segment has the following values: the first 32 bytes equal to H(g^a|g^b|UUID|version|cert), and the last 32 bytes set to 0. Verify the validity of the MAC address in ReportG.

[0079] 3) Certificate Issuance Process: The Worker requests a digital certificate from the Key-Server through the Guard. First, the Worker submits a private key and certificate request to the Guard. Then, the Guard, based on the Worker's unique identifier, submits a request to the Key-Server, which includes the Guard's digital signature. Upon receiving the request, the Key-Server first checks if it has a local cache; if so, it returns it; otherwise, it generates a certificate public-private key pair (x,X) and a data encryption key (y,Y), and stores them encrypted. Then, it constructs a Certificate Signature (CSR) using x as the private key, X as the certificate public key, and Y and other information as certificate extension fields (these other information could be key purpose, extended key purpose, subject alternative name, and certificate policy, etc., selected according to the specific scenario and requirements), and issues the CSR with the private key to obtain the certificate certW, which is then cached. Finally, the Key-Server uses the session key sk to encrypt (x,X) and (y,Y) to obtain ciphertext C2, and sends C2 and certW back to the Guard. Upon receiving this, the Guard returns the obtained public-private key and certificate to the Worker.

[0080] Example 3:

[0081] This invention also provides a method for using blockchain privacy contract keys, applied to the system of Embodiment 1. This key usage method (i.e., the privacy contract execution process) includes:

[0082] (a) Overall execution process: The blockchain-side startup manager maintains the number of Worker services to prevent an excessive number of Workers from consuming node resources. For example... Figure 3 As shown, all privacy transactions are cached in a queue, waiting to be executed or invoked. The system checks if the current contract has already been loaded by an existing Worker; if so, it enters the queue to wait; otherwise, a new Worker is created to execute the contract task. When a Worker is inactive and the transaction waiting queue is empty, the manager shuts down the Worker service to conserve resources.

[0083] (b) Execution flow of the privacy contract within the Worker: During the initialization phase, each worker possesses a unique pair of private keys and certificates, as well as an identical pair of working private and public keys. The specific process is as follows: Figure 4 As shown, once the working public key is on-chain, it can be used to encrypt the input of the privacy contract. Upon each privacy contract call, the worker node uses the working public key to decrypt the data and partially runs the contract using a virtual machine within the trusted execution environment to obtain the result. Finally, the result is signed using the worker's certificate public and private keys and returned to the blockchain.

[0084] From the above description, those skilled in the art will understand that the blockchain privacy contract key system, key generation method, and usage method provided in this embodiment of the invention have the following characteristics:

[0085] This invention utilizes blockchain technology to manage and protect keys and encrypted data. As a distributed, immutable ledger, blockchain ensures the security and trustworthiness of keys and data. This invention allows multiple trusted environments to share the same key to decrypt encrypted data, thereby simplifying key management and improving system efficiency. This invention includes a key distribution and authorization mechanism that ensures only authorized trusted environment nodes can obtain and use the key. This effectively controls access permissions and prevents unauthorized nodes from decrypting and accessing data.

[0086] In summary, this invention utilizes blockchain technology to achieve secure management of keys and data, and allows multiple trusted environments to share the same key to decrypt encrypted data. This helps improve the security, reliability, and efficiency of trusted environments.

[0087] The embodiments of the present invention have been described in detail above, and the principles and implementation methods of the present invention have been explained. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention.

[0088] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain privacy contract key system, characterized in that, The system includes: a certificate coordination service module, a guard service module, and a privacy contract enforcement module, among which: The certificate coordination service module is a centralized coordination service module, deployed separately in a trusted execution environment. It is used to issue, manage and store the keys and certificates related to the guard service module and the privacy contract execution module, and to perform remote authentication with the guard service module. A blockchain node contains multiple privacy contract execution modules; a guard service module corresponds to multiple privacy contract execution modules on a blockchain node; the same privacy contract execution module runs only one type of user's privacy contract. The guard service module corresponds one-to-one with a blockchain node and is used to communicate and negotiate with the certificate coordination service module to obtain the key and certificate of the privacy contract execution module and cache them; the guard service module and the certificate coordination service module perform remote authentication to ensure the execution security of each other; The privacy contract execution module is a virtual machine part on the blockchain, a resident service used to provide a secure and private computing environment; the privacy contract execution module obtains on-chain data through gRPC, and communicates with the certificate coordination service module through the guard service module to obtain relevant data, but does not communicate directly with the certificate coordination service module. Remote authentication between the Certificate Reconciliation Service module and the Guardian Service module includes: (a) After the certificate coordination service module is initialized, the CA and Report will be uploaded to the blockchain; (b) Hash MRENCLAVE and put it on the blockchain so that the certificate coordination service module can only accept access from the specified machine; (c) When the Guard Service module is initialized, a CSR and a pair of public and private keys are generated; (d) The Guardian Service Module requests access to the Certificate Reconciliation Service Module. First, it obtains the CA and Report from the on-chain Certificate Reconciliation Service Module. Then, it obtains the Proof returned by the Certificate Reconciliation Service Module and verifies the signature in the Proof using the public key in the CA, comparing it with the Report. Next, it obtains the public key in the CA and encrypts the random number and MRENCLAVE into an S_A, which, along with the Guardian Service Module's public key and CSR file, is transmitted to the Certificate Reconciliation Service Module. The Certificate Reconciliation Service Module decrypts S_A using its private key and retrieves the hash data of MRENCLAVE from the on-chain for comparison. It issues a certificate for the CSR, encrypts the random number using the Guardian Service Module's public key, signs the issued certificate using the Certificate Reconciliation Service Module's private key, and sends it back to the Guardian Service Module. The Guardian Service Module verifies the signature using the Certificate Reconciliation Service Module's public key and decrypts the random number using its private key, comparing it with the previously generated random number. If all verification steps pass, the remote authentication is successful. The certificate reconciliation service module's certificate issuance process includes: The privacy contract execution module submits a private key and certificate request to the guard service module. The Guardian Service Module submits an application to the Certificate Coordination Service Module based on the unique identifier of the Privacy Contract Execution Module, and the application contains the digital signature of the Certificate Coordination Service Module. After receiving the application, the Certificate Reconciliation Service module checks if there is a local cache. If there is, it returns the cache; otherwise, it generates a certificate public / private key pair and a data encryption key, and stores them in encryption. Then, it constructs a Certificate Signature (CSR) using the certificate private key, certificate public key, and data encryption key as certificate extension fields, issues the CSR with the private key to obtain the certificate, and caches it. The certificate coordination service module uses the session key to encrypt the certificate public and private key pair and the data encryption key to obtain ciphertext, and then sends the ciphertext and certificate back to the guard service module; upon receiving it, the guard service module returns the requested public and private key and certificate to the privacy contract execution module.

2. A method for generating blockchain privacy contract keys, characterized in that, Applied to a blockchain privacy contract key system as described in claim 1, the method enables mutual authentication between modules and generates a corresponding private key and certificate for each module. The method includes: 1) Remote authentication between the certificate coordination service module and the guard service module; 2) Local authentication between the Guardian Service Module and the Privacy Contract Execution Module; 3) Certificate issuance process; The remote authentication between the certificate coordination service module and the guard service module includes: (a) After the certificate coordination service module is initialized, the CA and Report will be uploaded to the blockchain; (b) Hash MRENCLAVE and put it on the blockchain so that the certificate coordination service module can only accept access from the specified machine; (c) When the Guard Service module is initialized, a CSR and a pair of public and private keys are generated; (d) The Guardian Service Module requests access to the Certificate Reconciliation Service Module. First, it obtains the CA and Report from the on-chain Certificate Reconciliation Service Module. Then, it obtains the Proof returned by the Certificate Reconciliation Service Module and verifies the signature in the Proof using the public key in the CA, comparing it with the Report. Next, it obtains the public key in the CA and encrypts the random number and MRENCLAVE into an S_A, which, along with the Guardian Service Module's public key and CSR file, is transmitted to the Certificate Reconciliation Service Module. The Certificate Reconciliation Service Module decrypts S_A using its private key and retrieves the hash data of MRENCLAVE from the on-chain for comparison. It issues a certificate for the CSR, encrypts the random number using the Guardian Service Module's public key, signs the issued certificate using the Certificate Reconciliation Service Module's private key, and sends it back to the Guardian Service Module. The Guardian Service Module verifies the signature using the Certificate Reconciliation Service Module's public key and decrypts the random number using its private key, comparing it with the previously generated random number. If all verification steps pass, the remote authentication is successful. The local authentication between the guard service module and the privacy contract execution module includes: (a) The privacy contract execution module requests verification from the guard service module; (b) The guard service module provides the first information as a response; (c) The privacy contract execution module constructs the second information based on the first information and requests the guard service module to distribute the key and certificate; (d) After receiving the second information, the guard service module calculates the shared public key based on the ECDH protocol and the first information; and verifies the legality of the second information. (e) Construct a third piece of information as a response; (f) The privacy contract execution module receives third-party information and verifies the legality of the report in the third-party information; The certificate issuance process includes: The privacy contract execution module submits a private key and certificate request to the guard service module. The Guardian Service Module submits an application to the Certificate Coordination Service Module based on the unique identifier of the Privacy Contract Execution Module, and the application contains the digital signature of the Certificate Coordination Service Module. After receiving the application, the Certificate Reconciliation Service module checks if there is a local cache. If there is, it returns the cache; otherwise, it generates a certificate public / private key pair and a data encryption key, and stores them in encryption. Then, it constructs a Certificate Signature (CSR) using the certificate private key, certificate public key, and data encryption key as certificate extension fields, issues the CSR with the private key to obtain the certificate, and caches it. The certificate coordination service module uses the session key to encrypt the certificate public and private key pair and the data encryption key to obtain ciphertext, and then sends the ciphertext and certificate back to the guard service module; upon receiving it, the guard service module returns the requested public and private key and certificate to the privacy contract execution module.

3. A method for using blockchain privacy contract keys, characterized in that, Applied to a blockchain privacy contract key system as described in claim 1, the method includes: (a) Overall execution process: The blockchain-side startup manager maintains the number of privacy contract execution modules to prevent excessive privacy contract execution modules from consuming node resources; all privacy transactions are cached in a queue, waiting to be executed or invoked; it checks whether the current contract has been loaded by an existing privacy contract execution module, and if it has been loaded, it enters the queue to wait; if it has not been loaded, a new privacy contract execution module is created to execute the contract task; when a privacy contract execution module is inactive and the transaction waiting queue is empty, the manager shuts down the privacy contract execution module service to save resources; (b) Execution flow of privacy contracts within privacy contract execution modules: During the initialization phase, each privacy contract execution module possesses a unique pair of private keys and certificates, as well as a pair of identical working private keys and public keys. After the working public key is uploaded to the blockchain, it is used to encrypt the input of the privacy contract. When each privacy contract call arrives, the privacy contract execution module uses the working public key to decrypt the data and runs the contract using a virtual machine portion within the trusted execution environment to obtain the execution result. Finally, the result is signed using the certificate public and private keys of the privacy contract execution module and returned to the blockchain.

Images