CN111988141B

CN111988141B - Method and device for sharing cluster key

Info

Publication number: CN111988141B
Application number: CN202010859303.4A
Authority: CN
Inventors: 吴因佥; 邱鸿霖; 吴行行
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-03-18
Filing date: 2020-03-18
Publication date: 2022-08-02
Anticipated expiration: 2040-03-18
Also published as: CN111988141A; WO2021184968A1; CN111092727B; CN111092727A

Abstract

This specification provides a method and a device for sharing a cluster key, in which the method includes: any node in the private computing cluster under the chain acquires a first remote attestation report which is sent by other nodes and corresponds to a first trusted execution environment under the chain; acquiring a cluster identity key generated in a trusted execution environment under a second chain of any node, wherein the cluster identity key is used for encrypting and decrypting interactive data and/or signing and checking in the process of interacting block chain links with each node to deploy or invoke a contract under the chain; and in the case that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, sending the cluster identity key and a second remote attestation report to other nodes, wherein in the case that the second remote attestation report indicates that the trusted execution environment under the second chain is trusted, the cluster identity key is approved by other nodes. The process of sharing the key can ensure data security, so that each subsequent node can perform privacy protection through the cluster identity key.

Description

Method and device for sharing cluster key

Technical Field

One or more embodiments of the present disclosure relate to the field of verifiable computing technologies, and in particular, to a method and an apparatus for sharing a cluster key.

Background

In the related art, one way to meet privacy requirements in various scenarios is to implement privacy protection through encryption technologies such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), which also brings serious performance loss. A Trusted Execution Environment (TEE) is another solution. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In terms of efficiency, due to the black-box nature of the TEE, plaintext data is operated on in the TEE, rather than complex cryptographic operations in homomorphic encryption, and computational process efficiency is not lost.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for sharing a cluster key, which can securely implement operations of sharing the cluster key in a chained environment.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided a method of sharing a cluster key, including:

Any node in a down-link privacy computing cluster acquires a first remote attestation report sent by other nodes in the down-link privacy computing cluster, wherein the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other nodes aiming at a created first down-link trusted execution environment;

the method comprises the steps that any node obtains a cluster identity key corresponding to the private computing cluster under the chain, the cluster identity key is generated in a trusted execution environment under a second chain created by the any node, and in the process that block chain nodes interact with each node in the private computing cluster under the chain to deploy or call contract under the chain, the cluster identity key is used for encrypting and decrypting interaction data and/or signing and checking a signature;

and the any node sends the cluster identity key and a second remote attestation report to the other nodes under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, the cluster identity key is maintained in the trusted execution environment under the first chain under the condition that the trusted execution environment under the second chain is determined to be trusted according to the second remote attestation report, and the second remote attestation report is generated by an authentication server after second self-referral information generated by the any node for the trusted execution environment under the second chain is verified.

According to a second aspect of one or more embodiments of the present specification, there is provided a method of sharing a cluster key, including:

any node in the down-link privacy computing cluster provides a first remote attestation report to other nodes in the down-link privacy computing cluster, wherein the first remote attestation report is generated by an authentication server after verifying first self-recommendation information generated by the any node aiming at the created first down-link trusted execution environment;

the any node receives a cluster identity key and a second remote attestation report which are sent by the other nodes and correspond to the private computing cluster under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, wherein the cluster identity key is generated in a trusted execution environment under the second chain created by the other nodes, the cluster identity key is used for encrypting, decrypting and/or signing and checking interaction data in the process that block chain links interact with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain, and the second remote attestation report is generated after an authentication server verifies second self-referral information generated by the other nodes aiming at the trusted execution environment under the second chain;

And the any node maintains the cluster identity key in the first-chain trusted execution environment under the condition that the second-chain trusted execution environment is determined to be trusted according to the second remote attestation report.

According to a third aspect of one or more embodiments of the present specification, there is provided a method of sharing a cluster key, including:

any node in a privacy computing cluster acquires a first remote attestation report sent by other nodes in the privacy computing cluster, wherein the first remote attestation report is generated after an authentication server verifies first self-referral information generated by the other nodes aiming at a created first trusted execution environment;

the method comprises the steps that any node obtains a cluster identity key corresponding to the privacy computing cluster, the cluster identity key is generated in a second trusted execution environment created by the any node, and in the process that a client interacts with each node in the privacy computing cluster to deploy or call an intelligent contract, the cluster identity key is used for encrypting and decrypting interaction data and/or signing and checking a signature;

and the any node sends the cluster identity key and a second remote attestation report to the other nodes under the condition that the first trusted execution environment is determined to be trusted according to the first remote attestation report, the cluster identity key is approved by the other nodes under the condition that the second remote attestation report indicates that the second trusted execution environment is trusted, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node aiming at the second trusted execution environment.

According to a fourth aspect of one or more embodiments of the present specification, there is provided a method of sharing a cluster key, including:

any node in a private computing cluster provides a first remote attestation report to other nodes in the private computing cluster, wherein the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the any node aiming at a created first trusted execution environment;

the any node receives a cluster identity key and a second remote attestation report which are sent by the other nodes and correspond to the private computing cluster under the condition that the first trusted execution environment is determined to be trusted according to the first remote attestation report, wherein the cluster identity key is generated in a second trusted execution environment created by the other nodes, the cluster identity key is used for encrypting, decrypting and/or signing and checking interaction data in the process that a client interacts with each node in the private computing cluster to deploy or call an intelligent contract, and the second remote attestation report is generated after an authentication server verifies second self-referral information generated by the other nodes aiming at the second trusted execution environment;

The any node approves the cluster identity key if it is determined that the second remote attestation report indicates that the second trusted execution environment is trusted.

According to a fifth aspect of one or more embodiments of the present specification, there is provided an apparatus for sharing a cluster key, including:

the report obtaining unit is used for enabling any node in the private computing cluster to obtain a first remote attestation report sent by other nodes in the private computing cluster, and the first remote attestation report is generated after an authentication server verifies first self-recommendation information generated by the other nodes aiming at the created first linked trusted execution environment;

a key obtaining unit, configured to enable the any node to obtain a cluster identity key corresponding to the private computing cluster under the chain, where the cluster identity key is generated in a second under-chain trusted execution environment created by the any node, and the cluster identity key is used for encrypting and decrypting interaction data and/or signing and verifying a signature during a process of interacting between a block link node and each node in the private computing cluster under the chain to deploy or invoke a contract under the chain;

a sending unit, configured to, when it is determined that the trusted execution environment under the first chain is trusted according to the first remote attestation report, send the cluster identity key and a second remote attestation report to the other node, where the cluster identity key is maintained in the trusted execution environment under the first chain when it is determined that the trusted execution environment under the second chain is trusted according to the second remote attestation report, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by any node for the trusted execution environment under the second chain.

According to a sixth aspect of one or more embodiments of the present specification, there is provided an apparatus for sharing a cluster key, including:

the report providing unit enables any node in the private computing cluster to provide a first remote attestation report to other nodes in the private computing cluster, wherein the first remote attestation report is generated by verifying first self-referral information generated by the any node aiming at the created first chain lower trusted execution environment by an authentication server;

a receiving unit, configured to enable the any node to receive a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, where the cluster identity key is generated in a trusted execution environment under the second chain created by the other node, the cluster identity key is used for encrypting, decrypting and/or signing and verifying interaction data in a process that a block link node interacts with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the other node for the trusted execution environment under the second chain;

A processing unit to cause the any node to maintain the cluster identity key within the first-chain trusted execution environment if the second-chain trusted execution environment is determined to be trusted based on the second remote attestation report.

According to a seventh aspect of one or more embodiments of the present specification, there is provided an apparatus for sharing a cluster key, including:

a key obtaining unit, configured to enable the any node to obtain a cluster identity key corresponding to the private computing cluster under the chain, where the cluster identity key is generated in a second chain trusted execution environment created by the any node, and the cluster identity key is used to encrypt and decrypt interaction data and/or sign and verify a contract during a process in which a client interacts with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain;

According to an eighth aspect of one or more embodiments of the present specification, there is provided an apparatus for sharing a cluster key, including:

a receiving unit, configured to enable the any node to receive a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, where the cluster identity key is generated in a trusted execution environment under the second chain created by the other node, and in a process that a client interacts with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain, the cluster identity key is used for encrypting and decrypting interaction data and/or signing and verifying a signature, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the other node for the trusted execution environment under the second chain;

According to a ninth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method according to the first, second, third or fourth aspect by executing the executable instructions.

According to a tenth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, perform the steps of the first, second, third or fourth aspects.

In summary, the present specification implements the chain-down trusted execution environment on the chain-down private computing node, so that the chain-down private computing node can provide a safe and reliable operation environment, and the reliability of the chain-down trusted execution environment can be verified through remote certification, thereby generating the cluster key safely and reliably, and implementing sharing among nodes in the cluster.

Drawings

Fig. 1 is a flowchart of a method for sharing a cluster key according to an exemplary embodiment.

FIG. 2 is a schematic diagram of cluster identity formation between private compute nodes in a chain according to an example embodiment.

FIG. 3 is a schematic diagram of a scenario for implementing remote attestation, according to an example embodiment.

FIG. 4 is a schematic diagram of another scenario for implementing remote attestation, provided by an example embodiment.

FIG. 5 is a scenario diagram of a deployment of a contract under a chain provided by an exemplary embodiment.

FIG. 6 is a scenario diagram of another deployment subcohain contract provided by an exemplary embodiment.

FIG. 7 is a schematic diagram of a verification of a contract under a chain provided by an exemplary embodiment.

FIG. 8 is a schematic illustration of another verification of a contract under a chain provided by an exemplary embodiment.

FIG. 9 is a scenario diagram of a call under-chain contract provided by an exemplary embodiment.

Fig. 10-12 are flow diagrams of another method for sharing a cluster key provided by an example embodiment.

Fig. 13 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 14 is a block diagram of an apparatus for sharing a cluster key according to an exemplary embodiment.

Fig. 15-17 are block diagrams of another apparatus for sharing a cluster key according to an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments. It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participants joining the public chain can read the data record on the chain, participate in transaction, compete for the accounting right of the new block, and the like, and each participant (i.e. node) can freely join and leave the network. The private chain is opposite, the data writing authority of the network is controlled by a certain organization or organization, and the data reading authority is regulated by the organization; briefly, the private chain can be a weakly centralized system with strict restrictions and few participating nodes, so that the private chain is more suitable for use within a particular organization. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in the federation chain usually has a corresponding entity organization or organization, and participants jointly maintain the operation of the block chain by authorizing to join the network and forming a profit-related federation.

In the blockchain network, corresponding blockchain transactions (transaction for short) are submitted to blockchain link points, and the blockchain transactions are executed by the blockchain link points, so that the corresponding operation purpose is realized. For any of the above types of blockchains, the blockchain link points may be implemented by creating a TEE and implementing the TEE as a secure execution environment for blockchain transactions. The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, such as TPM (Trusted Platform Module) in Software, and Intel SGX (Software Guard Extensions) in hardware, ARM Trustzone, and AMD PSP (Platform Security Processor).

The Intel SGX (hereinafter referred to as SGX) technology is taken as an example. The blockchain node may create enclave (enclosure or enclave) based on SGX technology as a TEE for performing blockchain transactions. The block link point may allocate a partial area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) in the memory by using a newly added processor instruction in the CPU, so as to reside the above-mentioned enclosure. The memory area corresponding to the EPC is encrypted by a memory Encryption engine mee (memory Encryption engine) inside the CPU, the contents (code and data in the enclave) in the memory area can be decrypted only in the CPU core, and a key for Encryption and decryption is generated and stored in the CPU only when the EPC is started. It can be seen that the security boundary of enclave only includes itself and the CPU, and no matter privileged or non-privileged software can not access enclave, even an operating system administrator and a VMM (virtual machine monitor, or called Hypervisor) can not affect code and data in enclave, so that the enclave has extremely high security.

Based on the decentralized architecture of the blockchain network, each blockchain transaction on the blockchain needs to be executed on all blockchain nodes in the blockchain network, so as to ensure that the blockchain account book data maintained by each blockchain node are consistent. If the transaction logic is simple, such as bitcoin for example, the blockchain transaction is only used for implementing the transfer operation, and this will not cause excessive resource consumption even if the blockchain transaction needs to be executed at all blockchain nodes. However, if the blockchain provides the functionality of an intelligent contract and the blockchain transaction invokes the intelligent contract, the situation may be quite different. The intelligent contracts on the blockchain are contracts which can be triggered to be executed by transactions on a blockchain system, and the intelligent contracts can be defined by the form of codes.

Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contract is divided into two phases of deployment and invocation.

In the deployment stage, a user sends a transaction containing information for creating the intelligent contract to the Ethernet shop network, the data field of the transaction contains the code (such as byte code) of the intelligent contract, and the to field of the transaction is empty. Each node in the ethernet network performs this transaction via the EVM and generates a corresponding contract instance. After the agreement is achieved between the nodes through the consensus mechanism, the intelligent contract corresponding to the transaction is successfully created, a contract account corresponding to the intelligent contract appears on the block chain, the contract account has a specific contract address, and the contract code (namely the code of the intelligent contract) or the hash value of the contract code is stored in the contract account, and the contract code is used for controlling the action of the corresponding intelligent contract.

In the calling phase, a user (which can be the same as or different from the user who deploys the intelligent contract) sends a transaction for calling the intelligent contract to the Ethernet network, wherein the from field of the transaction is the address of the external account corresponding to the user, the to field of the transaction is the contract address of the intelligent contract required to be called, and the data field contains a method and parameters for calling the intelligent contract. After the agreement is achieved among the nodes through a consensus mechanism, the intelligent contract called by the transaction statement is independently executed on each node of the Ethernet network in a specified mode, and all execution records and data are stored in the block chain, so that the transaction certificate which cannot be tampered and cannot be lost is stored in the block chain after the transaction is completed.

As previously mentioned, the EVM is a well-defined virtual machine; similarly, other blockchains may employ other types of virtual machines, such as WASM (WebAssembly) virtual machines, and the like. In summary, when the intelligent contract invoked by the transaction is used for implementing relatively complex logic, the process of executing the code of the intelligent contract by the node through the virtual machine consumes relatively more computing resources, and since all nodes in the block chain network need to execute the code of the intelligent contract, the consumption of the computing resources is multiplied as the number of the nodes is increased. Therefore, although the combination of TEE technology can relatively reduce the resource consumption of single blockchain nodes and accelerate the transaction execution efficiency, the whole blockchain network still causes great resource consumption and waste.

For this reason, the present specification proposes to deploy the private Computation nodes under the chain (i.e., the private Computation nodes under the chain), to transfer the Computation operations that would otherwise need to be performed on all block chain nodes to the private Computation nodes under the chain for execution, and the block chain link nodes only need to obtain the Computation results from the private Computation nodes under the chain and update the block chain ledger data based on the Computation results, and to prove that the Computation results are actually performed as expected in the trusted execution environment based on a Verifiable computing (Verifiable computing) technology, so as to greatly reduce the resource consumption on the chain while ensuring the reliability.

As described above, by deploying an intelligent contract at a block link point, the block link node can execute the code of the intelligent contract to achieve the corresponding computing requirement; similarly, code for performing computing tasks may be deployed at the down-chain private computing node such that the down-chain private computing node may execute the code to fulfill the respective computing requirements. For ease of understanding, contracts deployed at blockchain nodes are referred to herein as on-chain contracts, contracts deployed at private compute nodes under-chain are referred to herein as off-chain contracts; of course, whether it is a chain contract or a chain contract, it is essentially a piece of code that can be executed within a virtual machine.

Similar to the above-described block chain nodes, a down-chain TEE (i.e., a down-chain trusted execution environment) may be created on the down-chain private compute node, which is based on a CPU hardware-implemented fully-isolated trusted execution environment from the outside. The chain privacy computing node can realize deployment operation of chain contracts and call execution operation after deployment through the chain TEE by creating the chain TEE, and ensure data security and privacy protection in the operation process. For example, a down-link contract may be deployed on a down-link private compute node and a WASM virtual machine may be deployed within a down-link TEE created by the down-link private compute node. Then, when a user initiates a computation task based on the WASM program to the down-link privacy computing node, the down-link privacy computing node may read the down-link contract into the down-link TEE and compile the down-link contract into the WASM bytecode, and execute the compiled WASM bytecode in the WASM virtual machine by using the WASM virtual machine as an execution engine.

The method comprises the steps that a private computing node under a single-node form can be configured to execute computing tasks; or, high-concurrency and high-availability private computing services can be provided for users in a form of a linked private computing cluster, so that the problems of load balancing, fault transfer, dynamic expansion and capacity reduction of nodes and the like are solved. The down-link privacy computing cluster may include a control node and a plurality of down-link privacy computing nodes, where each node is configured to deploy the same down-link contract (at least one) to execute a computing task, and the control node is configured to uniformly manage all the down-link privacy computing nodes in the cluster. The following describes a process in which the privacy computation node under the control node management link requests to join the cluster.

When any one of the down-link privacy computing nodes requests to join the down-link privacy computing cluster, the control node may initiate a challenge to the node and receive a remote attestation report returned by the node. Remote attestation reports result from remote attestation processes directed to the down-link TEE on the down-link privacy computing node. The remote attestation report is generated by the authentication server after verifying self-referral information generated by the down-link privacy computing node, wherein the self-referral information is related to the down-link TEE created on the down-link privacy computing node. The chain lower privacy computing node generates a remote attestation report by generating self-referral information related to chain lower TEE and generating the remote attestation report after the self-referral information is verified by the authentication server, so that the remote attestation report can be used for indicating that the chain lower TEE on the chain lower privacy computing node can be trusted. In other words, the remote attestation report is generated by the authentication server after verifying the self-referral information generated by the down-link privacy computing node for its own down-link TEE.

For example, taking the Intel SGX technology as an example, the under-chain TEE is an enclave created on the under-chain private computing node for implementing the under-chain private computing, and the remote attestation process also involves another special enclave on the under-chain private computing node, namely, quoting enclave (QE for short), which is an architectural enclave (architectural enclave) provided and signed by Intel. The enclave first needs to generate a REPORT structure for local authentication, and the QE verifies whether the enclave is on the same platform as itself based on the REPORT structure, and then the QE encapsulates the REPORT structure into a structure body quite (i.e. self-recommendation information), and uses an epid (enhanced private identification) key for signature. The EPID key not only represents a platform of the privacy computation node, but also represents the credibility of the bottom hardware of the privacy computation node, and can bind information such as the version of processor firmware and the like, and only QE can access the EPID key for signing the structure QUOTE. In the SGX technology, the authentication server may be an IAS (intel authentication service) server provided by intel corporation, and the chain lower privacy computing node sends the signed structure body quite to the IAS server, so that the IAS server can verify the signature and return a corresponding remote Attestation report to the chain lower privacy computing node.

After obtaining the remote attestation report of the private computation node under the chain, the control node may verify, according to the remote attestation report, whether the corresponding private computation node under the chain is trusted, specifically, whether a TEE under the chain deployed on the private computation node under the chain is trusted, and use the private computation node under the chain as a member node of the private computation cluster under the chain through a request of the private computation node under the chain to join the private computation cluster under the condition that the TEE under the chain is determined to be trusted.

In particular, the down-chain privacy computing node, upon creating the down-chain TEE, generates self-referral information for implementing remote attestation, which may be used to anchor and solidify information of the down-chain TEE, such that a resulting remote attestation report including the self-referral information may be used to characterize a state of the down-chain TEE and to verify whether the down-chain TEE is authentic. For example, the self-referral information may include a first hash value to be verified, where the first hash value to be verified is a hash value of preset information in the chain TEE, and for example, the preset information may include all codes deployed in the chain TEE, a public key of a developer of the chain TEE, and the like. Taking the Intel SGX technique as an example, the hash value generated corresponding to all codes deployed in the TEE under the chain is MREnclave, and the hash value generated corresponding to the public key of the developer of the TEE under the chain is MRSigner, that is, the first hash value to be verified may include MREnclave and MRSigner.

The Intel SGX technique is still used as an example. As described above, after the chain down privacy computing node sends the signed structure body quite to the IAS server, the IAS server verifies the signature according to the maintained public key set, and returns a remote attestation report (i.e., an AVR report) to the chain down privacy computing node, where the remote attestation report includes: the structure QUOTE and the signature verification result, and the IAS server signs the remote attestation report with a private key held by the IAS server.

Accordingly, after obtaining the remote attestation report, the control node may first perform signature verification on the remote attestation report according to the public key of the IAS server, and if the verification passes, it indicates that the remote attestation report is indeed generated by the IAS server and has not been tampered or data is lost in the data transmission process. The control node may obtain the public key of the IAS server in any way, such as when a remote attestation report is provided to the control node, it may also associate a certificate chain providing the IAS, so that the control node may extract the public key of the IAS server from the certificate chain. The control node may then extract the structure body quite and signature verification results from the remote attestation report. The control node can check the signature verification result at first, if the signature verification result is verified, the CPU of the privacy computation node under the chain holds the private key provided by the Intel, so that the TEE under the chain is established on a reliable hardware platform, and other verification operations can be continuously executed; if the signature verification result is that the signature is not verified, the control node can judge that the down-link privacy computing platform is unreliable without continuing other verification operations. Then, the control node may extract the hash values MREnclave and MRSigner from within the structure quate, that is, MREnclave to be checked and MRSigner to be checked; meanwhile, the control node obtains in advance a first standard hash value of the above-mentioned preset information of the sub-chain TEE, such as reliable values of MREnclave and MRSigner (hereinafter referred to as reliable MREnclave and reliable MRSigner), compares the MREnclave to be checked with the reliable MREnclave, and compares the MRSigner to be checked with the reliable MRSigner. Then, the control node may use "MREnclave to be checked is consistent with the trusted MREnclave, and MRSigner to be checked is consistent with the trusted MRSigner" as a precondition that the TEE is trusted under the acknowledgement chain; in other words, if the MREnclave to be checked is not consistent with the trusted MREnclave, or the MRSigner to be checked is not consistent with the trusted MRSigner, the control node determines that the chain-down TEE of the chain-down privacy computing node is not trusted, and if all the preconditions set by the control node are satisfied, the chain-down TEE of the chain-down privacy computing node can be confirmed to be trusted. In addition, the operation of verifying the signature verification result by the control node and the operation of verifying the MREnable to be verified and the MRSigner to be verified do not have a necessary sequence, and the two operations can be completely independent.

Besides MREnclave and MRSigner, the control node may also verify the trustworthiness of the privacy computation node under the chain by other preconditions. For example, after creating the down-link TEE, the down-link privacy computing node may generate a key pair representing its own identity information within the down-link TEE, and create its own node identity information in the down-link TEE, where the node identity information is related to the above-mentioned key pair corresponding to the identity information, for example, the node identity information may include a public key of the key pair (i.e., a node identity public key). Wherein there may be one or more groups of key pairs representing identity information, for example, one group of key pairs is a key pair for signing and verifying (i.e. a signing key pair), and one group of key pairs is a key pair for encrypting and decrypting (i.e. an encrypting key pair), the node identity information may include a public signature key in the signing key pair and an encrypting public key in the encrypting key pair. In a set of key pairs, there may exist multiple public keys corresponding to different encryption algorithms, and these public keys are all included in the node identity information. In addition, the node identity information may also include other information (i.e., other identity information) related to the private computing node under the link, such as a software version, a domain name of the node, a partition name of the node, and the like, which is not limited in this specification. Then, after the node identity information is generated by the down-link privacy computing node in the down-link TEE (for example, generated during initialization of the down-link TEE), the generated node identity information may be subjected to hash computation to obtain a second standard hash value. And the down-link privacy computing node may add this second standard hash value to the structure body quantum when generating the structure body quantum.

Accordingly, the control node may perform signature verification from the remote attestation report after receiving the remote attestation report. And under the condition that the signature verification passes, the control node can extract a signature verification result and a second standard hash value contained in the remote certification report, verify the signature verification result, and verify whether the node identity information of the privacy computing node under the link is correct by using the second standard hash value, and the two verification steps do not have necessary sequence and can be completely independent. And assuming that the control node firstly verifies the signature verification result and continuously verifies the node identity information of the down-link privacy computing node by using the second standard hash value under the condition that the signature verification result is verified. In order to verify the node identity information of the privacy-preserving computation node, the control node needs to acquire the node identity information of the privacy-preserving computation node, for example, the remote attestation report may be provided to the control node and the node identity information may be provided in association, although the control node may also obtain the node identity information in other manners or at other times. Then, the control node may perform hash calculation on the obtained node identity information to obtain a second hash value to be verified, compare the calculated second hash value to be verified with the second standard hash value, and use the comparison result as a precondition for confirming that the privacy computation node under the chain is authentic. If the second hash value to be verified passes verification, the obtained node identity information can be proved to be the node identity information generated by the private computation node under the chain in the TEE of the node under the chain. Then, the private key in the key pair representing the identity information is owned only by the down-link privacy computing node, and the down-link privacy computing node can complete operations such as signature and encrypted communication.

Two judgment conditions adopted when the node is verified for the privacy computation under the link are listed, namely verification for the first hash value to be tested and verification for the node identity information. Other determination conditions may also be used, and are not listed here. When the trust verification is performed on the private computing node under the link, one or more judgment conditions can be selected. For example, the first hash value to be verified and the node identity information may be verified at the same time; alternatively, in some cases, only the node identity information may be verified, while the first hash value to be verified may be unverified or partially verified. For example, the control node may set a trust level, and determine whether to verify or partially verify the first hash value to be verified according to the trust level, for example, when the trust level is 0, the first hash value to be verified is not required to be verified, when the trust level is 1, the MRSigner in the first hash value to be verified is verified, when the trust level is 2, the MREnclave in the first hash value to be verified is verified, and the like.

In the above embodiment, the node identity information includes identity-related information of the private computation node, such as a node identity public key representing the node identity. The node identity information may further include information related to the chain TEE, and then the chain privacy computing node performs hash computation on the generated node identity information to obtain a hash value after generating the node identity information in the chain TEE of the chain privacy computing node itself, and when the hash value is added to the structure body queue, the hash value is equivalent to the effect of simultaneously realizing the first hash value to be tested and the second standard hash value. For example, the node identity information may include, in addition to information such as a signature public key and an encryption public key, values of MREnclave and MRSigner, so that a hash value obtained by hash calculation of the node identity information is related to the identity of the node privacy computation node under the link and the TEE under the link. Accordingly, the control node may perform signature verification from the remote attestation report after receiving the remote attestation report. And under the condition that the signature verification passes, the control node can extract a signature verification result and the hash value contained in the remote certification report, verify the signature verification result, and verify whether the node identity information of the privacy computing node under the link is correct by using the hash value, and the two verification steps do not have a necessary sequence and can be completely independent. And assuming that the control node firstly verifies the signature verification result and continuously verifies the node identity information of the privacy computation node under the chain by using the hash value under the condition that the signature verification result is verified. In order to verify the node identity information of the down-link privacy computing node, the control node needs to acquire the node identity information of the down-link privacy computing node, which is not described herein again. Then, the control node may perform hash calculation on the obtained node identity information to obtain a hash value to be verified, compare the calculated hash value to be verified with the hash value included in the remote attestation report, and use the comparison result as a precondition for confirming that the privacy computing node under the link is authentic. Therefore, the verification of the two aspects in the foregoing can be realized only by one comparison in the embodiment, which is helpful for improving the verification efficiency.

It should be noted that the verification process of the remote attestation report by the control node may further include other operations, such as determining whether the chain TEE operates in the test mode (risk of data leakage exists in the test mode) according to the content of the remote attestation report, and so on, which is not described herein again.

Based on the above method for verifying the private computation nodes under the chain, the control node can add the verified nodes into the private computation cluster under the chain, so as to establish a private computation cluster under the chain containing a plurality of private computation nodes under the chain. After the establishment of the private computing cluster, uniform identity information, for example, called a cluster identity key, needs to be generated for the private computing nodes. The cluster identity key may include a cluster encryption key pair and a cluster signature key pair, and each of the chain privacy computing nodes needs to maintain the cluster encryption private key and the cluster signature private key in their respective chain TEE. By generating uniform identity information for each node in the down-link privacy computing cluster, an external object docked with the down-link privacy computing cluster does not need to pay attention to the fact that the other party is a single down-link privacy computing node or the down-link privacy computing cluster, only needs to be used as an object and interacted with the object, and does not need to pay attention to details of the node or the cluster behind.

Fig. 1 is a flowchart of a method for sharing a cluster key according to an exemplary embodiment. As shown in fig. 1, the method may include the steps of:

102, any node in the down-link privacy computing cluster acquires a first remote attestation report sent by other nodes in the down-link privacy computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other nodes for a created first down-link trusted execution environment.

In this embodiment, for the first remote attestation report of the other node and the generated first self-referral information, reference may be made to the explanations in the foregoing, and details are not repeated here. And after obtaining the first remote attestation report, the any node may determine whether the first downlinked trusted execution environment created by the other node is trusted according to the first remote attestation report. Specifically, the signature verification may be performed on the first remote attestation report according to the public key of the authentication server, and when the signature verification passes and the remote authentication result included in the first remote attestation report is that the remote authentication passes, a first hash value to be verified is extracted from the first self-recommended information carried in the first remote attestation report, where the first hash value to be verified is a hash value of preset information in the trusted execution environment under the first chain. After the first hash value to be tested is extracted, comparing a first standard hash value which is obtained in advance and aims at the preset information with the first hash value to be tested, and using the comparison result as a precondition for confirming that the trusted execution environment under the first chain is trusted. Similarly, the specific process of determining whether the first-chain trusted execution environment is trusted may refer to the process of determining, by the control node, whether the chain trusted execution environment to be joined with the node is trusted, which is not described herein again.

And 104, acquiring a cluster identity key corresponding to the private computing cluster under the chain by any node, wherein the cluster identity key is generated in a trusted execution environment under a second chain created by any node, and the cluster identity key is used for encrypting and decrypting interaction data and/or signing and checking a signature during the process that a block chain link interacts with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain.

In this embodiment, when a cluster identity needs to be generated, the control node may select a certain linked privacy computation node as a master node and other linked privacy computation nodes as slave nodes, and the master node generates a key pair (cluster identity key) representing the cluster identity and further shares the key pair to each slave node, so that all the linked privacy computation nodes maintain a uniform key pair representing the cluster identity. For example, after each node in the down-link privacy computing cluster has generated its own node identity information, the control node selects "any node" in step 104 as a master node, generates a cluster identity key corresponding to the down-link privacy computing cluster in the down-link TEE created by itself, and further acquires the generated cluster identity key to implement a sharing operation when the cluster identity key needs to be shared with other nodes.

Step 106, in a case where the any node determines that the trusted execution environment under the first chain is trusted according to the first remote attestation report, the any node sends the cluster identity key and a second remote attestation report to the other node, in a case where the second remote attestation report indicates that the trusted execution environment under the second chain is trusted, the cluster identity key is approved by the other node, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node for the trusted execution environment under the second chain.

In this embodiment, the other node approves the cluster identity key when determining that the second remote attestation report indicates that the trusted execution environment in the second chain is trusted, so as to maintain the cluster identity key in the trusted execution environment in the first chain of the other node.

Before sending the cluster identity key to the other nodes, the any node may verify the first node identity information of the other nodes. Further, the first node identity information includes the node identity public keys of the other nodes, and the node identity public key included in the first node identity information can be obtained to encrypt the cluster identity key under the condition that the first node identity information passes verification, so that the cluster identity key can be decrypted only by the other nodes through the node identity private keys of the other nodes, and the security that the cluster identity key is shared by any node to the other nodes is ensured. Specifically, the any node may obtain first node identity information provided by the other node (for example, the other node may associate the first node identity information with a first remote attestation report and send the first remote attestation report to the any node), and perform hash calculation on the obtained first node identity information to obtain a second hash value to be verified, where the first node identity information includes a node identity public key of the other node and other identity information of the other node. Meanwhile, the any node obtains a second standard hash value provided by the other node (for example, the second standard hash value may be included in the first remote attestation report), and the second standard hash value is obtained by performing hash calculation on the generated node identity information after the other node generates its own node identity information in the first-chain trusted execution environment. Further, the any node compares the second hash value to be verified with the second standard hash value, and obtains the node identity public key included in the node identity information of the other node if the comparison result is consistent, so that the cluster identity key is signed by using the node identity private key of the any node, and the signed cluster identity key is encrypted by using the node identity public keys of the other node. And when the any node shares the encrypted cluster identity key with the other nodes, sending the second remote certification report of the any node and the encrypted cluster identity key to the other nodes in an associated manner so as to certify the identity. Then, the other nodes decrypt the received cluster identity key by using the node identity private key of the other nodes under the condition that the trusted execution environment under the second chain created by the any node is determined to be trusted according to the second remote attestation report, verify the signature of the cluster identity key by using the node identity public key included in the node identity information of the any node, and maintain the cluster identity key in the trusted execution environment under the first chain under the condition that the signature verification is passed.

The manner of obtaining the node identity public key of any node is similar to the manner of obtaining the node identity public key of other nodes by any node. In particular, the any node may provide second node identity information to the other node (e.g., the any node may send the second node identity information to the other node in association with a second remote attestation report), the second node identity information including a node identity public key of the any node and other identity information of the any node. Meanwhile, the any node provides a third standard hash value to the other node (for example, the third standard hash value may be included in a second remote attestation report), and the third standard hash value is obtained by performing hash calculation on the generated node identity information after the any node generates its own node identity information in the second chain trusted execution environment. Then, the other nodes decrypt the received cluster identity key by using the node identity private keys of the other nodes under the condition that a third hash value to be verified obtained by performing hash calculation on the second node identity information is consistent with a third standard hash value, verify the signature of the cluster identity key by using the node identity public key included in the node identity information of any node, and maintain the cluster identity key in the trusted execution environment under the first chain under the condition that the signature verification is passed.

Therefore, before the cluster identity key is shared by any node to other nodes, the other nodes need to be verified, and after the cluster identity key shared by any node is received by other nodes, the any node also needs to be verified, so that the security of the shared cluster identity key is ensured.

As shown in fig. 2, assuming that the private computation cluster includes several private computation nodes, such as node 20, node 21, node 22, etc., a uniform cluster identity needs to be established among these nodes. First, each of the down-link privacy computing nodes creates a down-link TEE, and creates node identities within the respective down-link TEEs, such as node 20 creating TEE1, and creating a Key pair Key-0 representing its own node identity within TEE1, node 21 creating TEE2, and creating a Key pair Key-1 representing its own node identity within TEE1, node 22 creating TEE3, and creating a Key pair Key-2 representing its own node identity within TEE1, etc. The timing of each of the down-link privacy computing nodes joining the cluster is often different, and thus the timing of creating the down-link TEE and the node identity is also different. Generally, a node needs to initiate an application to a control node of a down-link privacy cluster, and the control node may initiate a challenge to the node issuing the application to verify a hardware environment of the node, software running in a down-link TEE, and the like, and add the node to the down-link privacy computing cluster after the verification is passed, so that the node becomes a down-link privacy computing node.

When the cluster identity needs to be generated, the control node may select a certain linked privacy computing node as a master node and other linked privacy computing nodes as slave nodes, the master node generates a key pair representing the cluster identity, and then shares the key pair to each slave node, so that all the linked privacy computing nodes maintain a uniform key pair representing the cluster identity. As shown in fig. 2, assume that node 20 is selected to be the master node, nodes 21-22, etc. to be the slave nodes. First, node 20 generates a Key pair representing the cluster identity, i.e., a cluster identity Key pair C-Key, within TEE 1. Then, the node 20 initiates a challenge to each slave node, so that the slave nodes, such as the node 21 and the node 22, generate remote attestation reports, respectively, which may refer to the foregoing description and is not described herein again. MREnclave, MRSigner, hash value of node identity information, etc. may be contained within the remote attestation report. The node 20 receives the remote attestation report and the node identity information returned from each slave node, respectively, and verifies it in the manner described above to determine whether each slave node is authentic.

Taking node 21 as an example, assume that node 20 determines that node 21 is trusted by way of remote attestation. In the Key pair Key-0 representing the identity of the node 20, for example, a group of signature Key pairs Key-0-S and a group of encryption Key pairs Key-0-T, the node 20 may use the private signature Key in the signature Key pair Key-0-S to sign the cluster identity Key pair C-Key. Meanwhile, the node identity information provided by the node 21 to the node 20 contains a public Key in the Key pair Key-1 representing the identity of the node 21, such as a signature public Key in the signature Key pair Key-1-S and an encryption public Key in the encryption Key pair Key-1-T. Therefore, the node 20 may encrypt the C-Key and its signature data of the above cluster identity Key pair by using the encryption Key to encrypt the encryption public Key in Key-1-T, obtain an encrypted Key pair, and send the encrypted Key pair to the node 21.

Node 20 also triggers the obtaining of a remote attestation report generated for its own created TEE1 in the manner described earlier, and node 20 sends this remote attestation report, in addition to sending the above-described encrypted key pair to node 21, along with node identity information of node 20 itself, to node 21 for node 21 to authenticate node 20. Under the condition that the node 20 is verified and determined to be credible, the node 21 decrypts the received encrypted Key pair by using an encryption private Key in Key-1-T of an encryption Key pair maintained by the node to obtain a cluster identity Key pair C-Key and signature data thereof; and the node 21 extracts the signature public Key in the Key-0-S of the signature Key pair from the node identity information of the node 20, verifies the decrypted signature data, if the signature verification is successful, the node 21 determines that the decrypted cluster identity Key pair C-Key is valid, and determines that the Key pair C-Key can represent the cluster identity of the private computation cluster under the chain. Similarly, in the above manner, the master node may share the cluster identity Key pair C-Key to each slave node, so that all the down-link privacy computation nodes in the down-link privacy computation cluster obtain the cluster identity Key pair C-Key finally.

Whether the private computing nodes are in the form of single nodes or in the form of private computing clusters, a deploying party of the contract under the chain can deploy the contract under the chain in the private computing nodes under the chain for subsequent invoking and executing the computing task.

The client of the deployer may initiate a challenge to the down-chain privacy computing node and receive a remote attestation report back from the down-chain privacy computing node. For example, the client may initiate a down-link challenge to the down-link privacy computing node, that is, the process of initiating the challenge is independent of the blockchain network, so that the consensus process between blockchain nodes may be skipped and the interactions in the up-link and down-link chains may be reduced, so that the challenge of the client to the down-link privacy computing node has higher operation efficiency. For another example, the client may take the form of an on-chain challenge, such as the client may submit a challenge transaction to a blockchain node, the challenge transaction may include challenge information that may be transmitted by the blockchain node to the off-chain privacy computing node through a prolog mechanism, and the challenge information may be used to initiate a challenge to the off-chain privacy computing node.

Take the scenario shown in fig. 3 as an example. In one case, the client 31 may directly initiate the challenge to the down-link privacy computing node 32 through the down-link channel, i.e., the client 31 initiates the down-link challenge to the down-link privacy computing node 32. In another case, the client 31 may initiate a challenge to the down-chain privacy computing node 32 through the blockchain network 33, i.e., the client 31 initiates an up-chain challenge to the down-chain privacy computing node 33. The initiation process of the on-chain challenge may include three steps: step (i), the client 31 submits a transaction for initiating a challenge, for example, called a challenge transaction, to the blockchain network 33, where the challenge transaction can be received and executed by a certain node 33n in the blockchain network 33; step two, the node 33n calls a pre-deployed intelligent contract of a language predictive machine (abbreviated as a contract of a language predictive machine for short), the contract of the language predictive machine can transmit the challenge information contained in the challenge transaction to the server 34 of the language predictive machine under the chain, for example, the contract of the language predictive machine can generate an event containing the challenge information, and the server 34 of the language predictive machine can monitor the event generated by the contract of the language predictive machine so as to obtain the challenge information; and step three, the predicting machine server 34 sends the challenge information to the down-link privacy computing node 32 through a down-link channel.

When the client 31 initiates a challenge to the down-link privacy computing node 32 through the up-link channel, the data interaction between the block link network 33 and the down-link privacy computing node 32, that is, the up-link and down-link data interaction, may be implemented by the cooperation of the predictive language contract and the predictive language server 34 through the above-mentioned steps, and the cooperation mechanism between the predictive language contract and the predictive language server 34 is the predictive language mechanism. Wherein a transaction submitted by the client 31 to the node 33n should directly or indirectly invoke the predictive-machine contract described above to trigger the predictive-machine mechanism. Wherein if the contract address of the predictive machine contract is filled into the to field of the transaction, the transaction directly calls the predictive machine contract; if the contract address of a contract on a chain is filled into the to field of the transaction and the contract on the chain invokes the president contract, it indicates that the transaction indirectly invokes the president contract. The contract on the chain calls the president contract, in one case, the contract address of the president contract is written in the byte code of the contract on the chain in advance, and in another case, the contract address of the president contract is used as an input parameter when the contract on the chain is called, and the input parameter is filled in the data field of the transaction. In addition to passing challenge information or other data from the chain up to the chain down, the predictive engine mechanism may pass data from the chain down to the chain up, and in particular, the predictive engine server 34 may pass data from the chain down to the predictive engine contract, and then the predictive engine contract may pass data from the chain down to the data demander, for example, where the data from the chain down may include remote attestation reports or private calculations resulting from invoking the contract down, etc. In the prediction machine mechanism described above, passing data from the on-chain to the off-chain can be considered a "request" process, and passing data from the off-chain to the on-chain can be considered a "response" process, and these two processes typically occur in pairs.

Whether a challenge is a down-link challenge or an up-link challenge, the privacy-down-link computing node may, upon receiving a challenge initiated by the client, temporarily trigger a remote attestation process as described above and generate a corresponding remote attestation report, which is then fed back to the client. Alternatively, the downlink privacy computing node, upon receiving the client-initiated challenge, provides the remote attestation report to the client without temporarily triggering the remote attestation process if a pre-generated remote attestation report already exists locally. The remote attestation report locally existing in the down-link privacy computing node may be generated by the down-link privacy computing node triggered in response to a challenge of another challenger other than the client, for example, the other challenger may include another client, a control node in a down-link privacy computing cluster in which the down-link privacy computing node is located, a KMS server, and the like, which is not limited in this specification. Thus, the down-link privacy computing node, upon receiving the client-initiated challenge, may first look to see if there is a previously generated remote attestation report locally, and if so, feed back the remote attestation report to the client, otherwise temporarily trigger the remote attestation process. The remote attestation report may have a certain time limit, for example, 30 minutes or other duration, the remote attestation report that is out of time may be considered as invalid by the client, and the linked privacy computing node may also actively clear the invalid remote attestation report to avoid feedback to the client.

Data interaction between devices is involved in the process that a client initiates a challenge to a down-link privacy computing node or the process that the down-link privacy computing node feeds back a remote attestation report to the client. Taking the scenario shown in fig. 3 as an example, the involved data interactions may include: data interaction between client 31 and down-link privacy computing node 32 (client 31 issues down-link challenge to down-link privacy computing node 32, down-link privacy computing node 32 returns remote attestation report to client 31), data interaction between client 31 and node 33n (client 31 sends challenge transaction to node 33n, node 33n returns remote attestation report to client 31), data interaction between the node 33n and the talker server 34 (the talker server 34 reads challenge information from the node 33n, the talker server 34 feeds back a remote attestation report to the node 33 n), data interaction between the talker server 34 and the down-link privacy computing node 32 (the talker server 34 sends challenge information to the down-link privacy computing node 32, the down-link privacy computing node 32 returns a remote attestation report to the talker server 34), and so on. In the process of implementing any data interaction, there is a possibility of leakage of data transmitted between the data sending party and the data receiving party, and the node 33n links the challenge transaction to the public, so that information leakage can be avoided by performing encrypted transmission on the data.

Take the example where client 31 submits a challenge transaction to node 33 n. The challenge transaction initiates an on-chain challenge to the down-chain privacy computing node 32, so that the node 33n can perform chain linking after the challenge transaction submitted by the client 31 is identified with other nodes, and verify the challenge behavior of the client 31. However, if the client 31 does not want his/her challenge behavior to be freely known by other users, the challenge transaction can be privacy protected. The client 31 may encrypt the challenge transaction, and the node 33n may receive the encrypted challenge transaction, which may ensure that the content of the challenge transaction is not leaked during transmission. The chain TEE may be deployed at the node 33n, and the node 33n may decrypt the encrypted challenge transaction within the chain TEE after reading the encrypted challenge transaction into the chain TEE, which may ensure that the decrypted challenge transaction only exists within the chain TEE and does not leak. Node 33n links the encrypted challenge transaction directly and manages the viewing rights of the encrypted data to restrict users who can view the challenge transaction, while other users can only obtain the encrypted challenge transaction when viewing the blockchain data directly. In fact, node 33n may ensure that data requiring privacy protection can only be decrypted to plaintext form within the TEE on the chain, and ciphertext form once it leaves the TEE on the chain.

The encrypted transmission for the challenge transaction may take the form of symmetric encryption or asymmetric encryption. When symmetric encryption is used, the client 31 and the node 33n respectively maintain the same symmetric Key, for example, the symmetric Key can be obtained by negotiation between the client 31 and the node 33n through an algorithm such as DH (Diffie-Hellman) or ECDH (explicit customer Diffie-Hellman), or distributed to the client 31 and the node 33n by a KMS (Key Management Service) server, and the Key source is not limited in this specification. When the key is distributed by the KMS server, the KMS server may determine that the on-chain TEE at the node 33n is trusted by means of remote attestation, which is similar to the remote attestation process of the client 31 to the down-chain privacy computing node 32, and then encrypt and transmit the key into the on-chain TEE, which will not be described herein again. Then, the client 31 may encrypt the challenge transaction by using the above symmetric key, and the node 33n maintains the symmetric key in the chain TEE, so that the encrypted challenge transaction is read into the chain TEE, and a decryption operation is performed by using the symmetric key to obtain the above challenge transaction. The encryption algorithm used for symmetric encryption may include, for example, DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, and the like.

When asymmetric encryption is employed, the node 33n maintains a private key with an asymmetric key, for example, referred to as a node private key, and the client 31 can obtain a node public key corresponding to the node private key. The asymmetric key may be generated by the node 33n within the chain TEE or distributed to the node 33n by the KMS server, and the key source is not limited in this description. Similarly, when the key is distributed by the KMS server, the KMS server may determine that the on-chain TEE at node 33n is authentic by way of remote attestation, and then cryptographically transmit the key into the on-chain TEE. Then, the client 31 may encrypt the challenge transaction through the node public key, and the node 33n maintains the node private key in the chain TEE, so that the encrypted challenge transaction is read into the chain TEE, and a decryption operation is performed through the node private key to obtain the above challenge transaction. Asymmetric encryption algorithms used for asymmetric encryption may include, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), and the like.

The encrypted transmission for the challenge transaction may also take the form of a combination of symmetric encryption and asymmetric encryption. The client 31 may maintain a symmetric key, for example, the symmetric key may be randomly generated by the client 31, and the client 31 may obtain a public key of the asymmetric key. The client 31 may encrypt the challenge transaction by using the symmetric key to obtain an encrypted challenge transaction, encrypt the symmetric key by using the asymmetric key to obtain an encrypted key, and transmit the encrypted challenge transaction and the encrypted key to the node 33n by using the client 31. Correspondingly, the node 33n reads the encrypted challenge transaction and the encrypted key into the chain TEE, decrypts the encrypted key through the node private key to obtain a symmetric key, and decrypts the encrypted challenge transaction through the symmetric key. In comparison, the encryption and decryption efficiency of the symmetric encryption is relatively higher but the security is relatively lower, while the encryption and decryption efficiency of the asymmetric encryption is relatively lower but the security is relatively higher, so that the encryption and decryption efficiency and the security can be both considered based on a form of combining the symmetric encryption and the asymmetric encryption.

Similarly, in the process of other data interaction, the same symmetric key is maintained between the data sender and the data receiver, or the data sender maintains a public key with an asymmetric key, the data receiver maintains a private key with an asymmetric key, or a symmetric encryption and asymmetric encryption form is combined, so that data encryption transmission between any data sender and any data receiver can be realized, which is not described herein again.

The down-link privacy computing node may belong to a down-link privacy computing cluster that includes a plurality of down-link privacy computing nodes. The interaction process between a client and a single down-link privacy computing node may refer to the embodiments described above if there is complete independence between the individual down-link privacy computing nodes. In another mode, the down-link privacy computing cluster may include a control node, and the control node may perform unified management on all down-link privacy computing nodes in the cluster. For example, the client may initiate a challenge to the control node and receive a remote attestation report of the above-described private computing node from the control node. Similar to the previous embodiments, the client may initiate a down-link challenge to the control node, or the client may submit a challenge transaction to the blockchain node, the challenge transaction containing challenge information that is transmitted by the blockchain node to the control node through a predictive mechanism, so that the control node returns a remote attestation report of the down-link privacy computation node to the client.

Take the scenario as shown in fig. 4 as an example. In one case, the client 41 may initiate the challenge directly to the control node 42 through the down-link channel, i.e. the client 41 initiates the down-link challenge to the control node 42. Alternatively, the client 41 may initiate the challenge to the control node 42 via the blockchain network 43, i.e. the client 41 initiates the on-chain challenge to the control node 42. The initiation process of the on-chain challenge may include three steps: first, the client 41 submits a transaction for initiating a challenge, for example, called a challenge transaction, to the blockchain network 43, where the challenge transaction can be received and executed by a certain node 43n in the blockchain network 43; step two, the node 43n calls a pre-deployed intelligent contract of a language predictive machine (abbreviated as a contract of a language predictive machine for short), the contract of the language predictive machine can transmit the challenge information contained in the challenge transaction to the server 44 of the language predictive machine under the chain, for example, the contract of the language predictive machine can generate an event containing the challenge information, and the server 44 of the language predictive machine can monitor the event generated by the contract of the language predictive machine, so as to obtain the challenge information; step three, the predicting machine server 44 sends the challenge information to the control node 42 through a channel under the chain.

When the client 41 initiates a challenge to the control node 42, the challenge target may be set as a certain down-link privacy computing node, such as the down-link privacy computing node 42n, in the cluster where the control node 42 is located, and then the control node 42 returns a remote attestation report corresponding to the down-link privacy computing node 42n to the client 41 according to the received challenge. The client 41 may not set the challenge target, and then the control node 42 selects from the down-chain privacy computing cluster after receiving the challenge, for example, returns a remote attestation report corresponding to the down-chain privacy computing node 42n to the client 41 when the down-chain privacy computing node 42n is selected.

After receiving the challenge initiated by the client 41, the control node 42 may forward the challenge to the down-link privacy computing node 42n, so that the down-link privacy computing node 42n temporarily triggers the remote attestation process to generate a corresponding remote attestation report, and then feeds the remote attestation report back to the client 41 through the control node 42. Alternatively, the control node 42 may forward the challenge to the down-link privacy computing node 42n after receiving the challenge initiated by the client 41, and if there is already a pre-generated remote attestation report on the down-link privacy computing node 42n, the down-link privacy computing node 42n returns the remote attestation report to the control node 42, which is provided by the control node 42 to the client 41 without temporarily triggering the remote attestation process. Alternatively, after receiving the challenge initiated by the client 41, if there is already a pre-generated remote attestation report corresponding to the down-link privacy computing node 42n locally at the control node 42, the down-link privacy computing node 42n provides the remote attestation report to the client 41 without forwarding the challenge to the down-link privacy computing node 42n or without the down-link privacy computing node 42n thus temporarily triggering the remote attestation process. The remote attestation report locally existing in the down-link privacy computing node 42n may be generated by the down-link privacy computing node 42n in response to a challenge of another challenger other than the client 41, for example, the other challenger may include another client, the control node 42, the KMS server, and the like, which is not limited in this specification. While the down-link privacy computing node 42n provides remote attestation reports to the other challengers described above through the control node 42, the control node 42 may cache the received remote attestation reports. Therefore, after receiving the challenge initiated by the client 41, the control node 42 may first check whether there is a previously obtained remote attestation report locally, and if so, feed back the remote attestation report to the client 41, otherwise, forward the challenge to the down-link privacy computation node 42 n; and, the down-link privacy computing node 42n, upon receiving the challenge, may first look to see if there is a previously obtained remote attestation report locally, and if so, feed back the remote attestation report to the control node 42, otherwise temporarily trigger the remote attestation process. Where the remote attestation report may have a certain time limit, such as 40 minutes or other duration, the remote attestation report that is out of time may be considered to be invalid by the client 41, and the control node 42 or the down-link privacy computing node 42n may also actively clear the invalid remote attestation report to avoid feedback to the client 41.

In the embodiment shown in fig. 4, data interaction may occur between the client 41 and the control node 42, between the control node 42 and the down-link privacy computing node 42n, between the client 41 and the node 43n, between the node 43n and the predictive server 44, between the predictive server 44 and the control node 42, and so on. For any data interaction process, the encrypted data transmission scheme as described above may be adopted, and the encrypted data transmission scheme includes a form of symmetric encryption, asymmetric encryption, or a combination of both forms, which is not described herein again.

Or, for the situation of the privacy computing cluster under the link, based on that each privacy computing node under the link maintains a cluster identity key in each chain TEE, the privacy computing cluster under the link can be regarded as a whole, the control node selects a node responding to the client, and each node in the privacy computing cluster under the link does not adopt a node identity key of itself but adopts the cluster identity key to encrypt and decrypt the interactive data or generate and verify a signature in the process of interacting with external equipment (such as a block chain node, the client and the like). The way of encrypting and decrypting by using the cluster identity key or generating and verifying the signature is similar to the above process using the node identity key, and is not described herein again.

Based on the scheme, the deployment party can deploy the down-chain contract to the down-chain privacy computing node through the client under the condition that the down-chain privacy computing node is determined to be credible. The contract under the link is similar to the contract on the link executed by the block link node, and may be a bytecode running in the virtual machine, which is not described herein again. By carrying out encryption transmission on the byte codes of the contract under the link, data leakage or modification and the like can be avoided in the transmission process, and the privacy and the safety are ensured.

Similar to the aforementioned challenge process, the client may encrypt and transmit the bytecode of the contract under the link to the private computing node under the link through a link-down approach, that is, the transmission process for the bytecode is independent of the blockchain network, so that the consensus process between blockchain nodes can be skipped, and the inter-operation under the link up is reduced, so that the transmission efficiency of the bytecode is higher. Or, the client may encrypt and transmit the bytecode for the contract under the chain to the privacy computing node under the chain through an on-chain path, for example, the client generates an under-chain contract deployment transaction, where the under-chain contract deployment transaction includes a bytecode ciphertext obtained by encrypting the bytecode, the client encrypts the under-chain contract deployment transaction and submits the encrypted under-chain contract deployment transaction to the block link point, and the encrypted under-chain contract deployment transaction may be decrypted in an on-chain TEE created at the block link point to obtain the bytecode ciphertext, and then the block link point transmits the bytecode ciphertext to the privacy computing node under the chain through a preplan mechanism.

Take the scenario as shown in fig. 5 as an example. In one case, the client 51 may encrypt and transmit the bytecode directly to the down-link privacy computing node 52 through the down-link channel, that is, the client 51 transmits the encrypted bytecode ciphertext to the down-link privacy computing node 52. In another case, the client 51 may encrypt and transmit the bytecode to the down-link privacy computing node 52 through the blockchain network 53, that is, the client 51 transmits the encrypted bytecode ciphertext to the down-link privacy computing node 52. The process of on-chain encrypted transmission may include three steps: step one, the client 51 submits a transaction for deploying the under-link contract, i.e. an under-link contract deployment transaction, to the blockchain network 53, where the under-link contract deployment transaction can be received and executed by a certain node 53n in the blockchain network 53; step two, the node 53n calls a preplan contract, and the preplan contract can transmit the bytecode contained in the under-chain contract deployment transaction to the preplan server 55 under the chain, for example, the preplan contract can generate an event containing the bytecode, and the preplan server 55 can monitor the event generated by the preplan contract to obtain the bytecode; and step three, the prediction machine server 55 sends the byte codes to the down-link privacy computing node 52 through a down-link channel.

In the process of the down-link encryption transmission, only data interaction between the client 51 and the down-link privacy computing node 52 is involved, and the encryption transmission scheme of the symmetric encryption, the asymmetric encryption, or a combination of the two may be adopted as described above, and will not be described herein again. During the process of encryption transmission on the chain, data interaction among a plurality of objects is involved, and byte codes are required to be ensured to be always in an encryption state. For example, when the client 51 submits the under-link contract deployment transaction to the node 53n, the under-link contract deployment transaction may be cryptographically transmitted by a cryptographic transmission scheme such as the symmetric encryption, the asymmetric encryption, or a combination thereof described above, such that the bytecode included in the under-link contract deployment transaction is in a cryptographically protected state. The bytecode contained in the contract deployment transaction under the chain may be in a plaintext state or a ciphertext state. If the node is in the ciphertext state, it is indicated that the client 51 encrypts the bytecode, and then adds the bytecode ciphertext to the data field of the contract deployment transaction under the chain, and the client 51 should ensure that only the privacy computation node 52 under the chain in the final link can decrypt the bytecode ciphertext, but neither the other node 53n nor the predictive server 55 can decrypt the bytecode ciphertext, then after the node 53n decrypts the contract deployment transaction under the chain in the TEE created by itself to obtain the bytecode ciphertext, the predictive server 55 can directly read the bytecode ciphertext, and then the predictive server 55 transmits the bytecode ciphertext to the privacy computation node 52 under the chain. If the node is in the plaintext state, which indicates that the client 51 directly adds the plaintext bytecode to the data field of the contract deployment transaction under the chain, and the contract deployment transaction under the chain can call a contract on the chain, the node 53n decrypts the contract deployment transaction under the chain in the TEE on the chain to obtain the plaintext bytecode, and then executes the contract on the chain through the virtual machine deployed in the TEE on the chain, so that the bytecode is encrypted into a corresponding bytecode ciphertext in the TEE on the chain, the bytecode ciphertext is ensured to be decrypted only by the privacy computing node 52 under the chain, and then the bytecode ciphertext is read by the prediction machine server 55 and is further transmitted to the privacy computing node 52 under the chain.

When the bytecode is encrypted, a symmetric encryption, an asymmetric encryption, or a combination of both may be used, which is not limited in this specification. When asymmetric encryption or a combination of symmetric encryption and asymmetric encryption is used, a group of asymmetric key pairs is involved, the client 51 or the node 53n needs to know the public key of the asymmetric key pair, and the private key of the asymmetric key pair needs to be maintained by the down-link privacy computing node 52, so that the down-link privacy computing node 52 can decrypt the received bytecode ciphertext based on the private key. For example, the asymmetric key pair may be the encryption key pair generated by the down-chain privacy computing node 52 in the down-chain TEE, described above; accordingly, after receiving the bytecode ciphertext, the down-link privacy computing node 52 reads the bytecode ciphertext into the down-link TEE, and decrypts the bytecode ciphertext based on the encryption private key, thereby obtaining the bytecode of the plaintext.

After the node 52 for privacy under the chain decrypts the bytecode in the plaintext in the TEE under the chain, the bytecode may be re-encrypted in the TEE under the chain and then stored in a storage space outside the TEE under the chain, for example, a hard disk of the node 52 for privacy under the chain, so as to complete deployment of the contract under the chain. Here, the node 52 typically uses a symmetric key to encrypt and store the bytecode by symmetric encryption, so that the decryption operation can be performed faster than in the form of asymmetric encryption when the bytecode is called later. The symmetric key may be generated by the down-chain privacy computing node 52 in the down-chain TEE, or distributed by other objects to the down-chain privacy computing node 52 by way of encrypted transmission. For example, the symmetric key described above may be distributed to the down-chain privacy computing node 52 by the KMS server initiating a challenge to the down-chain privacy computing node 52 and verifying that the down-chain privacy computing node 52 is trusted by remote attestation. The down-link privacy computing node 52 can take the symmetric key distributed by the KMS server as the root key and apply a derivative key derived based on the root key to the encrypted storage for the bytecode. For another example, based on the Intel SGX technology, the symmetric Key may be an RSK (root Seal Key) Key burned in an e-fuses storage circuit in the CPU of the down-link privacy computing node 52, or a derivative Key (i.e., Seal Key) derived from the RSK Key. Of course, the node 52 may also encrypt and store the byte codes by using asymmetric encryption or a combination of symmetric encryption and asymmetric encryption, which is not limited in this specification.

In addition to securely storing the bytecode of the down-link contract at the down-link privacy computing node 52, the client 51 may specify to the down-link privacy computing node 52 an execution engine for executing the bytecode. For example, in the offline TEE created at the offline privacy computation node 52, several execution engines may be deployed, such as one or more of EVM, WASM virtual machine, and so on, and especially in the case where multiple execution engines are deployed simultaneously, the client 51 may send, to the offline privacy computation node 52, execution engine specifying information associated with the bytecode, the execution engine specifying information indicating, to the offline privacy computation node 52, an execution engine for executing the bytecode, such as employing an EVM or a WSAM virtual machine, and so on. For example, the bytecode and the execution engine specifying information may be packaged and encrypted and then transmitted to the down-link privacy computing node 52; the bytecode and the execution engine specifying information may also be encrypted and transmitted separately, where the execution engine specifying information should include information of the corresponding bytecode or the contract under the chain, such as a hash value of the bytecode, so as to determine which contract under the chain the execution engine specifying information corresponds to based on the information. Accordingly, when deploying the contract under the chain, the privacy-preserving computation node 52 under the chain needs to mark information of an execution engine that the bytecode needs to adopt, in addition to encrypting and storing the bytecode, so that an appropriate virtual machine is selected as the execution engine for processing the corresponding bytecode in a subsequent calling process.

In the above manner, the client 51 may deploy more down-link contracts to the down-link privacy computing node 52; similarly, other clients may also deploy the down-link contract to the down-link privacy computing node 52. To facilitate management, and subsequent invocation of the under-chain contract, the under-chain privacy computing node 52 may generate a corresponding contract ID for the deployed under-chain contract, with a one-to-one correspondence between the under-chain contract and the contract ID. For example, after completing the deployment operation for the contract under the chain, the privacy-preserving computation node 52 under the chain may perform a hash operation on the bytecode of the contract under the chain to obtain a first hash value, and use the first hash value as the contract ID of the contract under the chain. Of course, the contract ID may be generated by the down-link privacy computing node 52 in other ways, which is not limited in this specification.

The first hash value described above may also have other effects if it is used as a contract ID for a contract under a chain. After deployment is completed, the down-link privacy computation node 52 may feed back deployment result information to the client 51, where the deployment result information includes the first hash value, and the client 51 may further perform hash computation on the bytecode sent by itself to obtain a second hash value, and compare the first hash value with the second hash value: if the two are consistent, the bytecode deployed by the down-link privacy computing node 52 is correct and has no error, and the bytecode is not replaced or has other accidents in the transmission process, and the client 51 can confirm that the deployment of the down-link privacy computing node 52 is successful; if the two are not consistent, the client 51 may consider that the deployment of the under-chain contract fails, or that the deployed under-chain contract is at risk. The client 51 may mark successfully deployed in-chain contracts as trusted contracts and unsuccessfully deployed in-chain contracts as untrusted contracts or as non-maintained, so that calls may be made in subsequent processes only for trusted contracts. If the client 51 transmits the bytecode to the down-link privacy computing node 52 through the down-link path, the down-link privacy computing node 52 returns the deployment result information to the client 51 through the down-link path as well; if the client 51 transmits the bytecode to the down-link privacy computing node 52 through the up-link path, the down-link privacy computing node 52 also feeds back the deployment result information to the client 51 through the up-link path.

When the private computation nodes under the chain belong to the private computation cluster under the chain, the control node uniformly manages all the private computation nodes under the chain in the cluster, and then in the process of deploying the contract on the chain, the client side firstly encrypts and transmits the byte codes to the control node, and then the control node forwards the byte codes to one or more private computation nodes under the chain in the cluster, so that the byte codes of the contract on the chain are deployed to one or more private computation nodes under the chain in the cluster. If the private computing nodes are deployed to a plurality of the down-link private computing nodes, the down-link private computing nodes can simultaneously provide calling capacity aiming at the same down-link contract, so that parallel down-link private computing is realized, and load balancing can be realized among the plurality of the down-link private computing nodes.

Take the scenario as shown in fig. 6 as an example. In one case, the client 61 may directly send the bytecode ciphertext to the control node 62 through a link-down channel, that is, the client 61 transmits the bytecode to the control node 62 in a link-down encryption manner, and then the bytecode is forwarded by the control node 62 to one or more link-down privacy computing nodes in the cluster. In another case, the client 61 may encrypt and transmit the bytecode to the control node 62 through the blockchain network 63, that is, the client 61 transmits the encrypted bytecode ciphertext to the chain of the control node 62. The process of on-chain encrypted transmission may include three steps: step one, the client 61 submits a trade for deploying the under-link contract to the blockchain network 63, that is, the under-link contract deployment trade, which can be received and executed by a certain node 63n in the blockchain network 63; step two, the node 63n calls a preplan contract, and the preplan contract can transmit the bytecode contained in the under-chain contract deployment transaction to the preplan server 64 under the chain, for example, the preplan contract can generate an event containing the bytecode, and the preplan server 64 can monitor the event generated by the preplan contract to obtain the bytecode; step three, the predictive controller server 64 sends the bytecode to the control node 62 through a downlink channel, and the bytecode is further forwarded to one or more downlink privacy computing nodes in the cluster by the control node 62.

If only one down-chain privacy computing node, such as the down-chain privacy computing node 62n shown in fig. 6, is needed, similar to the embodiment shown in fig. 5, the client 61 or the node 63n only needs to ensure that the down-chain privacy computing node 62n can decrypt when encrypting the bytecode. For example, the encryption public key generated by the down-link privacy computing node 62n in the down-link TEE may be used to encrypt the bytecode, and after receiving the bytecode ciphertext, the down-link privacy computing node 62n may decrypt the bytecode ciphertext through the encryption private key in the down-link TEE, so as to obtain the plaintext bytecode. Meanwhile, the client 61 may carry deployment target indication information, and the control node 62 may determine, according to the deployment target indication information, that the corresponding deployment target is the downlink privacy calculation node 62n, so as to accurately forward the bytecode ciphertext to the downlink privacy calculation node 62n without forwarding to other downlink privacy calculation nodes in the cluster. If the client 61 does not carry the deployment target indication information, the control node 62 may forward the bytecode ciphertext to all the down-link privacy computing nodes in the cluster, but only the down-link privacy computing node 62n can successfully decrypt and complete the deployment.

If the deployment is required to be performed on a plurality of the down-link privacy computing nodes in the cluster, in addition to an independent deployment mode, the down-link contract may be safely deployed to the plurality of the down-link privacy computing nodes at the same time in the present specification. As mentioned above, each of the private computation nodes under the chain has its own node identity information, and the node identity information relates to a key pair created by each of the private computation nodes under the chain within its own TEE, such as an encryption key pair and a signature key pair, or a key pair that combines encryption and signature functions. The following description will be given taking an encryption key pair and a signature key pair as examples. Based on that each private calculation node under the chain maintains a cluster identity key in each TEE under the chain, the private calculation cluster under the chain can be regarded as a whole, and the cluster identity keys shared by all the nodes are utilized to safely deploy the contract under the chain to a plurality of private calculation nodes under the chain, so that the plurality of private calculation nodes under the chain can decrypt the received byte code ciphertext smoothly. The cluster identity key may include a cluster encryption key pair and a cluster signature key pair, and through the above process of sharing the cluster identity key, each of the down-link privacy computing nodes maintains a cluster encryption private key and a cluster signature private key in the respective down-link TEE, so that the client 61 or the node 63n can ensure that each of the down-link privacy computing nodes can decrypt the bytecode through the cluster encryption private key in the respective down-link TEE as long as the client uses the cluster encryption public key to encrypt the bytecode, thereby obtaining the bytecode and completing deployment. Of course, even if the encryption key is deployed to only a single down-link privacy computing node, the above-mentioned cluster encryption public key may be used to encrypt the bytecode as long as the corresponding down-link privacy computing node can decrypt smoothly. In fact, based on the cluster identity, the client 61 does not need to pay attention to the other party as a single down-link privacy computing node or a down-link privacy computing cluster, and only needs to take the other party as an object and interact with the object, and does not need to pay attention to the details of the nodes or clusters behind.

Taking said any node in the embodiment of fig. 1 as an example, the deployer may initiate a challenge to said any node before deploying the target under-chain contract to said any node, and then said any node may provide its own remote attestation report, i.e. the second remote attestation report, to the deployer in response to the challenge initiated by the deployer. Wherein the deployer may send the encrypted target down-link contract if it is determined from the second remote attestation report that the second down-link trusted execution environment (i.e., the down-link trusted execution environment created by the any node) is trusted. For example, the group identity public key in the group identity key may be used to encrypt the bytecode of the contract under the target link, and then the encrypted bytecode is sent to any node. After receiving the encrypted target under-chain contract, any node decrypts the target under-chain contract through the cluster identity private key in the cluster identity key in the trusted execution environment under the second chain and deploys the target under-chain contract. After the deployment of the target under-chain contract is completed, in the case that the block link point initiates a call to the target under-chain contract through the preplan mechanism, the any node may execute the target under-chain contract in the second under-chain trusted execution environment, and feed back the execution result to the block link point through the preplan mechanism.

In addition, in the challenge process described above, if the challenge needs to be sent to the down-link privacy computing node instead of the control node directly feeding back the remote attestation report, the challenge information may also be encrypted by using the cluster encryption public key, as long as the corresponding down-link privacy computing node can decrypt the challenge smoothly. However, if it is desired that the control node directly feeds back the remote attestation report (a remote attestation report obtained in advance, or obtained by the control node initiating a challenge to the down-link privacy computing node), the challenge information should be encrypted by using the identity public key of the control node, so as to ensure that the control node can perform decryption by using the identity private key within the TEE created by the control node.

In the embodiment shown in fig. 6, the client 61 may send execution engine specifying information, so that the execution engine for executing the bytecode may be known by the down-link privacy computing node where the down-link contract is deployed, which is not described herein again, and reference may be made to the embodiment shown in fig. 5. In addition, the client 61 may receive deployment result information, where the deployment result information includes a hash value of the contract under the link, for example, a first hash value, so that the client 61 may compare the first hash value with a second hash value corresponding to the bytecode sent by the client, so as to determine whether the contract on the link is successfully deployed by the privacy computation node under the link. If the contract on the link is deployed to a plurality of privacy computation nodes under the link, the control node 62 only needs to ensure that the deployment result information fed back by all privacy computation nodes under the link is consistent, and transmit the deployment result information fed back by any privacy computation node under the link to the client 61.

Based on the above embodiments, the present specification may effectively verify, based on a remote attestation manner, the hardware security of the private computation node under the chain, the software correctness of the TEE under the chain, and the like, so that, when the private computation node under the chain is verified to be trusted, the contract under the chain is safely deployed to the private computation node under the chain in an encrypted transmission manner, and the contract under the chain is only executed within the TEE under the chain created by the private computation node under the chain, which has extremely high security, can undertake the task of private computation under the chain distributed by the block link points, and ensure that the task of private technique under the chain is executed safely, reliably, and efficiently. Meanwhile, when the computing task is executed on the private computing nodes under the chain, a consensus mechanism among the nodes is not involved, so that the computing task only needs to be executed on a single private computing node under the chain, and compared with an on-chain contract which is limited by the consensus mechanism and needs to be executed by all block chain nodes, the resource consumption caused by the execution of the computing task can be greatly reduced.

In the technical solution of the present specification, except that the private computing node under the chain may have a unified cluster identity, a contract identity may be generated for a contract under the chain deployed on the private computing node under the chain. When multiple down-link privacy computing nodes exist in the cluster, each down-link privacy computing node can establish a contract identity for the down-link contract deployed by itself, and the contract identities generated by different down-link privacy computing nodes for the same down-link contract are the same.

In the example of deploying target under-chain contracts at various nodes described above, when a target under-chain contract is deployed in any node in the under-chain privacy computing cluster, that node may generate a contract identity key for the target under-chain contract. As an exemplary embodiment, the any node, within the created under-chain trusted execution environment, generates a contract identity key corresponding to the target under-chain contract based on the common factor of each node within the under-chain private computation cluster and the global identification information of the target under-chain contract (the under-chain contract deployed by each node in the private computation cluster is the same, and the global identification information of the same under-chain contract deployed by each node is the same). And the execution result is signed by adopting a contract identity key in the chain lower trusted execution environment of any node, and the signed execution result can be fed back to the block chain node through the predictive engine mechanism. As can be seen, each of the down-link privacy computing nodes generates a contract identity key for the down-link contract that has been deployed by itself in the above manner, and it can be ensured that the contract identity keys generated by each of the nodes for the same down-link contract are also the same. Meanwhile, compared with a mode that any node uniformly generates the contract identity key and then shares the contract identity key with other nodes, the efficiency of generating the contract identity key by each node is higher. It should be noted that the key generation algorithm can be flexibly selected according to actual situations, such as a bcrypt algorithm, a scrypt algorithm, PBKDF2, and the like.

In one case, the common factor may be generated by the control node and issued by the control node in unison as each node joins the cluster, so that each node joining the cluster may maintain the common factor. In another case, the common factor includes a cluster identity key corresponding to the privacy computing cluster, the cluster identity key being used to encrypt and decrypt and/or sign and verify interactive data during interaction of the block-link nodes with nodes in the down-chain privacy computing cluster to deploy or invoke down-chain contracts.

By way of example, the contract identity key may include a contract encryption key pair and a contract signature key pair; the contract identity public key comprises a public key in a contract encryption key pair and a public key in a contract signature key pair, and the contract identity private key comprises a private key in the contract encryption key pair and a private key in the contract signature key pair. Then, in addition to encrypting the call request using the cluster identity public key, the client or the block link point may also encrypt information of the access data included in the call request using the contract encryption public key. After receiving a call request aiming at a contract under a certain chain, the private computation node under the chain decrypts the encrypted information of the access data in the call request by adopting a contract encryption private key corresponding to the contract under the chain, thereby ensuring that the information of the access data can only be obtained by the called contract under the chain and can not be obtained by other contracts under the chain. And after the execution result of the contract under the target chain is obtained, the private computation node under the chain signs the execution result by adopting a contract identity private key of the contract under the target chain in the trusted execution environment under the chain before feeding the execution result back to the block chain link point through a preplan mechanism, and then the signed execution result is judged to be generated by the contract under the target chain under the condition that the signature verification is carried out on the execution result by adopting a contract identity public key of the contract under the target chain and the signature verification is passed. In other words, the private chain computing node may sign the execution result with the contract signature private key of the invoked contract under the chain, and the client or node may verify the execution result with the contract signature public key to determine that the execution result was indeed generated by the invoked contract under the chain

The chain privacy computing node can select a uniform cluster identity key and a contract ID of a chain contract, and derive the cluster identity key and the contract ID by adopting a key derivation algorithm to obtain a corresponding contract identity key, and because the cluster identity keys are the same and the contract IDs of different chain contracts are different, the following can be ensured: different down-link contracts deployed on the same down-link privacy computing node have different contract identities, while the same down-link contract deployed on different down-link privacy computing nodes have the same contract identity. Correspondingly, when the control node distributes the received call request, the control node only needs to pay attention to the idle degree of each linked privacy computing node in the cluster, and performs task distribution based on the idle degree without paying attention to other information. The key derivation algorithm may be flexibly selected according to actual situations, for example, a PBKDF2 key derivation algorithm may be used, but this specification is not limited thereto.

Based on the chain contract deployment scheme of the present specification, the block link point may allocate the computation task to the chain privacy computation node, and invoke the chain contract deployed on the chain privacy computation node, and execute the chain contract in the chain TEE created by the chain privacy computation node to complete the computation task. Through technologies such as remote certification, encrypted transmission, signature-based identity verification and the like, the reliability of a calculation result obtained by the privacy calculation node under the chain can be ensured, data leakage cannot be caused in the calculation process, and the method has extremely high safety. After the calculation is completed, the block chain link points can update the block chain account book data according to the calculation result, can perform solidification evidence storage on the calculation result, and can support later verification aiming at the calculation result. Meanwhile, compared with the uplink data generated after the block link point performs the on-chain contract, the calculation result generated based on the off-chain contract is relatively shorter, so that the calculation result is beneficial to saving the on-chain storage space when being linked.

Before the user calls the target under-chain contract through the client, the user can initiate a challenge to the target under-chain contract deployed in the under-chain privacy computing node to ensure that the target under-chain contract deployed in the under-chain privacy computing node is credible, and then the computing task is executed according to the expectation of the user. The following description is made with respect to the challenge processes in the form of a single node and a cluster, respectively, in conjunction with fig. 7-8.

As shown in fig. 7, for a single node form, the client 71 may initiate either a down-link challenge or an up-link challenge to the down-link privacy computation node 72, similar to the embodiment shown in fig. 3. The initiation process of the on-chain challenge may include three steps: step (i), the client 71 submits a transaction, called a challenge transaction, to the blockchain network 73, for initiating a challenge to the target link contract, where the challenge transaction may be received and executed by a certain node 73n in the blockchain network 73; step two, the node 73n calls a pre-deployed pre-language contract, the pre-language contract can transmit the challenge information contained in the challenge transaction to the pre-language server 74 under the chain, for example, the pre-language contract can generate an event containing the challenge information, and the pre-language server 74 can monitor the event generated by the pre-language contract to obtain the challenge information; step three, the predictive server 74 sends the challenge information to the control node 72 through a channel under the link.

By initiating a challenge for a target down-link contract deployed by the down-link privacy computing node 72, the client 71 may obtain a remote attestation report for the down-link TEE created by the down-link privacy computing node 72, the remote attestation report being generated by the authentication server after verifying the self-referral information generated by the down-link privacy computing node 72 for the down-link TEE. In one case, a challenge is initiated by the client 71 to the down-link privacy computing node 72, the challenge is a target down-link contract deployed by the down-link privacy computing node 72, and the remote attestation report and the contract information to be verified returned by the down-link privacy computing node 72 in response to the challenge are received, that is, the down-link privacy computing node 72 returns the remote attestation report and the contract information to be verified to the client 71 at one time in response to the challenge. In another case, a challenge is initiated by the client 71 to the down-chain privacy computing node 72, the challenge target is a down-chain TEE created by the down-chain privacy computing node 72, and then a remote attestation report returned by the down-chain privacy computing node 72 is received, and in a case where the down-chain TEE is determined to be trusted according to the remote attestation report, an acquisition request for contract information of a target down-chain contract deployed at the down-chain privacy computing node 72 is sent to the down-chain privacy computing node 72, and contract information to be verified returned by the down-chain privacy computing node 72 in response to the acquisition request is received. In the event that the down-link TEE is determined to be untrusted based on the remote attestation report, there is no need to request the down-link privacy computing node 72 to obtain contract information for the target down-link contract (i.e., contract information to be verified).

Wherein the client 71 may initiate a challenge to the challenge target by an on-chain challenge. For example, a challenge transaction for the challenge target is submitted to the blockchain node 73n, and the challenge transaction includes challenge information transmitted by the blockchain node 73n to the down-chain privacy computing node 72 through the prolog mechanism, and the challenge information is used for initiating a challenge to the challenge target. Alternatively, the client 71 directly initiates the down-link challenge to a challenge target in the down-link privacy computation node 72.

In this embodiment, the operation of the client 71 to verify the offline TEE of the offline privacy computing node 72 according to the remote attestation report may include: and performing signature verification on the remote certification report according to a public key of the authentication server, extracting a first hash value to be verified from self-recommended information carried by the remote certification report under the condition that the signature verification is passed and a remote authentication result contained in the remote certification report is that the remote certification report passes the authentication, wherein the first hash value to be verified is a hash value of preset information of the TEE under the chain, and comparing a first standard hash value which is obtained in advance and aims at the TEE under the chain with the first hash value to be verified. Wherein, the consistency of the comparison result is used as a precondition for confirming the credibility of the TEE under the chain. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

As shown in fig. 7, in an embodiment, after the node identity information of the node 72 is generated in the chain TEE, the generated node identity information may be subjected to hash calculation to obtain a second standard hash value; the generated node identity information includes a node identity public key of the down-link privacy computing node 72 and other identity information of the down-link privacy computing node 72. Then, the client 71 may verify the first node identity information (i.e., the declared node identity information, which includes the node identity public key of the private computing node 72 and other identity information of the private computing node 72, and is not necessarily real data, and may be understood as the identity information to be verified) provided by the private computing node 72 under the chain by using the second standard hash value, and obtain the node identity public key included in the node identity information of the private computing node 72 under the verifiable chain if the verification passes, so as to complete the subsequent verification of the contract under the target chain by using the node identity public key. For example, the client performs hash calculation on the acquired first node identity information to obtain a second hash value to be checked, and compares the second hash value to be checked with a second standard hash value provided by the down-link privacy computing node 72, so as to determine that the node identity information is verified under the condition that the comparison result is consistent. Since the node identity information is generated and calculated by the down-link privacy computing node 72 in the down-link TEE, and then the second standard hash value is obtained, after the down-link TEE is judged to be trusted according to the remote certification report, if the second hash value to be verified is the same as the second standard hash value, it is indicated that the first node identity information provided by the privacy computing node 72 is the node identity information generated in the down-link TEE, and thus the node identity public key included therein is the actual node identity public key of the privacy computing node 72, and the actual node identity public key of the privacy computing node 72 can be used for verifying the signature of the privacy computing node 72. The downlink privacy computation node 72 may send the second standard hash value, the remote attestation report, and the first node identity information to the client 71. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

As shown in fig. 7, in another embodiment, the node identity information generated by the down-link privacy computing node 72 in the down-link TEE includes a node identity public key of the down-link privacy computing node 72, other identity information of the down-link privacy computing node 72, and a hash value of preset information of the down-link TEE, and then the down-link privacy computing node 72 performs hash calculation on the generated node identity information after generating the node identity information in the down-link TEE to obtain a third standard hash value, and then the third standard hash value is equivalent to simultaneously implementing the functions of the first hash value to be checked and the second standard hash value. In particular, the down-link privacy computing node 72 may provide the remote attestation report, the third standard hash value, and the second node identity information (which at this point may be understood as the identity information to be verified) to the client 71. The second node identity information comprises a node identity public key of the down-link privacy computing node 72, other identity information of the down-link privacy computing node 72 and a fourth hash value to be verified, wherein the fourth hash value to be verified is a hash value of preset information of the down-link TEE; meanwhile, the second node identity information is declared node identity information, and is not necessarily real node identity information of the down-link privacy computing node 72. Then, the client 71 performs signature verification on the remote attestation report according to the public key of the authentication server, performs hash calculation on the acquired second node identity information to obtain a third hash value to be verified under the condition that the signature verification is passed and the remote authentication result included in the remote attestation report is that the remote authentication result is passed, and compares the third hash value to be verified with the third standard hash value. When the comparison result is consistent, it indicates that the second node identity information provided by the privacy computing node 72 is the node identity information generated in the chain TEE, that is, the fourth hash value to be verified included therein is the hash value of the actual preset information of the chain TEE. Therefore, a fourth standard hash value and a fourth hash value to be checked, which are obtained in advance and are used for the chain TEE preset information, are further compared, and the comparison result is consistent to be used as a precondition for confirming that the chain TEE is credible. Meanwhile, the node identity public key included in the second node identity information may be determined as the actual node identity public key of the privacy computing node 72, and may be used to perform signature verification on the contract information to be verified. The downlink privacy computation node 72 may send the third standard hash value, the remote attestation report, and the second node identity information to the client 71. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

Under the condition that the chain TEE is determined to be credible according to the remote certification report, the client 71 acquires contract information to be verified of a target chain contract deployed at the chain privacy calculation node 72, the contract information to be verified is signed by the chain privacy calculation node 72 in the chain TEE by using a node identity private key of the client, and the node identity private key is generated by the chain privacy calculation node 72 in the chain TEE. For example, the down-link privacy computing node 72 may read the deployed target down-link contract into the down-link TEE and sign with its own node identity private key.

The client 71 performs signature verification on the contract information to be verified by using the node identity public key of the down-link privacy computing node 72, and performs contract information verification on the contract information to be verified according to the contract information of the target down-link contract. Wherein the node identity public key is in a public state, such as the private computing node 72 publishing the node identity public key publicly out for acquisition by the client 71. Alternatively, the client 71 obtains the node identity information of the privacy computation node 72 through the verification link. Meanwhile, the contract information of the target down-link contract may also be in a public state, such as the deployment direction of the target down-link contract publicly developing the contract information to be acquired by the client 71. The contract information may include information such as a name, a description, a version number, a bytecode hash value, and a contract identity public key of the linked contract, which is not limited in this specification.

In the event that the signature verification and contract information verification pass, the client 71 may determine that the client 71 is executing in the down-chain TEE trusted execution environment by the down-chain privacy computing node 72 when a call is initiated to the target down-chain contract through the prolog mechanism of the blockchain node. In this specification, the process of verifying the contract under the chain is to verify that the TEE under the chain of the privacy computing node 72 is trusted, and then, in the case of verifying the TEE under the chain of the privacy computing node 72 to be trusted, if the contract information to be verified provided by the privacy computing node 72 under the chain is obtained by verifying the signature and is indeed signed by the node identity private key (maintained in the TEE under the chain) of the privacy computing node 72 under the chain, it may be determined that the contract under the chain which is currently challenged is the target contract under the chain which runs in the TEE under the chain of the privacy computing node 72, that is, it is ensured that the contract under the target chain deployed in the privacy computing node 72 under the chain is trusted, and the computing task may be executed according to the expectation of the user.

As shown in fig. 8, for the form of a cluster of down-link privacy computations, similar to the embodiment shown in fig. 4, the client 81 may initiate a down-link challenge or an up-link challenge to the control node 82. The initiation process of the on-chain challenge may include three steps: step one, the client 81 submits a transaction for initiating a challenge to the target chain contract, for example, called a challenge transaction, to the blockchain network 83, where the challenge transaction may be received and executed by a certain node 83n in the blockchain network 83; step two, the node 83n calls a pre-deployed prompter contract, the prompter contract can transmit the challenge information contained in the challenge transaction to a prompter server 84 under the chain, for example, the prompter contract can generate an event containing the challenge information, and the prompter server 84 can monitor the event generated by the prompter contract to acquire the challenge information; step three, the predicting machine server 84 sends the challenge information to the control node 82 through a downlink channel.

The private computing cluster in the chain as a whole provides the functionality of performing computing tasks outward. In this case, each node in the cluster may be deployed with the same contract under the link, and then each node may perform a computing task on behalf of the cluster, for example, the computing task may be distributed by the control node. Therefore, when each node performs data interaction with the outside on behalf of the cluster, the data interacted with the outside is decrypted or signed by using the cluster identity key representing the cluster identity, rather than using the node identity key of the node itself. Correspondingly, when the external object interacts with the cluster through the client, the cluster is regarded as a whole without paying attention to the internal structure of the cluster, and therefore the cluster identity key is adopted for encryption or signature verification.

As shown in fig. 8, a user may initiate a challenge to a target under-chain contract deployed in a cluster through a client 81 before invoking the target under-chain contract in the cluster through the client 81 (the challenge is initiated after each node in the under-chain privacy computing cluster deploys the target under-chain contract). Control node 82, upon receiving the challenge, may select any node in the cluster to respond to the challenge. For example, the master node for generating the cluster identity key may be selected, or a slave node in the cluster may be selected, and the specification does not limit the manner of selecting the node responding to the challenge. The example of node 82n responding to the challenge is illustrated. Control node 82 selects node 82n to respond to the challenge on behalf of the cluster, providing the challenger with a cluster remote attestation report on behalf of the cluster. The cluster remote attestation report is generated by the authentication server after verifying the self-referral information generated by the node 82n for the own chain TEE, that is, the cluster remote attestation report is the remote attestation report corresponding to the chain TEE of the node 82 n. Specifically, the self-recommendation information carried by the cluster remote attestation report includes a first hash value to be verified, where the first hash value to be verified is a hash value of preset information of the chain-down TEE of the node 82n, the first hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is that the remote authentication result passes authentication, the cluster remote attestation report is compared with a first standard hash value (for example, a trusted hash value of the preset information of the chain-down TEE) obtained in advance for the chain-down TEE, and the comparison result is consistent and is used as a precondition that the challenger confirms that the chain-down TEE is trusted. The process of verifying the chain-down TEE by the challenger according to the cluster remote certification report may refer to the content of the chain-down TEE verified by the control node to be added to the node, which is not described herein again. In effect, the challenger reports the verified down-chain TEE from the cluster remote attestation as the down-chain TEE for node 82 n.

As shown in fig. 8, in an embodiment, when the node 82n generates its own node identity information in the chain TEE, cluster identity information representing a cluster may also be generated in the chain TEE, and the generated cluster identity information is subjected to hash calculation to obtain a second standard hash value; the generated cluster identity information includes the cluster identity public key and other identity information except the node identity public key in the node identity information of the node 82 n. In other words, based on representing the cluster by node 82n, the difference between the node identity information of node 82n and the cluster identity information is: the public key recorded in the node identity information is a node identity public key, and the public key recorded in the cluster identity information is a cluster identity public key; otherwise, the identity information is the same. Then, the client 81 may verify the first cluster identity information (i.e., the declared cluster identity information, which includes the cluster identity public key and other identity information of the node 82n, and is not necessarily real data, and may be understood as identity information to be verified) provided by the node 82n using the second standard hash value, and obtain the cluster identity public key included in the cluster identity information when the verification passes, so as to complete the subsequent verification of the contract under the target link using the cluster identity public key. For example, the client performs hash calculation on the acquired first cluster identity information to obtain a second hash value to be verified, and compares the second hash value to be verified with a second standard hash value provided by the node 82n, so as to determine that the cluster identity authentication is passed when the comparison result is consistent. Since the cluster identity information is generated by the node 82n in the chain TEE and calculated to obtain the second standard hash value, after the chain TEE is judged to be trusted according to the remote certification report, if the second hash value to be verified is the same as the second standard hash value, it is indicated that the first cluster identity information provided by the privacy computing node 82 is the cluster identity information generated in the chain TEE, so that the cluster identity public key included therein is the cluster identity public key corresponding to the cluster actually maintained by the privacy computing node 82, and the cluster identity public key actually maintained by the privacy computing node 82 can be used for verifying the signature of the privacy computing node 82. The node 82n may send the second standard hash value, the remote attestation report, and the first cluster identity information to the client 81 through the control node 82. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

As shown in fig. 8, in another embodiment, the cluster identity information generated by the node 82n in the chain-down TEE may include a cluster identity public key, identity information of the node 82n except for the node identity public key, and a hash value of preset information of the chain-down TEE, so that after the node 82n generates the cluster identity information in its own chain-down TEE, the generated cluster identity information is subjected to hash calculation to obtain a third standard hash value, and the third standard hash value is equivalent to simultaneously implementing the functions of the first hash value to be tested and the second standard hash value. In particular, node 82n may provide the client 81 with a remote attestation report, a third standard hash value, and second cluster identity information (which at this point may be understood as identity information to be verified). The second cluster identity information comprises a cluster identity public key, other identity information of the node 82n and a fourth hash value to be verified, wherein the fourth hash value to be verified is a hash value of preset information of the TEE under the link; meanwhile, the second cluster identity information is declared cluster identity information and does not necessarily provide real cluster identity information for the node 82 n. Then, the client 81 performs signature verification on the remote attestation report according to the public key of the authentication server, performs hash calculation on the acquired second cluster identity information to obtain a third hash value to be verified under the condition that the signature verification is passed and the remote authentication result included in the remote attestation report is that the remote authentication result is passed, and compares the third hash value to be verified with a third standard hash value. When the comparison result is consistent, it is described that the second cluster identity information provided by the privacy computing node 82 is the cluster identity information generated in the chain TEE, that is, the fourth hash value to be verified included therein is the hash value of the actual preset information of the chain TEE. Therefore, a fourth standard hash value and a fourth hash value to be checked, which are obtained in advance and are used for the chain TEE preset information, are further compared, and the comparison result is consistent to be used as a precondition for confirming that the chain TEE is credible. Meanwhile, the cluster identity public key included in the second cluster identity information may be determined as the cluster identity public key actually maintained by the privacy computing node 82, and may be used to perform signature verification on the contract information to be verified. The node 82n may send the third standard hash value, the remote attestation report, and the second cluster identity information to the client 81 through the control node 82. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

Similar to the embodiment shown in fig. 7, the cluster remote attestation report and the contract information to be verified are sent from the node 82n to the control node 82, and then forwarded to the client 81 by the control node 82. The control node 82 may provide the cluster remote attestation report and the contract information to be verified to the client 81 at the same time, or may provide the cluster remote attestation report first, and after the client 81 passes verification according to the cluster remote attestation report, obtain the contract information to be verified from the node 82n to provide the contract information to be verified to the client 81. The contract information to be verified is contract information of a target under-chain contract deployed at the node 82n, and the node 82n performs signature in the under-chain TEE of the node 82n by using a cluster identity private key (maintained in the under-chain TEE of the node 82 n). For example, the node 82n reads the target under-chain contract deployed at the node 82n into the under-chain TEE and signs with the cluster identity private key.

The client 81 adopts the cluster identity public key to perform signature verification on the contract information to be verified and performs contract information verification on the contract information to be verified according to the contract information of the target under-link contract under the condition that the under-link TEE is determined to be credible (namely the under-link TEE of the node 82n, the node 82n represents the cluster, and the user cannot sense other nodes in the cluster) according to the cluster remote certification report. Wherein, the cluster identity public key is in a public state, such as the control node 81 publishes the cluster identity public key to the outside for being acquired by the client 81. Alternatively, the client 81 obtains the cluster identity information by the above-mentioned method of verifying the cluster identity information. Meanwhile, contract information of the target down-link contract may also be in a public state, such as the deployment direction of the target down-link contract developing the contract information to be acquired by the client 81. The contract information may include information such as a name, a description, a version number, a bytecode hash value, and a contract identity public key of the linked contract, which is not limited in this specification.

Similar to the principle of verifying the target under-chain contract in the single-node form described above, in the case that the signature verification and contract information verification pass, the client 81 may determine that the client 81 initiated a call to the target under-chain contract through the prolog mechanism of the blockchain node, which was executed by the node 82n in the under-chain TEE trusted execution environment, i.e., ensure that the target under-chain contract deployed in the node 82n is trusted, and may perform the computing task as intended by the user.

It should be noted that, in the form of the down-link privacy computing cluster, each type of remote attestation report may have a certain time limit, such as 30 minutes or other duration, and the remote attestation report that is out of time is determined to be invalid. For example, the remote attestation reports involved in the process of sharing the cluster identity key are all acquired by the nodes from the authentication server control node in real time, and the cluster remote attestation reports can be cached locally by the control node and set the aging duration.

The block chain node updates the block chain ledger data according to the calculation result, or refers to performing uplink on the calculation result, and the method may include: generating a block chain transaction, adding a calculation result to a data field of the transaction, and adding each block chain link point to a block body of a latest block after the block chain transaction passes consensus, so that updating of block chain account data is realized, namely, the uplink of the calculation result is completed; or, the block link point updates the status of the related account according to the calculation result, the related account may be, for example, an external account corresponding to the user or a contract account corresponding to a contract on the chain, the updating of the status of the related account may cause a value change of a root of a status tree (state tree), and the root of the status tree may be included in the block header of the latest block, thereby implementing the updating of the block link book data, that is, linking the calculation result.

The contract under the chain in this specification may implement any computational logic defined by the user. For example, the under-chain contract may be used to verify whether the amount of the encrypted order data stored on the blockchain is correct, and feed back the verification result to the chain; for another example, the under-link contract may be used to perform secure computation on the multi-party data according to a preset algorithm, that is, secure multi-party computation, and feed back the computation result to the link, and so on, which is not described herein any more.

As shown in FIG. 9, assume that client 91 wishes to make a call to a deployed under-chain contract (such as after verifying the target under-chain contract passes). The client 91 may send a call request to the control node 92 through a downlink channel, where the call request is encrypted by using a public key of a cluster identity, and the control node 92 may distribute the call request to a certain downlink privacy computing node in the cluster, such as a node 92n, based on a load balancing algorithm, where the node 92n responds to the call request. The node 92n decrypts the call request by the cluster identity private key in the chain TEE created by itself, and obtains the information of the contract ID, the function name and the parameter data included in the call request. The contract ID may be, for example, a hash of the bytecode of the linked-down contract, so that the node 92n can find the bytecode of the corresponding deployed linked-down contract accordingly. The contract under the chain may contain multiple functions, so the function name may specify the function that the client 91 wishes to call; if the contract under the chain contains only one function, or the client 91 wishes to call all functions in the contract under the chain, the information of the function name may also be omitted from the call request. The information of the entry data may be the entry parameter data itself, or the description information of the entry parameter data, for example, the description information may be a storage address, so that the node 92n may obtain the entry parameter data accordingly, and especially when the client 91 itself is not the data owner, the interaction between the client 91 and the data owner may be omitted, and the data amount of the invocation request may be reduced, and the transmission speed thereof may be increased. Node 92n may then execute the subcohain contracted bytecode in the subcohain TEE to process the inbound parameter data to obtain a corresponding call result. The node 92n may encrypt the call result in the down-link TEE and feed back the call result to the client 91 through the control node 92.

The client 91 may send a call request to the control node 92 through an on-chain channel. The client 91 may submit a contract-down-link call transaction to the blockchain network 93, the contract-down-link call transaction including a call request encrypted by the client 91 using the cluster identity public key. Of course, the contract invoking transaction itself under the link may also be encrypted for transmission, for example, the contract invoking transaction is encrypted by using the public key of the cluster identity, or other encryption methods, which may refer to the content of the data encryption transmission described above, and will not be described herein again. The chain contract invocation transaction may invoke a predictive engine contract such that the predictive engine contract generates a corresponding contract event for the invocation request included in the transaction, which contract event is intercepted by the predictive engine server 94, after which the invocation request is retrieved by the predictive engine server 94 and transmitted to the control node 92. The control node 92 then distributes the invocation request, such as to the down-link privacy computing node 92n, for response. And the control node 92 may feed back the call result to the chain through a prediction mechanism, and the node 93n may initiate a transaction actively and chain the call result, or the node 93n may feed back the call result to the client 91, and the client 91 re-initiates a transaction and chain the call result.

If the import parameter data is blockchain data, the client 91 may submit an encrypted contract-under-chain call transaction to the blockchain network 93, where the contract-under-chain call transaction includes information of the contract ID, the function name, and the import parameter data, and the contract-under-chain call transaction calls an contract-on-chain for acquiring the import parameter data. After receiving the encrypted under-chain contract invoking transaction, the node 93n decrypts the on-chain TEE created by the node 93n, and then executes the invoked on-chain contract through a virtual machine deployed in the on-chain TEE to obtain blockchain data used as the entry parameter data, where the blockchain data is usually in an encrypted state, the node 93n may decrypt the data in the on-chain TEE into a plaintext, and then package the blockchain data of the plaintext and a contract ID and a function name included in the under-chain contract invoking transaction into an invoking request, encrypt the invoking request in the on-chain TEE by using a cluster identity public key, and transmit the invoking request to the control node 92 based on a preplan mechanism, and the control node 92 allocates the invoking request to, for example, the under-chain privacy computing node 92n to respond. And, the control node 92 may feed back the call result to the chain through a prediction mechanism, and the node 93n may chain the call result.

In addition to encrypting the call request using the cluster identity public key, the client 91 or the node 93n may encrypt information of the access data included in the call request using a contract encryption public key. After receiving a call request for a contract under a certain chain, the private computation node 92n decrypts the encrypted information of the access data in the call request by using the contract encryption private key corresponding to the contract under the chain, thereby ensuring that the information of the access data can only be obtained by the called contract under the chain and cannot be obtained by other contracts under the chain. And after obtaining the invocation result (i.e., the execution result obtained by executing the down-chain contract), the down-chain privacy computing node 92n may sign the invocation result through the contract signature private key of the invoked down-chain contract, and the client 91 or the node 93n may verify the invocation through the contract signature public key, thereby determining that the invocation result is indeed generated by the invoked down-chain contract.

In the embodiment shown in fig. 9, the example of the private computation cluster under the chain is described. In fact, the client 91 may also directly interact with a single down-link privacy computing node to invoke a down-link contract deployed on the down-link privacy computing node, which is not described herein again.

It should be noted that, in this specification, the encryption and decryption, the generation of the signature and the verification of the signature may use the same set of key pairs, or configure a set of encryption key pairs and a set of signature key pairs separately. Wherein, in a set of key pairs, there may be multiple public keys and corresponding private keys at the same time, corresponding to different encryption algorithms. In the following, a node identity key is taken as an example, and a cluster identity key and a contract identity key are similar to the node identity key.

In one case, the node identity key is a set of key pairs comprising a node identity public key and a node identity private key. The node identity public key can be used for encrypting data, and then the node identity private key can be used for decrypting the data; the node identity private key can be used for signing data, and then the node identity public key can be used for signature verification of the data. In another case, two sets of key pairs, respectively a node encryption key pair and a node signing key pair, may be configured. The node encryption key pair is used for encrypting and decrypting data, and the node signature key pair is used for signing and verifying signature of the data.

In the embodiment shown in fig. 1, the cluster identity key is shared by any node in the cluster to other nodes, and the sharing process is described from the side of any node. Accordingly, in the embodiment shown in fig. 10, a cluster identity key shared by other nodes is received by any node in the cluster (i.e., the cluster identity key is shared by other nodes to any node), and the sharing process is described from any node side. It should be noted that the description related to the sharing process shown in fig. 1 may also be applied to the sharing process shown in fig. 10, and is not described in detail below.

Referring to fig. 10, fig. 10 is a flowchart illustrating another method for sharing a cluster key according to an exemplary embodiment. As shown in fig. 10, the sharing process may include the steps of:

step 1002, any node in the down-link privacy computing cluster provides a first remote attestation report to other nodes in the down-link privacy computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the any node for the created first down-link trusted execution environment.

A step 1004, in which the any node receives a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, the cluster identity key being generated in a trusted execution environment under the second chain created by the other node, the cluster identity key being used for encrypting, decrypting and/or signing and verifying interactive data in the process that the block link node interacts with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain, and the second remote attestation report being generated by an authentication server after verifying second self-referral information generated by the other node for the trusted execution environment under the second chain.

As previously described, the determining, by the any node, from the second remote attestation report that the second down-chain trusted execution environment is trusted operations comprising: performing signature verification on the second remote attestation report according to the public key of the authentication server; under the condition that the signature verification is passed and the remote authentication result contained in the second remote attestation report is passed, extracting a first hash value to be verified from the second self-recommendation information carried by the second remote attestation report, wherein the first hash value to be verified is the hash value of preset information in the trusted execution environment under the second chain; and comparing a first standard hash value which is obtained in advance and aims at the preset information with the first hash value to be tested, and using the comparison result as a precondition for confirming that the trusted execution environment under the second chain is trusted.

As described above, the any node provides first node identity information to the other nodes, where the first node identity information includes a node identity public key of the any node and other identity information of the any node, and the first identity information is subjected to hash calculation by the other nodes to obtain a second hash value to be verified; the any node provides a second standard hash value to the other nodes, and the second standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates the node identity information of the any node in the first-chain trusted execution environment; and under the condition that the second standard hash value is consistent with the second hash value to be verified, the cluster identity key is signed by other nodes by adopting the node identity private keys of the other nodes, and the signed cluster identity key is encrypted by adopting the node identity public key of any node.

As described above, the any node obtains second node identity information provided by the other nodes, and performs hash calculation on the second node identity information to obtain a third hash value to be verified, where the second node identity information includes the node identity public keys of the other nodes and the other identity information of the other nodes; the any node acquires a third standard hash value provided by the other node, and the third standard hash value is obtained by performing hash calculation on the generated node identity information after the other node generates the node identity information of the other node in the second-chain trusted execution environment; and when the third hash value to be verified and the third standard hash value are consistent, the any node decrypts the received cluster identity key by using the node identity private key of the any node, verifies the signature of the cluster identity key by using the node identity public key contained in the node identity information of the other node, and maintains the cluster identity key in the trusted execution environment under the first chain when the signature verification is passed.

As described above, in the case of receiving the target under-chain contract encrypted by the cluster identity public key in the cluster identity key, decrypting the target under-chain contract by the cluster identity private key in the cluster identity key in the first under-chain trusted execution environment and deploying the target under-chain contract; and under the condition that the block chain link point initiates a call to the target under-chain contract through a predictive machine mechanism, executing the target under-chain contract in the first under-chain trusted execution environment, and feeding back an execution result to the block chain node through the predictive machine mechanism.

As before, before any node receives the encrypted target chain contract, the any node provides the first remote attestation report to a signing party in response to a challenge initiated by the signing party of the target chain contract; wherein the encrypted target under-chain contract is sent by the signing party if the first under-chain trusted execution environment is determined to be trusted based on the first remote attestation report.

As described above, before feeding back the execution result to the block chain link point through the preplan mechanism, the any node signs the execution result in the first-chain lower trusted execution environment with the contract identity private key in the contract identity key of the target-chain lower contract, and the signed execution result is determined to be generated by the target-chain lower contract when the execution result is signature-verified with the contract identity public key in the contract identity key and passes the signature verification.

As previously mentioned, the operation of the any node to generate a contract identity key for the target linked contract comprises: generating the contract identity key based on the cluster identity key and the global identification information of the target under-chain contract by adopting a key generation algorithm shared among all nodes in the under-chain private computing cluster in the first under-chain trusted execution environment; wherein the target down-chain contract is deployed at each node in the down-chain privacy computing cluster.

As described above, before a block link point initiates a call to the target under-chain contract through a prediction mechanism, the any node provides the cluster remote attestation report to a challenger of the target under-chain contract, and the cluster remote attestation report is generated after an authentication server verifies the first self-referral information; providing to the challenger contract information to be verified for the target under-chain contract deployed at the any node, the contract information to be verified being signed by the any node within the first under-chain trusted execution environment using a cluster identity private key of the cluster identity keys; and under the condition that the challenger determines that the trusted execution environment under the first chain is trusted according to the cluster remote attestation report, the contract information to be verified is subjected to signature verification by adopting a cluster identity public key in the cluster identity key, the contract information to be verified is subjected to contract information verification according to the contract information of the contract under the target chain, and under the condition that the signature verification and the contract information verification pass, when the challenger is determined to initiate calling on the contract under the target chain through a prompter mechanism of a block chain node, the contract under the target chain is executed by any node in the trusted execution environment under the first chain.

As mentioned above, the first self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, where the fourth hash value to be verified is a hash value of the preset information of the trusted execution environment under the first chain, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is that the remote authentication result passes authentication, the comparison result is compared with a fourth standard hash value, which is obtained in advance and is used as a precondition for the challenger to confirm that the trusted execution environment under the first chain is trusted.

As described above, the any node provides cluster identity information to the challenger, the cluster identity information includes a cluster identity public key in a cluster identity key and other identity information except the node identity public key of the any node in the node identity information of the any node, and the cluster identity information is subjected to hash calculation by the challenger to obtain a fifth hash value to be verified; the any node provides a fifth standard hash value to the challenger, and the fifth standard hash value is obtained by performing hash calculation on the cluster identity information after the any node generates the cluster identity information in the first-chain trusted execution environment; and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the challenger acquires the cluster identity public key contained in the cluster identity information under the condition that the comparison result is consistent.

As described previously, the challenger initiates a challenge after each node in the down-chain privacy computing cluster deploys the target down-chain contract, and the initiated challenge is received by a control node of the down-chain privacy computing cluster and forwarded to the any node.

As described above, the any node receiving blockchain node receives, through a preplan mechanism, a call transaction initiated by the target link contract, where the call transaction is encrypted with a cluster identity public key in the cluster identity key, and the call transaction is received by a control node of the link privacy computation cluster and forwarded to the any node according to a load condition of the link privacy computation cluster; and decrypting the call transaction by adopting the cluster identity private key in the cluster identity key in the first-chain trusted execution environment so as to respond to the decrypted call transaction to execute the target-chain contract.

Step 1006, the any node approves the cluster identity key if it is determined that the second remote attestation report indicates that the second down-chain trusted execution environment is trusted.

As previously described, the cluster identity key is approved by any node upon determining that the second remote attestation report indicates that the trusted execution environment in the second chain is trusted, thereby maintaining the cluster identity key within its trusted execution environment in the first chain.

In the technical scheme of the specification, the client can directly interact with the privacy computing node to complete operations of deploying the intelligent contract on the privacy computing node, initiating a challenge to the intelligent contract, verifying the intelligent contract, calling the intelligent contract and the like, the operations are not required to be completed through a preplanning machine mechanism of the block chain, and meanwhile, a computing result obtained by calling the intelligent contract deployed on the privacy computing node is not required to be fed back to the block chain. In this case, since no distinction between on-chain and off-chain is involved, "private computation node under chain" will be referred to as "private computation node", private computation cluster under chain "will be referred to as" private computation cluster ", trusted execution environment under chain" will be referred to as "trusted execution environment", and contract under chain "will be referred to as" intelligent contract "hereinafter. However, the principle of the technical solution is similar to the above embodiments, and the implementation details can be referred to the above embodiments, so that the detailed description is not repeated below.

Accordingly, FIG. 11 is a flow chart of another method for sharing a cluster key in accordance with an illustrative embodiment. As shown in fig. 11, the method may include the steps of:

step 1102, any node in a private computing cluster acquires a first remote attestation report sent by other nodes in the private computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other nodes for a created first trusted execution environment.

As described above, the any node performs signature verification on the first remote attestation report according to the public key of the authentication server; under the condition that the signature verification is passed and the remote authentication result contained in the first remote attestation report is passed, extracting a first hash value to be verified from the first self-recommendation information carried by the first remote attestation report, wherein the first hash value to be verified is the hash value of preset information in the first trusted execution environment; and comparing a first standard hash value which is obtained in advance and aims at preset information in the first trusted execution environment with the first hash value to be verified, and taking the comparison result as a precondition for confirming that the first trusted execution environment is trusted.

And 1104, the any node acquires a cluster identity key corresponding to the privacy computing cluster, the cluster identity key is generated in a second trusted execution environment created by the any node, and the cluster identity key is used for encrypting and decrypting the interactive data and/or signing and checking the signature during the process that the client interacts with each node in the privacy computing cluster to deploy or invoke the smart contract.

Step 1106, in a case that the any node determines that the first trusted execution environment is trusted according to the first remote attestation report, the any node sends the cluster identity key and a second remote attestation report to the other node, in a case that the second remote attestation report indicates that the second trusted execution environment is trusted, the cluster identity key is approved by the other node, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node for the second trusted execution environment.

As described above, the any node obtains the first node identity information provided by the other nodes, and performs hash calculation on the obtained first node identity information to obtain a second hash value to be verified, where the first node identity information includes the node identity public keys of the other nodes and the other identity information of the other nodes;

acquiring a second standard hash value provided by the other node, wherein the second standard hash value is obtained by performing hash calculation on the generated node identity information after the other node generates own node identity information in the first trusted execution environment;

Comparing the second hash value to be verified with the second standard hash value, and acquiring a node identity public key contained in the node identity information of the other node under the condition that the comparison result is consistent;

and signing the cluster identity key by adopting the node identity private key of any node, and encrypting the signed cluster identity key by adopting the node identity public keys of other nodes.

As described above, the any node provides second node identity information to the other nodes, where the second node identity information includes a node identity public key of the any node and other identity information of the any node;

the any node provides a third standard hash value to the other nodes, and the third standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates the node identity information of the any node in the second trusted execution environment;

and under the condition that a third hash value to be verified obtained by performing hash calculation on the second node identity information is consistent with the third standard hash value, the other nodes decrypt the received cluster identity key by using the node identity private key of the other nodes, verify the signature of the cluster identity key by using the node identity public key contained in the node identity information of any node, and maintain the cluster identity key in the first trusted execution environment under the condition that the signature verification is passed.

As described above, in the case that the any node receives the target smart contract encrypted by the cluster identity public key in the cluster identity key, decrypting the target smart contract by the cluster identity private key in the cluster identity key in the second trusted execution environment and deploying the target smart contract;

and under the condition that the client initiates call to the target intelligent contract, executing the target intelligent contract in the second trusted execution environment, and feeding back an execution result to the client.

As previously mentioned, said any node providing said second remote attestation report to a signing party of said target intelligent contract in response to a challenge initiated by said signing party;

wherein the encrypted target smart contract is sent by the signing party with the second trusted execution environment being trusted as determined from the second remote attestation report.

As described above, the any node signs the execution result in the second trusted execution environment by using the contract identity private key in the contract identity key of the target smart contract, and the signed execution result is determined to be generated by the target smart contract when the execution result is subjected to signature verification by using the contract identity public key in the contract identity key and passes the signature verification.

As previously mentioned, the operation of generating the contract identity key for the target smart contract includes:

generating the contract identity key based on the cluster identity key and the global identification information of the target intelligent contract by adopting a key generation algorithm shared among all nodes in the private computing cluster in the second trusted execution environment;

wherein the target smart contracts are deployed at respective nodes in the private computing cluster.

As described above, before the client initiates a call to the target smart contract, the any node provides the cluster remote attestation report to the challenger of the target smart contract, where the cluster remote attestation report is generated by an authentication server after verifying the second self-referral information;

providing to the challenger contract information to be verified of the target smart contract deployed at the any node, the contract information to be verified being signed by the any node within the second trusted execution environment with a cluster identity private key of the cluster identity keys, the cluster identity private key of the cluster identity keys being maintained by the any node within the second trusted execution environment;

And under the condition that the challenger determines that the second trusted execution environment is trusted according to the cluster remote attestation report, the challenger adopts a cluster identity public key in the cluster identity key to sign and verify the contract information to be verified, the challenger verifies the contract information to be verified according to the contract information of the target intelligent contract, and under the condition that the signature verification and the contract information verification pass, the challenger determines that the target intelligent contract is executed in the second trusted execution environment by any node when the challenger initiates calling on the target intelligent contract through a language predicting mechanism of a block chain node.

As mentioned above, the second self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, where the fourth hash value to be verified is a hash value of the preset information of the second trusted execution environment, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is that the remote authentication result passes authentication, the comparison result is compared with a fourth standard hash value, which is obtained in advance and is used as a precondition for the challenger to confirm that the second trusted execution environment is trusted.

As mentioned above, the method further comprises:

the any node provides cluster identity information to the challenger, the cluster identity information comprises a cluster identity public key in a cluster identity key and other identity information except the node identity public key of the any node in the node identity information of the any node, and the cluster identity information is subjected to hash calculation by the challenger to obtain a fifth hash value to be verified;

the any node provides a fifth standard hash value to the challenger, and the fifth standard hash value is obtained by performing hash calculation on the cluster identity information after the any node generates the cluster identity information in the second trusted execution environment;

and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the challenger acquires the cluster identity public key contained in the cluster identity information under the condition that the comparison result is consistent.

As described above, the any node receives a call transaction initiated by the client to the target smart contract, the call transaction is encrypted by using a cluster identity public key in the cluster identity key, the call transaction is received by the control node of the privacy computation cluster and forwarded to the any node according to the load condition of the privacy computation cluster;

And decrypting the calling transaction by adopting the cluster identity private key in the cluster identity key in the second trusted execution environment so as to respond to the decrypted calling transaction to execute the target intelligent contract.

Accordingly, FIG. 12 is a flow chart of another method for sharing a cluster key provided by an example embodiment. As shown in fig. 12, the method may include the steps of:

step 1202, any node in a private computing cluster provides a first remote attestation report to other nodes in the private computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the any node for a created first trusted execution environment.

As previously described, the operation of the any node determining that the second trusted execution environment is trusted based on the second remote attestation report includes:

performing signature verification on the second remote attestation report according to the public key of the authentication server;

under the condition that the signature verification is passed and the remote authentication result contained in the second remote attestation report is passed, extracting a first hash value to be verified from the second self-referral information carried by the second remote attestation report, wherein the first hash value to be verified is the hash value of preset information in the second trusted execution environment;

And comparing a first standard hash value which is obtained in advance and aims at preset information in the second trusted execution environment with the first hash value to be verified, and taking the comparison result as a precondition for confirming that the second trusted execution environment is trusted.

Step 1204, the any node receives a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster under the condition that the first trusted execution environment is determined to be trusted according to the first remote attestation report, where the cluster identity key is generated in a second trusted execution environment created by the other node, the cluster identity key is used for encrypting, decrypting and/or signing and checking interaction data in the process that a client interacts with each node in the private computing cluster to deploy or invoke a smart contract, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the other node for the second trusted execution environment.

At step 1206, the any node approves the cluster identity key if it is determined that the second remote attestation report indicates that the second trusted execution environment is trusted.

As described above, the any node provides first node identity information to the other nodes, where the first node identity information includes a node identity public key of the any node and other identity information of the any node, and the first identity information is subjected to hash calculation by the other nodes to obtain a second hash value to be verified;

the any node provides a second standard hash value to the other nodes, and the second standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates the node identity information of the any node in the first trusted execution environment;

and under the condition that the second standard hash value is consistent with the second hash value to be verified, the cluster identity key is signed by other nodes by adopting the node identity private keys of the other nodes, and the signed cluster identity key is encrypted by adopting the node identity public key of any node.

As described above, the any node obtains second node identity information provided by the other nodes, and performs hash calculation on the second node identity information to obtain a third hash value to be verified, where the second node identity information includes the node identity public keys of the other nodes and the other identity information of the other nodes;

The any node acquires a third standard hash value provided by the other node, wherein the third standard hash value is obtained by performing hash calculation on generated node identity information after the other node generates own node identity information in the second trusted execution environment;

and when the third hash value to be verified and the third standard hash value are consistent, the any node decrypts the received cluster identity key by using the node identity private key of the any node, verifies the signature of the cluster identity key by using the node identity public key contained in the node identity information of the other node, and maintains the cluster identity key in the first trusted execution environment when the signature verification is passed.

As described above, in the case that the any node receives the target smart contract encrypted by the cluster identity public key in the cluster identity key, decrypting the target smart contract by the cluster identity private key in the cluster identity key in the first trusted execution environment and deploying the target smart contract;

and under the condition that the client initiates call to the target intelligent contract, executing the target intelligent contract in the first trusted execution environment, and feeding back an execution result to the client.

As described above, said any node, prior to receiving said encrypted target intelligent contract, provides said first remote attestation report to a signing party of said target intelligent contract in response to a challenge initiated by said signing party;

wherein the encrypted target smart contract is sent by the signing party with the first trusted execution environment being trusted as determined from the first remote attestation report.

As described above, before feeding back the execution result to the client, the any node signs the execution result in the first trusted execution environment with the contract identity private key in the contract identity key of the target smart contract, and the signed execution result is determined to be generated by the target smart contract when the execution result is signature-verified with the contract identity public key in the contract identity key and passes the signature verification.

As previously mentioned, the operation of the any node to generate the contract identity key for the target smart contract comprises:

generating the contract identity key based on the cluster identity key and the global identification information of the target intelligent contract by adopting a key generation algorithm shared among all nodes in the private computing cluster in the first trusted execution environment;

As described above, before the client initiates a call to the target smart contract, the any node provides the cluster remote attestation report to the challenger of the target smart contract, where the cluster remote attestation report is generated by an authentication server after verifying the first self-referral information;

providing to the challenger contract information to be verified of the target smart contract deployed at the any node, the contract information to be verified being signed by the any node within the first trusted execution environment with a cluster identity private key of the cluster identity keys;

and under the condition that the challenger determines that the first trusted execution environment is trusted according to the cluster remote attestation report, the challenger performs signature verification on the contract information to be verified by adopting a cluster identity public key in the cluster identity key, performs contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and under the condition that the signature verification and the contract information verification pass, determines that the challenger executes the target intelligent contract in the first trusted execution environment by any node when invoking the target intelligent contract through a language predicting mechanism of a block chain node.

As mentioned above, the first self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, where the fourth hash value to be verified is a hash value of the preset information of the first trusted execution environment, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is that the remote authentication result passes authentication, the comparison result is compared with a fourth standard hash value, which is obtained in advance and is used as a precondition for the challenger to confirm that the first trusted execution environment is trusted.

As described above, the any node provides cluster identity information to the challenger, the cluster identity information includes a cluster identity public key in a cluster identity key and other identity information except the node identity public key of the any node in the node identity information of the any node, and the cluster identity information is subjected to hash calculation by the challenger to obtain a fifth hash value to be verified;

The any node provides a fifth standard hash value to the challenger, and the fifth standard hash value is obtained by performing hash calculation on the cluster identity information after the any node generates the cluster identity information in the first trusted execution environment;

and decrypting the calling transaction by adopting a cluster identity private key in the cluster identity key in the first trusted execution environment so as to respond to the decrypted calling transaction to execute the target intelligent contract.

It should be noted that, the specific process for sharing the cluster identity key may refer to the embodiment shown in fig. 1, and is not described in detail below.

Corresponding to the above method embodiments, the present specification also provides embodiments of an apparatus for sharing a cluster key.

The embodiment of the apparatus for sharing a cluster key in this specification can be applied to an electronic device. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

Referring to fig. 13 from a hardware level, fig. 13 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 13, at the hardware level, the device includes a processor 1302, an internal bus 1304, a network interface 1306, a memory 1308, and a non-volatile storage 1310, although other hardware required for service may be included. The processor 1302 reads a corresponding computer program from the non-volatile storage 1310 into the memory 1308 and then runs, thereby forming a device sharing a cluster key at a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

In an embodiment, referring to fig. 14, in a software implementation, the apparatus for sharing a cluster key may include:

a report obtaining unit 1401, configured to enable any node in the private computing cluster to obtain a first remote attestation report sent by another node in the private computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the another node for a created first private execution environment under the chain;

a key obtaining unit 1402, configured to enable the any node to obtain a cluster identity key corresponding to the private computing cluster under the chain, where the cluster identity key is generated in a second trusted execution environment created by the any node, and the cluster identity key is used for encrypting and decrypting interaction data and/or signing and verifying a signature during a process of interacting between a block link node and each node in the private computing cluster under the chain to deploy or invoke a contract under the chain;

a sending unit 1403, which causes the any node to send, to the other node, the cluster identity key and a second remote attestation report in a case where it is determined from the first remote attestation report that the trusted execution environment in the first chain is trusted, where the cluster identity key is approved by the other node in a case where the second remote attestation report indicates that the trusted execution environment in the second chain is trusted, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node for the trusted execution environment in the second chain.

Optionally, the report obtaining unit 1401 is specifically configured to:

performing signature verification on the first remote attestation report according to the public key of the authentication server;

under the condition that signature verification is passed and a remote authentication result contained in the first remote attestation report is authenticated, extracting a first hash value to be verified from the first self-referral information carried by the first remote attestation report, wherein the first hash value to be verified is a hash value of preset information in the first chain lower trusted execution environment;

and comparing a first standard hash value which is obtained in advance and aims at preset information in the trusted execution environment under the first chain with the first hash value to be verified, and using the comparison result as a precondition for confirming that the trusted execution environment under the first chain is trusted.

Optionally, before the any node sends the cluster identity key to the other node, the sending unit 1403 is specifically configured to:

acquiring first node identity information provided by other nodes, and performing hash calculation on the acquired first node identity information to obtain a second hash value to be verified, wherein the first node identity information comprises node identity public keys of the other nodes and other identity information of the other nodes;

Acquiring a second standard hash value provided by the other node, wherein the second standard hash value is obtained by performing hash calculation on generated node identity information after the other node generates own node identity information in the first-chain trusted execution environment;

Optionally, the sending unit 1403 is specifically configured to:

the any node provides second node identity information to the other nodes, wherein the second node identity information comprises a node identity public key of the any node and other identity information of the any node;

the any node provides a third standard hash value to the other nodes, and the third standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates the node identity information of the any node in the second-chain trusted execution environment;

And under the condition that a third hash value to be verified obtained by performing hash calculation on the second node identity information is consistent with the third standard hash value, the other nodes decrypt the received cluster identity key by using the node identity private key of the other nodes, verify the signature of the cluster identity key by using the node identity public key contained in the node identity information of any node, and maintain the cluster identity key in the trusted execution environment under the first chain under the condition that the signature verification is passed.

Optionally, the sending unit 1403 is specifically configured to:

decrypting and deploying the target under-chain contract through a cluster identity private key in the cluster identity key in the second under-chain trusted execution environment under the condition that the target under-chain contract encrypted by the cluster identity public key in the cluster identity key is received;

and under the condition that the block chain link point initiates a call to the target under-chain contract through a prediction machine mechanism, executing the target under-chain contract in the second under-chain trusted execution environment, and feeding back an execution result to the block chain node through the prediction machine mechanism.

Optionally, before any node receives the encrypted target downlink contract, the sending unit 1403 is further configured to:

providing the second remote attestation report to a signing party of the target under-chain contract in response to a challenge initiated by the signing party;

wherein the encrypted target under-chain contract is sent by the signing party if the second under-chain trusted execution environment is determined to be trusted based on the second remote attestation report.

Optionally, before any node feeds back the execution result to the block link point through the predictive engine mechanism, the sending unit 1403 is specifically configured to:

and signing the execution result by adopting a contract identity private key in a contract identity key of the contract under the target chain in the trusted execution environment under the second chain, wherein the signed execution result is judged to be generated by the contract under the target chain under the condition that the execution result is subjected to signature verification by adopting a contract identity public key in the contract identity key and passes the signature verification.

Optionally, the operation of generating a contract identity key of the target linked contract includes:

generating the contract identity key based on the cluster identity key and the global identification information of the target under-chain contract by adopting a key generation algorithm shared among all nodes in the under-chain private computing cluster in the second under-chain trusted execution environment;

Wherein the target down-chain contract is deployed at each node in the down-chain privacy computing cluster.

Optionally, before the block link point initiates an invocation to the target link contract through a prediction machine mechanism, the sending unit 1403 is specifically configured to:

the any node provides the cluster remote attestation report to a challenger of the target linked contract, wherein the cluster remote attestation report is generated after the second self-referral information is verified by an authentication server;

providing, to the challenger, contract information to be verified for contract under the target chain deployed at the any node, the contract information to be verified being signed by the any node within the second chain trusted execution environment with a cluster identity private key of the cluster identity key, the cluster identity private key of the cluster identity key being maintained by the any node within the second chain trusted execution environment;

and under the condition that the challenger determines that the trusted execution environment under the second chain is trusted according to the cluster remote attestation report, the contract information to be verified is subjected to signature verification by adopting a cluster identity public key in the cluster identity key, the contract information to be verified is subjected to contract information verification according to the contract information of the contract under the target chain, and under the condition that the signature verification and the contract information verification pass, when the challenger is determined to initiate calling on the contract under the target chain through a prompter mechanism of a block chain node, the contract under the target chain is executed by any node in the trusted execution environment under the second chain.

Optionally, the second self-referral information carried by the cluster remote attestation report includes a fourth hash value to be verified, the fourth hash value to be verified is a hash value of the preset information of the trusted execution environment under the second chain, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is authenticated, the comparison result is compared with a fourth standard hash value which is obtained in advance and is used as a precondition that the challenger confirms that the trusted execution environment under the second chain is trusted.

Optionally, the sending unit 1403 is specifically configured to:

The any node provides a fifth standard hash value to the challenger, and the fifth standard hash value is obtained by performing hash calculation on the cluster identity information after the any node generates the cluster identity information in the second-chain trusted execution environment;

Optionally, the challenger initiates a challenge after each node in the down-chain privacy computing cluster deploys the target down-chain contract, and the initiated challenge is received by the control node of the down-chain privacy computing cluster and forwarded to the any node.

Optionally, the sending unit 1403 is specifically configured to:

receiving a calling transaction initiated by a block chain node through a preplan mechanism, wherein the calling transaction is encrypted by a cluster identity public key in the cluster identity key, and the calling transaction is received by a control node of the down-chain privacy computation cluster and forwarded to any node according to the load condition of the down-chain privacy computation cluster;

And decrypting the call transaction by adopting the cluster identity private key in the cluster identity key in the second-chain trusted execution environment so as to respond to the decrypted call transaction to execute the target-chain contract.

In an embodiment, referring to fig. 15, in a software implementation, the apparatus for sharing a cluster key may include:

a report providing unit 1501, configured to enable any node in the private computing cluster to provide a first remote attestation report to other nodes in the private computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the any node for a created first linked trusted execution environment;

a receiving unit 1502 enabling the any node to receive a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, wherein the cluster identity key is generated in the trusted execution environment under the second chain created by the other node, the cluster identity key is used for encrypting, decrypting and/or signing and verifying interaction data in the process that block chain links interact with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the other node for the trusted execution environment under the second chain;

Processing unit 1503 causes the any node to approve the cluster identity key if it is determined that the second remote attestation report indicates that the second down-chain trusted execution environment is trusted.

Optionally, the report providing unit 1501 is specifically configured to:

under the condition that the signature verification is passed and the remote authentication result contained in the second remote attestation report is passed, extracting a first hash value to be verified from the second self-recommendation information carried by the second remote attestation report, wherein the first hash value to be verified is the hash value of preset information in the trusted execution environment under the second chain;

and comparing a first standard hash value which is obtained in advance and aims at preset information in the trusted execution environment under the second chain with the first hash value to be verified, and using the comparison result as a precondition for confirming that the trusted execution environment under the second chain is trusted.

Optionally, the report providing unit 1501 is specifically configured to:

the any node provides first node identity information to the other nodes, the first node identity information comprises a node identity public key of the any node and other identity information of the any node, and the first identity information is subjected to hash calculation by the other nodes to obtain a second hash value to be verified;

The any node provides a second standard hash value to the other nodes, and the second standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates the node identity information of the any node in the first-chain trusted execution environment;

Optionally, the report providing unit 1501 is specifically configured to:

the any node acquires second node identity information provided by other nodes, and performs hash calculation on the second node identity information to obtain a third hash value to be verified, wherein the second node identity information comprises node identity public keys of other nodes and other identity information of other nodes;

the any node acquires a third standard hash value provided by the other node, and the third standard hash value is obtained by performing hash calculation on the generated node identity information after the other node generates the node identity information of the other node in the second-chain trusted execution environment;

And when the third hash value to be verified and the third standard hash value are consistent, the any node decrypts the received cluster identity key by using the node identity private key of the any node, verifies the signature of the cluster identity key by using the node identity public key contained in the node identity information of the other node, and maintains the cluster identity key in the trusted execution environment under the first chain when the signature verification is passed.

Optionally, the processing unit 1503 is further configured to:

decrypting and deploying the target under-chain contract through a cluster identity private key in the cluster identity key in the first under-chain trusted execution environment under the condition that the target under-chain contract encrypted by the cluster identity public key in the cluster identity key is received;

and under the condition that the block chain link point initiates a call to the target under-chain contract through a prediction machine mechanism, executing the target under-chain contract in the first under-chain trusted execution environment, and feeding back an execution result to the block chain node through the prediction machine mechanism.

Optionally, before receiving the encrypted target-chain contract, the processing unit 1503 is further configured to:

Causing said any node to provide said first remote attestation report to said deployer in response to a challenge initiated by a deployer of said target subcohain contract;

wherein the encrypted target under-chain contract is sent by the signing party if the first under-chain trusted execution environment is determined to be trusted based on the first remote attestation report.

Optionally, before the execution result is fed back to the block link point through the prediction machine mechanism, the processing unit 1503 is further configured to:

and enabling any node to sign the execution result by adopting a contract identity private key in a contract identity key of the target down-link contract in the first down-link trusted execution environment, wherein the signed execution result is judged to be generated by the target down-link contract under the condition that the execution result is subjected to signature verification by adopting a contract identity public key in the contract identity key and passes the signature verification.

Optionally, the operation of generating, by any node, a contract identity key of the target linked contract includes:

generating the contract identity key based on the cluster identity key and the global identification information of the target under-chain contract by adopting a key generation algorithm shared among all nodes in the under-chain private computing cluster in the first under-chain trusted execution environment;

Optionally, before the block link point initiates a call to the target under-link contract through a prediction machine mechanism, the report providing unit 1501 is further configured to:

the any node provides the cluster remote attestation report to a challenger of the target down-link contract, wherein the cluster remote attestation report is generated after the first self-referral information is verified by an authentication server;

providing, to the challenger, contract information to be verified for the target down-chain contract deployed at the any node, the contract information to be verified being signed by the any node within the first down-chain trusted execution environment with a cluster identity private key of the cluster identity keys;

and under the condition that the challenger determines that the trusted execution environment under the first chain is trusted according to the cluster remote attestation report, the contract information to be verified is subjected to signature verification by adopting a cluster identity public key in the cluster identity key, the contract information to be verified is subjected to contract information verification according to the contract information of the contract under the target chain, and under the condition that the signature verification and the contract information verification pass, when the challenger is determined to initiate calling on the contract under the target chain through a prompter mechanism of a block chain node, the contract under the target chain is executed by any node in the trusted execution environment under the first chain.

Optionally, the first self-referral information carried by the cluster remote attestation report includes a fourth hash value to be verified, the fourth hash value to be verified is a hash value of the preset information of the first-chain lower trusted execution environment, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is authenticated, the comparison result is compared with a fourth standard hash value which is obtained in advance and is used as a precondition for the challenger to confirm that the first-chain lower trusted execution environment is trusted.

Optionally, the report providing unit 1501 is further configured to:

The any node provides a fifth standard hash value to the challenger, and the fifth standard hash value is obtained by performing hash calculation on the cluster identity information after the any node generates the cluster identity information in the first-chain trusted execution environment;

Optionally, the receiving unit 1502 is further configured to:

And decrypting the call transaction by adopting the cluster identity private key in the cluster identity key in the first-chain trusted execution environment so as to respond to the decrypted call transaction to execute the target-chain contract.

In an embodiment, referring to fig. 16, in a software implementation, the apparatus for sharing a cluster key may include:

a report obtaining unit 1601, configured to enable any node in a private computing cluster to obtain a first remote attestation report sent by another node in the private computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the another node for a created first trusted execution environment;

a key obtaining unit 1602, configured to enable the any node to obtain a cluster identity key corresponding to the private computing cluster, where the cluster identity key is generated in a second trusted execution environment created by the any node, and the cluster identity key is used to encrypt and decrypt interaction data and/or sign and verify a signature during a process in which a client interacts with each node in the private computing cluster to deploy or invoke a smart contract;

a sending unit 1603, which causes the any node to send the cluster identity key and a second remote attestation report to the other node if it is determined that the first trusted execution environment is trusted according to the first remote attestation report, where the cluster identity key is approved by the other node if the second remote attestation report indicates that the second trusted execution environment is trusted, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node for the second trusted execution environment.

Optionally, the report acquiring unit 1601 is specifically configured to:

under the condition that the signature verification is passed and the remote authentication result contained in the first remote attestation report is passed, extracting a first hash value to be verified from the first self-referral information carried by the first remote attestation report, wherein the first hash value to be verified is the hash value of preset information in the first trusted execution environment;

and comparing a first standard hash value which is obtained in advance and aims at preset information in the first trusted execution environment with the first hash value to be verified, and taking the comparison result as a precondition for confirming that the first trusted execution environment is trusted.

Optionally, before the any node sends the cluster identity key to the other node, the sending unit 1603 is further configured to:

enabling any node to acquire first node identity information provided by other nodes, and performing hash calculation on the acquired first node identity information to obtain a second hash value to be verified, wherein the first node identity information comprises node identity public keys of other nodes and other identity information of other nodes;

Optionally, the sending unit 1603 is specifically configured to:

in the case of receiving a target intelligent contract encrypted by a cluster identity public key in the cluster identity key, decrypting the target intelligent contract by the cluster identity private key in the cluster identity key in the second trusted execution environment and deploying the target intelligent contract;

Optionally, before any node receives the encrypted target smart contract, the sending unit 1603 is further configured to:

Causing said any node to provide said second remote attestation report to a deployer of said target intelligent contract in response to a challenge initiated by said deployer;

Optionally, before the any node feeds back the execution result to the client, the sending unit 1603 is further configured to:

and enabling any node to sign the execution result by using a contract identity private key in a contract identity key of the target intelligent contract in the second trusted execution environment, wherein the signed execution result is judged to be generated by the target intelligent contract when the execution result is subjected to signature verification by using a contract identity public key in the contract identity key and passes the signature verification.

Optionally, the operation of generating the contract identity key of the target smart contract includes:

Optionally, before the client initiates a call to the target smart contract, the sending unit 1603 is further configured to:

causing said any node to provide said cluster remote attestation report to a challenger of said target intelligent contract, said cluster remote attestation report generated by an authentication server after verification of said second self-referral information;

Optionally, the second self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, where the fourth hash value to be verified is a hash value of the preset information of the second trusted execution environment, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when a remote authentication result included in the cluster remote attestation report is that the remote authentication result passes authentication, the cluster remote attestation report is compared with a fourth standard hash value, which is obtained in advance and is used for the challenger to confirm that the second trusted execution environment is trusted, and the comparison result is consistent and is used as a precondition for the challenger to confirm that the second trusted execution environment is trusted.

Optionally, the sending unit 1603 is further configured to:

enabling any node to provide cluster identity information to the challenger, wherein the cluster identity information comprises a cluster identity public key in a cluster identity key and other identity information except the node identity public key of any node in the node identity information of any node, and the cluster identity information is subjected to hash calculation by the challenger to obtain a fifth hash value to be verified;

Optionally, the sending unit 1603 is further configured to:

receiving a call transaction initiated by the client to the target intelligent contract, wherein the call transaction is encrypted by a cluster identity public key in the cluster identity key, and the call transaction is received by a control node of the privacy computing cluster and forwarded to any node according to the load condition of the privacy computing cluster;

In an embodiment, referring to fig. 17, in a software implementation, the apparatus for sharing a cluster key may include:

A report providing unit 1701, configured to enable any node in the private computing cluster to provide a first remote attestation report to other nodes in the private computing cluster, where the first remote attestation report is generated by an authentication server after verification of first self-referral information generated by the any node for a created first trusted execution environment;

a receiving unit 1702, configured to cause the any node to receive a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster if it is determined that the first trusted execution environment is trusted according to the first remote attestation report, where the cluster identity key is generated in a second trusted execution environment created by the other node, and is used for encrypting, decrypting, and/or signing an authentication signature on interaction data during a process of a client interacting with each node in the private computing cluster to deploy or invoke a smart contract, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the other node for the second trusted execution environment;

processing unit 1703 causes the any node to approve the cluster identity key if it is determined that the second remote attestation report indicates that the second trusted execution environment is trusted.

Optionally, the determining, by the any node, that the second trusted execution environment is trusted according to the second remote attestation report includes:

Optionally, the report providing unit 1701 is further configured to:

Optionally, the processing unit 1703 is further configured to:

in the case of receiving a target intelligent contract encrypted by a cluster identity public key in the cluster identity key, decrypting the target intelligent contract by a cluster identity private key in the cluster identity key in the first trusted execution environment and deploying the target intelligent contract;

Optionally, before receiving the encrypted target smart contract, the report providing unit 1701 is further configured to:

causing said any node to provide said first remote attestation report to a party to said target intelligent contract in response to a challenge initiated by said party;

Wherein the encrypted target smart contract is sent by the signer upon determining that the first trusted execution environment is trusted based on the first remote attestation report.

Optionally, before feeding back the execution result to the client, the processing unit 1703 is further configured to:

and enabling any node to sign the execution result by adopting a contract identity private key in a contract identity key of the target intelligent contract in the first trusted execution environment, wherein the signed execution result is judged to be generated by the target intelligent contract when the execution result is subjected to signature verification by adopting a contract identity public key in the contract identity key and passes the signature verification.

Optionally, the operation of generating, by any node, a contract identity key of the target smart contract includes:

Optionally, before the client initiates a call to the target smart contract, processing unit 1703 is further configured to:

the any node provides the cluster remote attestation report to a challenger of the target intelligent contract, and the cluster remote attestation report is generated after the first self-referral information is verified by an authentication server;

Optionally, the first self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, where the fourth hash value to be verified is a hash value of the preset information of the first trusted execution environment, the fourth hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when a remote authentication result included in the cluster remote attestation report is that the remote authentication result passes authentication, the cluster remote attestation report is compared with a fourth standard hash value, which is obtained in advance and is used for the challenger to confirm that the first trusted execution environment is trusted, and the comparison result is consistent and is used as a precondition for the challenger to confirm that the first trusted execution environment is trusted.

Optionally, the processing unit 1703 is further configured to:

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A method of sharing a cluster key, comprising:

the method comprises the steps that any node obtains a cluster identity key corresponding to the private computing cluster under the chain, the cluster identity key is generated in a trusted execution environment under a second chain created by the any node, and the cluster identity key is used for encrypting and decrypting interaction data and/or signing and checking a signature in the process that block chain nodes interact with each node in the private computing cluster under the chain to deploy or call a target contract under the chain;

And the any node sends the cluster identity key and a second remote attestation report to the other nodes under the condition that the trusted execution environment under the first chain is determined to be trusted according to the first remote attestation report, the cluster identity key is approved by the other nodes under the condition that the second remote attestation report indicates that the trusted execution environment under the second chain is trusted, and the second remote attestation report is generated after an authentication server verifies second self-referral information generated by the any node aiming at the trusted execution environment under the second chain.

2. The method of claim 1, the operation of the any node determining from the first remote attestation report that the first off-chain trusted execution environment is trusted comprising:

3. The method of claim 1, further comprising:

before the cluster identity key is sent to the other nodes by any node, acquiring first node identity information provided by the other nodes, and performing hash calculation on the acquired first node identity information to obtain a second hash value to be verified, wherein the first node identity information comprises node identity public keys of the other nodes;

4. The method of claim 3, further comprising:

the any node provides second node identity information to the other nodes, wherein the second node identity information comprises a node identity public key of the any node;

5. The method of claim 1, further comprising:

the any node acquires a calling request, read by a predictive engine server, for the target down-link contract from the monitored contract events, wherein the contract events are generated by a block link point responding to a received contract calling transaction for the target down-link contract by calling a predictive engine contract, the contract calling transaction comprises the calling request, and the calling request is encrypted by a cluster identity public key in the cluster identity key;

the any node decrypts the calling request by adopting the cluster identity private key in the cluster identity key in the second-chain trusted execution environment, and executes the target-chain contract based on the information obtained by decryption;

and the any node returns an execution result to the language predictive machine server, and the execution result is transmitted to the language predictive machine contract by the language predictive machine server.

6. The method of claim 5, further comprising:

and the execution result is signed by the any node in the trusted execution environment under the second chain by adopting the cluster identity private key, and the signed execution result is judged to be generated by the private computation cluster under the condition that the execution result is signed and verified by adopting the cluster identity public key and passes the signature verification.

7. The method of claim 5, further comprising:

before the execution result is returned, the execution result is signed by a contract identity private key in a contract identity key of the target chain contract in the second chain trusted execution environment by any node, and the signed execution result is judged to be generated by the target chain contract under the condition that the execution result is subjected to signature verification by the contract identity public key in the contract identity key and passes the signature verification.

8. The method of claim 7, the operation of generating a contract identity key for the target down-link contract comprising:

9. The method of claim 1, further comprising:

and under the condition that the target under-chain contract encrypted by the cluster identity public key in the cluster identity key is received, decrypting the target under-chain contract by the cluster identity private key in the cluster identity key in the second under-chain trusted execution environment and deploying the target under-chain contract.

10. The method of claim 9, further comprising:

said any node providing said second remote attestation report to a signing party of said target chain contract in response to a challenge issued by said signing party prior to receiving said encrypted target chain contract;

11. The method of claim 1, further comprising:

the any node provides a cluster remote attestation report to a challenger of the target down-link contract, wherein the cluster remote attestation report is generated after the authentication server verifies the second self-referral information;

providing to the challenger contract information to be verified for contract under the target chain deployed at the any node, the contract information to be verified being signed by the any node within the second chain trusted execution environment with a cluster identity private key of the cluster identity keys, the cluster identity private key being maintained by the any node within the second chain trusted execution environment;

12. The method according to claim 11, wherein the second self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, the fourth hash value to be verified is a hash value of the preset information of the trusted execution environment under the second chain, the fourth hash value to be verified is used for comparing, by the challenger, a signature verification and a signature verification pass on the cluster remote attestation report according to the public key of the authentication server, and when a remote authentication result included in the cluster remote attestation report is a pass authentication result, a fourth standard hash value obtained in advance for the preset information of the trusted execution environment under the second chain is compared, and the comparison result is consistent and is used as a precondition for the challenger to confirm that the trusted execution environment under the second chain is trusted.

13. The method of claim 11, further comprising:

the any node provides cluster identity information to the challenger, the cluster identity information comprises a cluster identity public key in a cluster identity key, and the cluster identity information is subjected to hash calculation by the challenger to obtain a fifth hash value to be verified;

14. The method of claim 11, the challenger initiating a challenge after each node in the down-chain privacy computing cluster deploys the target down-chain contract, and the initiated challenge is received by a control node of the down-chain privacy computing cluster and forwarded to the any node.

15. The method of claim 11, further comprising:

16. A method of sharing a cluster key, comprising:

the any node receives a cluster identity key and a second remote attestation report which are sent by the other nodes and correspond to the private computing cluster under the chain under the condition that the trusted execution environment under the chain is determined to be trusted according to the first remote attestation report, wherein the cluster identity key is generated in a trusted execution environment under the chain created by the other nodes, the cluster identity key is used for encrypting, decrypting and/or signing and checking interaction data in the process that block chain links interact with each node in the private computing cluster under the chain to deploy or invoke a contract under a target chain, and the second remote attestation report is generated after an authentication server verifies second self-referral information generated by the other nodes aiming at the trusted execution environment under the second chain;

The any node approves the cluster identity key if it is determined that the second remote attestation report indicates that the second down-chain trusted execution environment is trusted.

17. The method of claim 16, the determining, by the any node, from the second remote attestation report that the second off-chain trusted execution environment is trusted operations comprising:

18. The method of claim 16, further comprising:

the any node provides first node identity information to the other nodes, the first node identity information comprises a node identity public key of the any node, and the first node identity information is subjected to hash calculation by the other nodes to obtain a second hash value to be verified;

The any node provides a second standard hash value to the other nodes, and the second standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates the node identity information of the any node in the first-link trusted execution environment;

19. The method of claim 18, further comprising:

the any node acquires second node identity information provided by other nodes, and performs hash calculation on the second node identity information to obtain a third hash value to be verified, wherein the second node identity information comprises node identity public keys of other nodes;

And when the third hash value to be verified and the third standard hash value are consistent, the any node decrypts the received cluster identity key by using the node identity private key of the any node, verifies the signature of the cluster identity key by using the node identity public key contained in the node identity information of the other nodes, and maintains the cluster identity key in the trusted execution environment under the first chain when the signature verification is passed.

20. The method of claim 16, further comprising:

the any node acquires a calling request which is read by a predictive machine server from the monitored contract events and aims at the target down-link contract, wherein the contract events are generated by a block chain node in response to a received contract calling transaction aiming at the target down-link contract by calling a predictive machine contract, the calling request is contained in the contract calling transaction and is encrypted by a cluster identity public key in the cluster identity key;

the any node decrypts the calling request by adopting a cluster identity private key in the cluster identity key in the first-chain trusted execution environment, and executes the target-chain contract based on information obtained by decryption;

21. The method of claim 20, further comprising:

and the execution result is signed by the any node in the first-chain trusted execution environment by using the cluster identity private key, and the signed execution result is judged to be generated by the chain privacy computing cluster under the condition that the execution result is signed and verified by using the cluster identity public key and passes the signature verification.

22. The method of claim 20, further comprising:

before the execution result is returned, the execution result is signed by a contract identity private key in a contract identity key of the target chain contract in the first chain trusted execution environment, and the signed execution result is judged to be generated by the target chain contract under the condition that the execution result is subjected to signature verification by the contract identity public key in the contract identity key and passes the signature verification.

23. The method of claim 22, the operation of generating a contract identity key for the target down-link contract comprising:

24. The method of claim 16, further comprising:

and under the condition that the target under-chain contract encrypted by the cluster identity public key in the cluster identity key is received, decrypting the target under-chain contract by the cluster identity private key in the cluster identity key in the first under-chain trusted execution environment and deploying the target under-chain contract.

25. The method of claim 24, further comprising:

said any node providing said first remote attestation report to a signing party of said target chain contract in response to a challenge initiated by said signing party prior to receiving said encrypted target chain contract;

26. The method of claim 16, further comprising:

the any node provides a cluster remote attestation report to a challenger of the target down-link contract, wherein the cluster remote attestation report is generated after the first self-referral information is verified by an authentication server;

providing to the challenger contract information to be verified for contract under the target chain deployed at the any node, the contract information to be verified being signed by the any node within the first chain trusted execution environment with a cluster identity private key of the cluster identity keys, the cluster identity private key being maintained by the any node within the first chain trusted execution environment;

the contract information to be verified is subjected to signature verification on the contract information to be verified by the challenger by adopting a cluster identity public key in the cluster identity key under the condition that the trusted execution environment under the first chain is determined to be trusted according to the cluster remote attestation report, the contract information to be verified is verified according to the contract information of the contract under the target chain, and under the condition that the signature verification and the contract information verification pass, when the challenger is determined to initiate calling on the contract under the target chain through a prompter mechanism of a block chain node, the contract under the target chain is executed by any node in the trusted execution environment under the first chain.

27. The method according to claim 26, wherein the first self-recommended information carried by the cluster remote attestation report includes a fourth hash value to be verified, the fourth hash value to be verified is a hash value of the preset information of the first-chain lower trusted execution environment, the fourth hash value to be verified is used for comparing, by the challenger, a signature verification and signature verification of the cluster remote attestation report according to the public key of the authentication server, and when a remote authentication result included in the cluster remote attestation report is that the remote authentication result is a pass authentication, a fourth standard hash value obtained in advance for the preset information of the first-chain lower trusted execution environment is compared, and the comparison result is consistent and is used as a precondition for the challenger to confirm that the first-chain lower trusted execution environment is trusted.

28. The method of claim 26, further comprising:

29. The method of claim 26, the challenger initiating a challenge after each node in the down-chain privacy computing cluster deploys the target down-chain contract, and the initiated challenge is received by a control node of the down-chain privacy computing cluster and forwarded to the any node.

30. The method of claim 26, further comprising:

31. An apparatus for sharing a cluster key, comprising:

the report acquisition unit enables any node in the private computing cluster to acquire a first remote attestation report sent by other nodes in the private computing cluster, wherein the first remote attestation report is generated by verifying first self-referral information generated by the other nodes aiming at the created first linked trusted execution environment by an authentication server;

a key obtaining unit, configured to enable the any node to obtain a cluster identity key corresponding to the private computing cluster under the chain, where the cluster identity key is generated in a second-chain trusted execution environment created by the any node, and the cluster identity key is used for encrypting and decrypting interaction data and/or signing and verifying a signature during a process of interacting between a block link node and each node in the private computing cluster under the chain to deploy or invoke a target-chain contract;

a sending unit, configured to, when determining that the trusted execution environment under the first chain is trusted according to the first remote attestation report, send the cluster identity key and a second remote attestation report to the other node, where the second remote attestation report indicates that the trusted execution environment under the second chain is trusted, the cluster identity key is approved by the other node, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by any node for the trusted execution environment under the second chain.

32. An apparatus for sharing a cluster key, comprising:

a receiving unit, configured to enable the any node to receive a cluster identity key and a second remote attestation report, which are sent by the other node and correspond to the private computing cluster under the chain if the trusted execution environment under the chain is determined to be trusted according to the first remote attestation report, where the cluster identity key is generated in a trusted execution environment under the chain created by the other node, the cluster identity key is used for encrypting, decrypting and/or signing and verifying interaction data in a process of interacting with each node in the private computing cluster under the chain to deploy or invoke a target contract under the chain at block chain links, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the other node for the trusted execution environment under the second chain;

A processing unit to cause the any node to approve the cluster identity key if it is determined that the second remote attestation report indicates that the second down-chain trusted execution environment is trusted.

33. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-30 by executing the executable instructions.

34. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 30.