CN111092726A - Method and device for generating shared contract key - Google Patents

Method and device for generating shared contract key Download PDF

Info

Publication number
CN111092726A
CN111092726A CN202010190878.1A CN202010190878A CN111092726A CN 111092726 A CN111092726 A CN 111092726A CN 202010190878 A CN202010190878 A CN 202010190878A CN 111092726 A CN111092726 A CN 111092726A
Authority
CN
China
Prior art keywords
node
contract
cluster
chain
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010190878.1A
Other languages
Chinese (zh)
Other versions
CN111092726B (en
Inventor
吴因佥
邱鸿霖
吴行行
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Priority to CN202010910443.XA priority Critical patent/CN112152800B/en
Priority to CN202010190878.1A priority patent/CN111092726B/en
Publication of CN111092726A publication Critical patent/CN111092726A/en
Application granted granted Critical
Publication of CN111092726B publication Critical patent/CN111092726B/en
Priority to PCT/CN2021/073820 priority patent/WO2021184962A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

This specification provides a method and apparatus for generating a shared contract key, the method comprising: any node in the down-link privacy computing cluster determines a target down-link contract deployed by the node, and the target down-link contract is deployed at a plurality of nodes in the down-link privacy computing cluster; wherein the target down-link contract is executable within an down-link trusted execution environment created by each of the plurality of nodes in response to invocation of the blockchain node; any node operates on a common factor among the multiple nodes and global identification information of a target chain contract in a chain trusted execution environment established by the node through a key generation algorithm shared among the multiple nodes to generate a shared contract identity key corresponding to the target chain contract, wherein the shared contract identity key is used for signing an execution result of the target chain contract in the chain trusted execution environment. The scheme for generating the shared contract key can realize privacy protection.

Description

Method and device for generating shared contract 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 apparatus for generating a shared contract 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 the above, one or more embodiments of the present disclosure provide a method and an apparatus for generating a shared contract key, which enable secure implementation of operations of the shared contract key in a linked 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 generating a shared contract key, comprising:
determining a target under-link contract which is deployed by any node in an under-link privacy computing cluster, wherein the target under-link contract is deployed at a plurality of nodes in the under-link privacy computing cluster; wherein, in response to invocation of a block link point, the target down-link contract is executable within an down-link trusted execution environment created by each of the plurality of nodes;
and the any node operates on the common factors among the nodes and the global identification information of the target under-chain contract in the under-chain trusted execution environment created by the any node through a key generation algorithm shared among the nodes to generate a shared contract identity key corresponding to the target under-chain contract, wherein the shared contract identity key is used for signing the execution result of the target under-chain contract in the under-chain trusted execution environment.
According to a second aspect of one or more embodiments of the present specification, there is provided a method of generating a shared contract key, comprising:
determining a target under-link contract which is deployed by any node in an under-link privacy computing cluster, wherein the target under-link contract is deployed at a plurality of nodes in the under-link privacy computing cluster; wherein, in response to invocation by a client, the target down-link contract is executable within a down-link trusted execution environment created by each of the plurality of nodes;
and the any node operates on the common factors among the nodes and the global identification information of the target under-chain contract in the under-chain trusted execution environment created by the any node through a key generation algorithm shared among the nodes to generate a shared contract identity key corresponding to the target under-chain contract, wherein the shared contract identity key is used for signing the execution result of the target under-chain contract in the under-chain trusted execution environment.
According to a third aspect of one or more embodiments of the present specification, there is provided an apparatus for generating a shared contract key, comprising:
a contract determining unit, which enables any node in the private computing cluster to determine a target under-link contract deployed by itself, wherein the target under-link contract is deployed at a plurality of nodes in the private computing cluster; wherein, in response to invocation of a block link point, the target down-link contract is executable within an down-link trusted execution environment created by each of the plurality of nodes;
and a contract key generation unit, which enables the any node to operate on a common factor among the plurality of nodes and global identification information of the target under-chain contract in the under-chain trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generates a shared contract identity key corresponding to the target under-chain contract, wherein the shared contract identity key is used for signing an execution result of the target under-chain contract in the under-chain trusted execution environment.
According to a fourth aspect of one or more embodiments of the present specification, there is provided an apparatus for generating a shared contract key, comprising:
a contract determining unit, which enables any node in a privacy computing cluster to determine a target intelligent contract deployed by the node, wherein the target intelligent contract is deployed at a plurality of nodes in the privacy computing cluster; wherein, in response to invocation by a client, the target smart contract is executable within a trusted execution environment created by each of the plurality of nodes;
and a contract key generation unit which enables the any node to operate on the sharing factor among the plurality of nodes and the global identification information of the target intelligent contract in the trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generates a shared contract identity key corresponding to the target intelligent contract, wherein the shared contract identity key is used for signing the execution result of the target intelligent contract in the trusted execution environment.
According to a fifth 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 aspect or the second aspect by executing the executable instructions.
According to a sixth 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, implement the steps of the method according to the first or second aspect.
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 execution environment, and the reliability of the chain-down trusted execution environment can be verified through remote attestation, so that the shared contract identity key can be generated safely and reliably and transmitted between nodes in the cluster, and the same contract deployed at all nodes has the same shared contract identity key.
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 flowchart of a method for generating a shared contract key according to an exemplary embodiment.
FIG. 8 is a schematic diagram of a verification of a contract under a chain provided by an exemplary embodiment.
FIG. 9 is a schematic illustration of another verification of a contract under a chain provided by an exemplary embodiment.
FIG. 10 is a scenario diagram of a call under-chain contract provided by an exemplary embodiment.
FIG. 11 is a flowchart of another method for generating a shared contract key provided by an exemplary embodiment.
Fig. 12 is a schematic diagram of an apparatus according to an exemplary embodiment.
FIG. 13 is a block diagram of an apparatus that generates a shared contract key provided by an exemplary embodiment.
FIG. 14 is a block diagram of another apparatus for generating a shared contract key provided by an exemplary 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.
Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) 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-behaved 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 the TEE technology can relatively reduce the resource consumption of a single blockchain node and accelerate the transaction execution efficiency, the resource consumption and waste are still great for the whole blockchain network.
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 single-node type down-link privacy computing node 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 of requesting a private computing node to join a cluster under a control node management link.
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 privacy computing node for implementing the under-chain privacy computing, and the remote attestation process also involves another special enclave on the under-chain privacy computing node, namely, quoting enclave (QE for short), and the QE 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 authentication) key for signing. 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 IntelSGX 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, wherein the first remote attestation report is generated after an authentication server verifies first self-referral information generated by the other nodes aiming at the created 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 under-chain 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-recommendation 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 under-chain trusted execution environment of the other node. After the first hash value to be tested is extracted, comparing a first standard hash value which is obtained in advance and is aimed at preset information in the chain lower trusted execution environment of the other node with the first hash value to be tested, and using the consistency of the comparison result as a precondition for confirming the chain lower trusted execution environment of the other node is trusted. Similarly, the specific process of determining whether the linked trusted execution environment is trusted may refer to the process of determining, by the control node, whether the linked 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 the chain created by any node, and the cluster identity key is used for encrypting and decrypting interactive data and/or signing and checking a signature during the 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.
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, since the first node identity information includes the node identity public keys of the other nodes, the node identity public key included in the first node identity information can be acquired to encrypt the cluster identity key under the condition that the first node identity information passes the 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 by the other node after the other node generates its own node identity information in the under-chain trusted execution environment of the other node. 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 chain-down trusted execution environment created by the any node is determined to be trusted according to the second remote certification report, verify the signature of the cluster identity key by using the node identity public key contained in the node identity information of the any node, and maintain the cluster identity key in the chain-down trusted execution environment of the other nodes 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 nodes (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 chained trusted execution environment of the any node. 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 contained in the node identity information of any node, and maintain the cluster identity key in the trusted execution environment of the chain of the other nodes under the condition that the signature verification is passed.
Similarly, the control node may select another node different from "any node" in the down-link privacy computing cluster as a master node, generate a cluster identity key corresponding to the down-link privacy computing cluster in the down-link TEE created by the control node, and further share the cluster identity key with "any node".
In this case, the process of any node obtaining the cluster identity key includes: the any node provides a second remote attestation report to other nodes in the private computing cluster under the chain (the second remote attestation report is generated after an authentication server verifies second self-referral information generated by the any node for the created trusted execution environment under the chain), and further, the any node receives the cluster identity key and a first remote attestation report which are transmitted by the other nodes under the condition that the trusted execution environment under the chain of the any node is determined to be trusted according to the second remote attestation report, the cluster identity key is generated in the trusted execution environment under the chain created by the other nodes, and the first remote attestation report is generated after the authentication server verifies the first self-referral information generated by the other nodes for the created trusted execution environment under the chain. Then, the any node approves the cluster identity key if it is determined that the first remote attestation report indicates that the chain-down trusted execution environment of the other node is trusted, and then maintains the cluster identity key within the chain-down trusted execution environment created by the any node. The above process of obtaining the cluster identity key shared by other nodes by any node is similar to the above process of sharing the cluster identity key from any node to other nodes, and is not described herein again.
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, and so on. 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 values 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.
Taking 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, that is, the client 31 initiates the down-link challenge to the down-link privacy computing node 32, in another case, the client 31 may initiate the challenge to the down-link privacy computing node 32 through the blockchain network 33, that is, the client 31 initiates the up-link challenge to the down-link privacy computing node 33. the process of initiating the up-link challenge may include three steps, step ①, in which the client 31 submits a transaction for initiating the challenge, for example, called a challenge transaction, to the blockchain network 33, which may be received and executed by a certain node 33n within the blockchain network 33, step ②, in which the node 33n invokes a pre-prompter intelligent contract (for short, a pre-prompter contract), which may transfer the challenge information contained in the above challenge transaction to the down-link prepro server 34, for example, the pre-prompter intelligent contract server 34 may generate an event including the challenge information, which may be sent to the under-link computing node ③ through the down-link computing node 32.
When a client 31 initiates a challenge to a private down-link computing node 32 through an up-link channel, it refers to data interaction between a block-link network 33 and the private down-link computing node 32, i.e. data interaction on and off the link, which may be realized by a preplanning contract cooperating with a preplanning server 34 through the above-mentioned step ②, and the cooperation mechanism between the preplanning contract and the preplanning server 34 is a preplanning mechanism, wherein a transaction submitted to a node 33n by the client 31 should directly or indirectly invoke the preplanning contract described above to trigger the preplanning mechanism, wherein if the contract address of the preplanning contract is filled in the to field of the transaction, it indicates that the transaction directly invokes the preplanning contract, if the contract address of a contract on a link is filled in the to field of the transaction, and the contract on the link invokes the preplanning contract, it indicates that the transaction indirectly invokes the preplanning contract as a preplanning contract address, it may be considered as a result of a data transfer from the up-link contract to the private down-link, and may be transferred from the data exchange to the down-link contract, and the data exchange may be carried from the down-link to the data exchange process.
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 the down-link privacy computing cluster where 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, such as 30 minutes or other duration, the overtime remote attestation report may be considered to be 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.
Taking the scenario shown in fig. 4 as an example, in one case, the client 41 may directly initiate a challenge to the control node 42 through a down-link channel, that is, the client 41 may initiate a down-link challenge to the control node 42, in another case, the client 41 may initiate a challenge to the control node 42 through the blockchain network 43, that is, the client 41 may initiate an up-link challenge to the control node 42, the process of initiating the up-link challenge may include three steps, step ①, the client 41 submits a transaction for initiating the challenge to the blockchain network 43, for example, called a challenge transaction, which may be received and executed by a certain node 43n within the blockchain network 43, step ②, the node 43n invokes a pre-deployed pre-language machine intelligent contract (abbreviated pre-language machine contract), which may transfer challenge information included in the challenge transaction to a pre-language machine server 44 under the link, for example, the pre-language machine contract may generate an event including the challenge information, and the pre-language machine server 44 may listen to the event generated by the pre-language machine contract server to obtain the pre-language machine contract information ③, and send the challenge information to the control node 42 through the down-link channel.
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. Thus, after receiving the challenge initiated by the client 41, the control node 42 may first check to see 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 computing 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.
Taking the scenario shown in fig. 5 as an example, in one case, the client 51 may encrypt the transport bytecode directly to the down-link privacy computing node 52 through the down-link channel, that is, the client 51 may transmit the encrypted bytecode ciphertext to the down-link privacy computing node 52 down-link, in another case, the client 51 may encrypt the transport bytecode to the down-link privacy computing node 52 through the blockchain network 53, that is, the client 51 may transmit the encrypted bytecode ciphertext to the down-link privacy computing node 52 up-link, the process of the up-link encryption transmission may include three steps, step ①, the client 51 may submit a transaction for deploying a down-link contract to the blockchain network 53, that is, a down-link contract deployment transaction, which may be received and executed by a certain node 53n within the blockchain network 53, step ②, the node 53n invokes a prolog machine contract, which may transfer the bytecode included in the down-link contract deployment to a prolog machine server 55 under-link, for example, the prolog machine contract may generate an event including the prolog machine contract, and may generate the prolog machine contract by the contraction server ③, thereby generating the prolog machine contract to generate the events to be transmitted to the down-link through the contraction channel network 3655.
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 may take the symmetric key distributed by the KMS server as a 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 an offline TEE created at the offline privacy computing node 52, several execution engines may be deployed, such as one or more of an EVM, a WASM virtual machine, and so on, and particularly in the case where multiple execution engines are deployed simultaneously, the client 51 may send, to the offline privacy computing node 52, execution engine specifying information associated with the above bytecode, which indicates to the offline privacy computing node 52 the execution engine for executing the above bytecode, such as employing an EVM or 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 manners, 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.
Taking the scenario 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 encrypted manner, and then the bytecode is forwarded to one or more link-down privacy computing nodes in the cluster by the control node 62. in another case, the client 61 may transmit the bytecode in an encrypted manner to the control node 62 through the blockchain network 63, that is, the client 61 transmits the bytecode ciphertext encrypted onto the control node 62 in a link-up encrypted manner, the process of the link-up encrypted transmission may include three steps, step ①, the client 61 submits a transaction for deploying a link-down contract, that is, a link-down contract deployment transaction, to the blockchain network 63, which may be received and executed by a certain node 63n in the blockchain network 63, step ②, the node 63n invokes a prolog machine which may pass the bytecode included in the link-down contract deployment to a prolog machine 64 under the link, for example, the prolog machine contract code which may be generated by the prolog machine, and then forwarded to the control node 62 through a link-down channel network ③, and thus, the prolog machine may listen to the prefix server, and thus generate a plurality of the prolog machine.
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 down-link privacy computing node 62n, so as to accurately forward the bytecode ciphertext to the down-link privacy computing node 62n without forwarding to other down-link privacy computing 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-chain contract if it is determined from the second remote attestation report that the down-chain trusted execution environment created by the any of the nodes 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. And after receiving the encrypted target under-chain contract, the any node decrypts the target under-chain contract through the cluster identity private key in the cluster identity key in the under-chain trusted execution environment of the any node 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 under-chain trusted execution environment of the any node, 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 chain, such as 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 61, so as to determine whether the contract on the chain is successfully deployed by the privacy computation node under the chain. 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. Thus, the same contract identity may be understood as a shared contract identity for multiple nodes in the privacy-compute cluster under the chain. Where the contract identity may be defined by a contract identity key, the process of generating a shared contract key is described below.
Referring to FIG. 7, FIG. 7 is a flowchart of a method for generating a shared contract key according to an exemplary embodiment. As shown in fig. 7, the method may include:
step 702, any node in a chain privacy computation cluster determines a target chain contract deployed by itself, wherein the target chain contract is deployed at a plurality of nodes in the chain privacy computation cluster; wherein the target under-chain contract is executable within an under-chain trusted execution environment created by each of the plurality of nodes in response to invocation of a block link point.
Step 704, the any node performs an operation on the common factor among the plurality of nodes and the global identification information of the target under-chain contract in the under-chain trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generates a shared contract identity key corresponding to the target under-chain contract, where the shared contract identity key is used for signing an execution result of the target under-chain contract in the under-chain trusted execution environment.
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, the any node may generate a shared 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 shared 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 contracts deployed by each node in the private computation cluster are the same, and the global identification information of the same under-chain contract deployed by each node is the same). The target under-chain contract is executed in the under-chain trusted execution environment of any node under the condition that the block chain node initiates a call to the target under-chain contract deployed in any node through a preplan mechanism, the execution result is signed by adopting a shared contract identity key in the under-chain trusted execution environment of any node, and the signed execution result can be fed back to the block chain node through the preplan mechanism. As can be seen, each of the down-link privacy computing nodes generates a shared 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 shared 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 shared contract identity key and then shares the shared contract identity key with other nodes, the efficiency of generating the shared 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 shared 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 private calculation node under the chain can select a uniform cluster identity key and a contract ID of the contract under the chain, and derive the cluster identity key and the contract ID by adopting a key derivation algorithm to obtain a corresponding shared contract identity key, and because the cluster identity keys are the same and the contract IDs of the contracts under different chains 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 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.
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. 8-9.
As shown in fig. 8, for a single node, similar to the embodiment shown in fig. 3, the client 81 may initiate a down-link challenge or an up-link challenge to the down-link privacy computing node 82, the process of initiating the up-link challenge may include three steps, step ①, where the client 81 submits a transaction to the blockchain network 83 for initiating the challenge to the target down-link contract, for example, called a challenge transaction, which may be received and executed by a certain node 83n within the blockchain network 83, step ②, the node 83n invokes a pre-deployed prognostics contract, which may transfer the challenge information contained in the above challenge transaction to the down-link prognostics server 84, for example, the prognostics contract may generate an event containing the challenge information, and the prognostics server 84 may obtain the above challenge information by listening to the event generated by the prognostics contract, step ③, where the prognostics server 84 sends the challenge information to the control node 82 through a down-link channel.
By initiating a challenge for a target down-link contract deployed by the down-link privacy computing node 82, the client 81 may obtain a remote attestation report for the down-link TEE created by the down-link privacy computing node 82, the remote attestation report being generated by the authentication server after verifying the self-referral information generated by the down-link privacy computing node 82 for the down-link TEE. In one case, a challenge is initiated by the client 81 to the down-chain privacy computing node 82, the challenge is a target down-chain contract deployed by the down-chain privacy computing node 82, and the remote attestation report and the contract information to be verified returned by the down-chain privacy computing node 82 in response to the challenge are received, that is, the down-chain privacy computing node 82 returns the remote attestation report and the contract information to be verified to the client 81 in one time in response to the challenge. In another case, the client 81 initiates a challenge to the down-chain privacy computing node 82, the challenge target is a down-chain TEE created by the down-chain privacy computing node 82, and then receives a remote attestation report returned by the down-chain privacy computing node 82, and in a case that the down-chain TEE is determined to be trusted according to the remote attestation report, sends an acquisition request for contract information of a target down-chain contract deployed at the down-chain privacy computing node 82 to the down-chain privacy computing node 82, and receives contract information to be verified returned by the down-chain privacy computing node 82 in response to the acquisition request. In the case where 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 82 to obtain contract information for the target down-link contract (i.e., contract information to be verified).
Wherein the client 81 may initiate a challenge to the challenge target through an on-chain challenge. For example, a challenge transaction for the challenge target is submitted to the blockchain node 83n, and the challenge transaction includes challenge information transmitted by the blockchain node 83n to the down-chain privacy computing node 82 through the prolog mechanism, and the challenge information is used for initiating a challenge to the challenge target. Alternatively, the client 81 initiates the down-link challenge directly to the challenge target in the down-link privacy computing node 82.
In this embodiment, the operation of the client 81 to verify the down-link TEE of the down-link privacy computing node 82 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. 8, in an embodiment, after the node identity information of the node 82 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 82 and other identity information of the down-link privacy computing node 82. Then, the client 81 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 82 under the chain and other identity information of the private computing node 82 under the chain, and is not necessarily real data, and may be understood as the identity information to be verified) provided by the private computing node 82 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 82 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 82, 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 82 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 82 is the node identity information generated in the down-link TEE, and therefore the node identity public key included therein is the actual node identity public key of the privacy computing node 82, and the actual node identity public key of the privacy computing node 82 can be used for verifying the signature of the privacy computing node 82. The downlink privacy computation node 82 may send the second standard hash value, the remote attestation report, and the first node identity information to the client 81. 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 node identity information generated by the down-link privacy computing node 82 in the down-link TEE includes a node identity public key of the down-link privacy computing node 82, other identity information of the down-link privacy computing node 82, and a hash value of preset information of the down-link TEE, and then the down-link privacy computing node 82 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 82 may provide the client 81 with the remote attestation report, the third standard hash value, and the second node identity information (which may be understood at this time as the identity information to be verified). The second node identity information comprises a node identity public key of the down-link privacy computing node 82, other identity information of the down-link privacy computing node 82 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 82. 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 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 is described that the second node identity information provided by the privacy computing node 82 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 82, and may be used to perform signature verification on the contract information to be verified. The downlink privacy computation node 82 may send the third standard hash value, the remote attestation report, and the second node identity information to the client 81. 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 client 81 determines that the chain-down TEE is credible according to the remote certification report, acquiring contract information to be verified of a target chain-down contract arranged at the chain-down privacy computing node 82, wherein the contract information to be verified is signed by the chain-down privacy computing node 82 in the chain-down TEE by using a node identity private key of the client, and the node identity private key is generated by the chain-down privacy computing node 82 in the chain-down TEE. For example, the down-chain privacy computing node 82 may read the deployed target down-chain contract into the down-chain TEE and sign with its own node identity private key.
The client 81 performs signature verification on the contract information to be verified by using the node identity public key of the down-link privacy computing node 82, 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 node identity public key is published to the outside by the private computing node 82 in the chain for acquisition by the client 81. Alternatively, the client 81 obtains the node identity information of the privacy computation node 82 through the verification link. 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.
In the event that the signature verification and contract information verification pass, the client 81 may determine that the client 81 is executing in the down-chain TEE trusted execution environment by the down-chain privacy computing node 82 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 contract under the chain of the privacy computing node 82 is trusted, and then, under the condition that the contract under the chain of the privacy computing node 82 is trusted, if the signature is verified to obtain that the contract information to be verified provided by the privacy computing node 82 under the chain is indeed signed by the node identity private key (maintained in the TEE under the chain) of the privacy computing node 82 under the chain, it can be determined that the currently challenged contract under the chain is a target contract under the chain running in the TEE of the privacy computing node 82 under the chain, that is, it is ensured that the contract under the target chain deployed in the privacy computing node 82 under the chain is trusted, and the computing task can be executed according to the expectation of the user.
As shown in fig. 9, for the form of the private computing cluster under the chain, similar to the embodiment shown in fig. 4, the client 91 may initiate a challenge under the chain or a challenge on the chain to the control node 92, the process of initiating the challenge on the chain may include three steps, step ①, where the client 91 submits a transaction for initiating the challenge to the blockchain network 93 under the target chain contract, for example, called a challenge transaction, which may be received and executed by a certain node 93n within the blockchain network 93, step ②, the node 93n invokes a pre-deployed prognostics contract, which may transfer the challenge information contained in the above challenge transaction to the prognostics server 94 under the chain, for example, the prognostics contract may generate an event containing the challenge information, and the prognostics server 94 may obtain the above challenge information by listening to the event generated by the prognostics contract, step ③, where the prognostics server 94 sends the challenge information to the control node 92 through a channel under the chain.
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. 9, a user may initiate a challenge to a target under-chain contract deployed in a cluster through a client 91 before invoking the target under-chain contract in the cluster through the client 91 (the challenge is initiated after each node in the under-chain privacy computing cluster deploys the target under-chain contract). The control node 92, 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 92n responding to the challenge is illustrated. Control node 92 selects node 92n to respond to the challenge on behalf of the cluster, providing a cluster remote attestation report on behalf of the cluster to the challenger. The cluster remote attestation report is generated by the authentication server after verifying the self-referral information generated by the node 92n for the own chain TEE, that is, the cluster remote attestation report is a remote attestation report corresponding to the chain TEE of the node 92 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 92n, 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 authenticated, 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) for the chain-down TEE obtained in advance, and the comparison result is consistent and is used as a precondition for the challenger to confirm that the chain-down TEE is authentic. 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 92 n.
As shown in fig. 9, in an embodiment, when the node 92n 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 92 n. In other words, based on representing a cluster by node 92n, the difference between the node identity information of node 92n 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 91 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 92n, and is not necessarily real data, and may be understood as identity information to be verified) provided by the node 92n by 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 by 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 92n, so as to determine that the cluster identity authentication is passed when the comparison result is consistent. Since the cluster identity information is generated and calculated by the node 92n in the chain TEE, and then the second standard hash value is obtained, 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 calculation node 92 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 calculation node 92, and the cluster identity public key actually maintained by the privacy calculation node 92 can be used for verifying the signature of the privacy calculation node 92. The node 92n may send the second standard hash value, the remote attestation report, and the first cluster identity information to the client 91 through the control node 92. 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. 9, in another embodiment, the cluster identity information generated by the node 92n in the chain-down TEE may include a cluster identity public key, hash values of other identity information except the node identity public key in the node identity information of the node 92n and preset information of the chain-down TEE, and then the node 92n generates the cluster identity information in its own chain-down TEE, and performs hash calculation on the generated cluster identity information to obtain a third standard hash value, where 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 92n may provide the client 91 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 92n 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 is not necessarily real cluster identity information provided for the node 92 n. Then, the client 91 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 indicated that the second cluster identity information provided by the privacy computing node 92 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 92, and may be used to perform signature verification on the contract information to be verified. The node 92n may send the third standard hash value, the remote attestation report, and the second cluster identity information to the client 91 through the control node 92. 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. 8, the cluster remote attestation report and the contract information to be verified are sent to the control node 92 by the node 92n, and then forwarded to the client 91 by the control node 92. The control node 92 may provide the cluster remote attestation report and the contract information to be verified to the client 91 together, or may provide the cluster remote attestation report first, and after the client 91 passes verification according to the cluster remote attestation report, obtain the contract information to be verified from the node 92n to provide the contract information to be verified to the client 91. The contract information to be verified is contract information of a target under-chain contract deployed at the node 92n, and the node 92n performs signature in the under-chain TEE of the node 92n by using a cluster identity private key (maintained in the under-chain TEE of the node 92 n). For example, the node 92n reads the target under-chain contract deployed at the node 92n into the under-chain TEE and signs with the cluster identity private key.
The client 91 performs signature verification on the contract information to be verified by using the cluster identity public key under the condition that the chain TEE is determined to be credible (namely the chain TEE of the node 92n, the node 92n represents the cluster, and the user cannot sense other nodes in the cluster) according to the cluster remote certification report, and performs contract information verification on the contract information to be verified according to the contract information of the target chain contract. Wherein the cluster identity public key is in a public state, for example, the control node 91 publishes the cluster identity public key to the outside for being acquired by the client 91. Alternatively, the client 91 obtains the cluster identity information by the above-mentioned method. 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 91. 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 91 may determine that the client 91 initiated a call to the target under-chain contract through the prolog mechanism of the blockchain node, which was executed by the node 92n in the under-chain TEE trusted execution environment, i.e., ensure that the target under-chain contract deployed in the node 92n 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 state 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 update of the state of the related account may cause a value change of a root of a state tree (state tree), and the root of the state tree may be included in the block header of the latest block, thereby implementing the update of the block chain account data, that is, equivalent to 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. 10, assume that client 1001 wishes to make a call to a deployed under-chain contract (such as after verifying that the target under-chain contract passes). The client 1001 may send a call request to the control node 1002 through a downlink channel, where the call request is encrypted by using a public key of a cluster identity, and the control node 1002 may distribute the call request to a certain downlink privacy computing node in the cluster, such as the node 1002n, based on a load balancing algorithm, where the node 1002n responds to the call request. The node 1002n 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 contract under the chain, so that the node 1002n can find the bytecode of the corresponding deployed contract under the chain based on the hash. The contract under the chain may contain multiple functions, so the function name may specify the function that the client 1001 wishes to call; if the contract under the chain contains only one function, or if the client 1001 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 1002n may obtain the entry parameter data accordingly, and particularly, when the client 1001 itself is not the data owner, the interaction between the client 1001 and the data owner may be omitted, and the data amount of the call request may be reduced, and the transmission speed thereof may be increased. Then, the node 1002n may execute the byte code of the down-link contract in the down-link TEE to process the in-parameter data, thereby obtaining a corresponding call result. The node 1002n may encrypt the call result in the down-link TEE and feed back the call result to the client 1001 through the control node 1002.
The client 1001 may send a call request to the control node 1002 through an on-chain channel. The client 1001 may submit a contract-down-link call transaction to the blockchain network 1003, which includes a call request encrypted by the client 1001 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 heard by the predictive engine server 1004 before the invocation request is retrieved by the predictive engine server 1004 and transmitted to the control node 1002. The control node 1002 then distributes the invocation request, for example, to the down-link privacy computing node 1002n for response. And, the control node 1002 may feed back the invocation result to the chain through a prediction mechanism, and the node 1003n may initiate a transaction actively, and chain the invocation result, or the node 1003n may feed back the invocation result to the client 1001, and the client 1001 re-initiates a transaction to chain the invocation result.
If the import parameter data is blockchain data, the client 1001 may submit an encrypted contract-down-link call transaction to the blockchain network 1003, where the contract-down-link call transaction includes information of a contract ID, a function name, and the import parameter data, and the contract-down-link call transaction calls an contract on the link for acquiring the import parameter data. After receiving the encrypted under-chain contract invoking transaction, the node 1003n decrypts the on-chain TEE created by the node 1003n, executes the invoked on-chain contract through a virtual machine deployed in the on-chain TEE to obtain blockchain data serving as entry data, the blockchain data is usually in an encrypted state, the node 1003n can decrypt the data in the on-chain TEE into a plaintext, then packages 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, encrypts the invoking request in the on-chain TEE by using a cluster identity public key, then transmits the invoking request to the control node 1002 based on a preplan mechanism, and the control node 1002 distributes the invoking request to the under-chain privacy computing node 1002n for response. And, the control node 1002 may feed back the call result to the chain through a prediction mechanism, and the node 1003n may chain the call result.
In addition to encrypting the call request using the cluster identity public key, the client 1001 or node 1003n 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 chain computing node 1002n 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 1002n may sign the invocation result through the contract signature private key of the invoked down-chain contract, and the client 1001 or node 1003n may check and sign 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. 10, the example of the private computation cluster is described. In fact, the client 1001 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 shared 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 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 target contract under chain "will be referred to as" target intelligent contract ". 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 flowchart of another method for generating a shared contract key provided by an exemplary embodiment. As shown in fig. 11, the method may include the steps of:
step 1102, determining a target intelligent contract which is deployed by any node in a privacy computing cluster, wherein the target intelligent contract is deployed at a plurality of nodes in the privacy computing cluster; wherein the target smart contract is executable within a trusted execution environment created by each of the plurality of nodes in response to invocation by a client.
And 1104, the any node performs operation on the common factor among the plurality of nodes and the global identification information of the target smart contract in the trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generates a shared contract identity key corresponding to the target smart contract, wherein the shared contract identity key is used for signing the execution result of the target smart contract in the trusted execution environment.
As described above, the common factor includes a cluster identity key corresponding to the plurality of nodes, and the cluster identity key is used for encrypting and decrypting the interaction data and/or signing and checking the signature during the process of the client interacting with the plurality of nodes to deploy or invoke the smart contract.
As previously described, the cluster identity key is generated within a trusted execution environment created by the any node; the any node sharing the cluster identity key to other nodes in the privacy computing cluster, including:
the any node acquires a first remote attestation report sent by the other node, wherein the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other node aiming at the created trusted execution environment;
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 of the other nodes 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 of the any node 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 created trusted execution environment.
As previously mentioned, the determining, by the any node, that the trusted execution environment of the other node is trusted based on the first remote attestation report includes:
performing 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-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 trusted execution environment of the other node;
and comparing a first standard hash value of preset information in the trusted execution environment of the other node, which is obtained in advance, with the first hash value to be verified, and taking the comparison result as a precondition for confirming that the trusted execution environment of the other node is trusted.
As described above, before sending the cluster identity key to the other nodes, the any node obtains 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 generated node identity information after the other node generates own node identity information in a trusted execution environment of the other node;
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 for 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 a trusted execution environment of the any node;
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 keys 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 of the other nodes under the condition that the signature verification is passed.
As mentioned above, the obtaining, by the any node, the cluster identity key includes:
the any node provides a second remote attestation report to other nodes in the private computing cluster, wherein 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 created trusted execution environment;
the any node receives the cluster identity key and a first remote attestation report which are sent by the other nodes under the condition that the trusted execution environment of the any node is determined to be trusted according to the second remote attestation report, wherein the cluster identity key is generated in the trusted execution environment created by the other nodes, and the first remote attestation report is generated by an authentication server after first self-referral information generated by the other nodes aiming at the created trusted execution environment is verified;
the any node approves the cluster identity key if it is determined that the first remote attestation report indicates that the trusted execution environment of the other node is trusted.
As described above, when receiving the target smart contract encrypted by the cluster identity public key in the cluster identity key, the any node decrypts and deploys the target smart contract by the cluster identity private key in the cluster identity key in the trusted execution environment of the any node.
As mentioned above, before receiving the encrypted target smart contract, the any node provides a second remote attestation report to a signing party of the target smart contract in response to a challenge initiated by the signing party, the second remote attestation report being generated by an authentication server after verifying second self-referral information generated by the any node for the created trusted execution environment, the encrypted target smart contract being sent by the signing party with the trusted execution environment of any node determined to be trusted according to the second attestation report.
As described above, before the client initiates a call to the target smart contract deployed at any node, the any node provides the cluster remote attestation report to the client, the cluster remote attestation report being generated by an authentication server after verifying second self-referral information generated by the any node for the created trusted execution environment;
providing to the client to-be-verified contract information of the target smart contract deployed at the any node, the to-be-verified contract information being signed by the any node within a trusted execution environment of the any node using 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 trusted execution environment of the any node;
and under the condition that the client determines that the trusted execution environment of any node is trusted according to the cluster remote attestation report, the client 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 determines that the target intelligent contract is executed by any node in the trusted execution environment of any node under the condition that the signature verification and the contract information verification pass.
As mentioned above, the second self-recommended information generated by the any node in the cluster remote attestation report for the created trusted execution environment 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 of the any node, the fourth hash value to be verified is used for the client 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 of the preset information in the trusted execution environment for the any node obtained in advance, and the comparison result is consistent and used as a precondition for the client to confirm that the trusted execution environment of the any node is trusted.
As described above, the any node provides cluster identity information to the client, 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 client to obtain a fifth hash value to be verified;
the any node provides a fifth standard hash value to the client, 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 a trusted execution environment of the any node;
and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the client 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 the any node decrypts the calling transaction by adopting the cluster identity private key in the cluster identity key in the trusted execution environment of the any node so as to respond to the decrypted calling transaction to execute the target intelligent contract.
As described above, the contract identity private key in the shared contract identity key is used to sign the execution result obtained by executing the target smart contract, and the contract identity public key in the shared contract identity key is used to encrypt the input parameter data used when the target smart contract is invoked.
It should be noted that, the specific process for generating the shared contract key may refer to the embodiment shown in fig. 7, and is not described herein again.
In correspondence with the above method embodiments, the present specification also provides an embodiment of an apparatus for generating a shared contract key.
Embodiments of the apparatus for generating a shared contract key of the present specification may 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. 12, fig. 12 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 12, at the hardware level, the apparatus includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210, although it may also include hardware required for other services. Processor 1202 reads the corresponding computer program from non-volatile storage 1210 into memory 1208 and then runs the computer program, forming a means for generating a shared contract 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 one embodiment, referring to fig. 13, in a software implementation, the means for generating the shared contract key may include:
a contract determining unit 1301, which enables any node in the private computing cluster to determine a target under-chain contract that has been deployed by itself, where the target under-chain contract is deployed at multiple nodes in the private computing cluster; wherein, in response to invocation of a block link point, the target down-link contract is executable within an down-link trusted execution environment created by each of the plurality of nodes;
the contract key generation unit 1302 is configured to cause the any node to operate on the common factor between the plurality of nodes and the global identification information of the target down-chain contract within the down-chain trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generate a shared contract identity key corresponding to the target down-chain contract, where the shared contract identity key is used to sign an execution result of the target down-chain contract within the down-chain trusted execution environment.
Optionally, the common factor includes cluster identity keys corresponding to the plurality of nodes, and the cluster identity keys are used for encrypting and decrypting the interaction data and/or signing and checking the signature during the process of interacting with the plurality of nodes to deploy or invoke the linked contract.
Optionally, the cluster identity key is generated in a chain trusted execution environment created by any node; the device further comprises:
an obtaining unit 1303, configured to enable the any node to obtain a first remote attestation report sent by another node in the private computing cluster under the link, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the another node for the created trusted execution environment under the link;
a sending unit 1304, configured to, if it is determined that the chain-down trusted execution environment of the other node is trusted according to the first remote attestation report, cause the any node to send the cluster identity key and a second remote attestation report to the other node, where the cluster identity key is approved by the other node if the second remote attestation report indicates that the chain-down trusted execution environment of the any node 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 created chain-down trusted execution environment.
Optionally, the sending unit 1304 is further configured to:
performing 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-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 chain lower trusted execution environment of the other node;
and comparing a first standard hash value of preset information in the chain trusted execution environment of the other node with the first hash value to be checked, and using the comparison result as a precondition for confirming that the chain trusted execution environment of the other node is trusted.
Optionally, the sending unit 1304 is further 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 a linked trusted execution environment of the other node;
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.
Optionally, the sending unit 1304 is further configured to:
enabling the any node to provide 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;
enabling any node to provide a third standard hash value for other nodes, wherein the third standard hash value is obtained by performing hash calculation on generated node identity information after the any node generates node identity information of the any node in a linked trusted execution environment of the any node;
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 a trusted execution environment under the chain of the other nodes under the condition that the signature verification is passed.
Optionally, the sending unit 1304 is further configured to:
causing the any node to provide a second remote attestation report to other nodes in the private computing cluster under the chain, the second remote attestation report being generated by an authentication server after verifying second self-referral information generated by the any node for the created trusted execution environment under the chain;
causing the any node to receive the cluster identity key and a first remote attestation report sent by the other node when the trusted execution environment under the chain of the any node is determined to be trusted according to the second remote attestation report, wherein the cluster identity key is generated in the trusted execution environment under the chain created by the other node, and the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other node for the trusted execution environment under the chain created;
cause the any node to approve the cluster identity key if it is determined that the first remote attestation report indicates that the chain-down trusted execution environment of the other node is trusted.
Optionally, the method further includes:
the deployment unit 1305, when receiving the target under-chain contract encrypted by the cluster identity public key in the cluster identity key, causes the any node to decrypt the target under-chain contract through the cluster identity private key in the cluster identity key and deploy the target under-chain contract in the under-chain trusted execution environment of the any node.
Optionally, before receiving the encrypted target-chain contract, the deployment unit 1305 is further configured to:
and enabling any node to respond to a challenge initiated by a signature part of the target chain lower contract, and providing a second remote certification report to the signature part, wherein the second remote certification report is generated by an authentication server after verifying second self-referral information generated by any node aiming at the created chain lower trusted execution environment, and the encrypted target chain lower contract is sent by the signature part under the condition that the chain lower trusted execution environment of any node is determined to be trusted according to the second certification report.
Optionally, the encrypted target under-link contract is uploaded to the control node of the under-link privacy computing cluster by the deployment party of the target under-link contract, and is forwarded to the any node by the control node.
Optionally, the block link node initiates a call to the target link contract based on a transaction initiated by a client; before a block link point initiates a call to the target under-link contract deployed at the any node through a preplan mechanism, the sending unit 1304 is further configured to:
causing the any node to provide the cluster remote attestation report to the client, the cluster remote attestation report generated by an authentication server after verification of second self-referral information generated by the any node for the created down-link trusted execution environment;
causing the any node to provide to the client to-be-verified contract information for the target down-chain contract deployed at the any node, the to-be-verified contract information being signed by the any node within the down-chain trusted execution environment of the any node using 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 down-chain trusted execution environment of the any node;
and under the condition that the client determines that the under-chain trusted execution environment of any node is trusted according to the cluster remote attestation report, the client 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 under-chain contract of the target, and determines that the under-chain contract of the target is executed by any node in the under-chain trusted execution environment of any node under the condition that the signature verification and the contract information verification pass.
Optionally, the second referral information generated by any node carried by the cluster remote attestation report for the created downlink trusted execution environment includes a fourth hash value to be verified, the fourth hash value to be checked is a hash value of preset information of the under-chain trusted execution environment of any node, the fourth hash value to be verified is used for the client to perform signature verification on the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote attestation report contains a remote authentication result that is authenticated, comparing with a fourth standard hash value of preset information in the chain trusted execution environment aiming at any node obtained in advance, and the consistency of the comparison result is used as a precondition that the client confirms that the chain trusted execution environment of any node is trusted.
Optionally, the sending unit 1304 is further configured to:
enabling any node to provide cluster identity information to the client, 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 client to obtain a fifth hash value to be verified;
enabling any node to provide a fifth standard hash value to the client, wherein the fifth standard hash value is obtained by performing hash calculation on the cluster identity information after any node generates the cluster identity information in a linked trusted execution environment of any node;
and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the client acquires the cluster identity public key contained in the cluster identity information under the condition that the comparison result is consistent.
Optionally, the client 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 deployment unit 1305 is further configured to:
enabling any node receiving block chain node to receive a calling transaction initiated by the target chain contract through a preplan mechanism, wherein the calling transaction is encrypted by a cluster identity public key in the cluster identity key, the calling transaction is received by a control node of the chain privacy computation cluster and is forwarded to any node according to the load condition of the chain privacy computation cluster;
and enabling any node to decrypt the call transaction by adopting the cluster identity private key in the cluster identity key in the chained trusted execution environment of any node so as to respond to the decrypted call transaction to execute the target chained contract.
Optionally, a contract identity private key in the shared contract identity key is used to sign an execution result obtained by executing the target down-link contract, and a contract identity public key in the shared contract identity key is used to encrypt input parameter data used when invoking the target down-link contract.
In another embodiment, referring to fig. 14, in a software implementation, the means for generating the shared contract key may include:
a contract determining unit 1401, which causes any node in the privacy computing cluster to determine a target intelligent contract that has been deployed by itself, the target intelligent contract being deployed at a plurality of nodes in the privacy computing cluster; wherein, in response to invocation by a client, the target smart contract is executable within a trusted execution environment created by each of the plurality of nodes;
the contract key generation unit 1402 causes the any node to generate a shared contract identity key corresponding to the target smart contract by operating on a common factor between the plurality of nodes and the global identification information of the target smart contract within the trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, the shared contract identity key being used for signing an execution result of the target smart contract within the trusted execution environment.
Optionally, the common factor includes a cluster identity key corresponding to the plurality of nodes, and the cluster identity key is used for encrypting and decrypting the interaction data and/or signing and checking the signature during the process of the client interacting with the plurality of nodes to deploy or invoke the smart contract.
Optionally, the cluster identity key is generated in a trusted execution environment created by any node; the device further comprises:
an obtaining unit 1403, which enables the any node to obtain a first remote attestation report sent by the other node, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other node for the created trusted execution environment;
a sending unit 1404, configured to, if it is determined from the first remote attestation report that the trusted execution environment of the other node is trusted, cause the any node to send the cluster identity key and a second remote attestation report to the other node, where the cluster identity key is approved by the other node if the second remote attestation report indicates that the trusted execution environment of the any node 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 created trusted execution environment.
Optionally, the sending unit 1404 is further configured to:
performing 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-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 trusted execution environment of the other node;
and comparing a first standard hash value of preset information in the trusted execution environment of the other node, which is obtained in advance, with the first hash value to be verified, and taking the comparison result as a precondition for confirming that the trusted execution environment of the other node is trusted.
Optionally, the sending unit 1404 is further 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 a trusted execution environment of the other node;
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.
Optionally, the sending unit 1404 is further 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 for 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 a trusted execution environment of the any node;
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 keys 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 of the other nodes under the condition that the signature verification is passed.
Optionally, the sending unit 1404 is further configured to:
the any node provides a second remote attestation report to other nodes in the private computing cluster, wherein 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 created trusted execution environment;
the any node receives the cluster identity key and a first remote attestation report which are sent by the other nodes under the condition that the trusted execution environment of the any node is determined to be trusted according to the second remote attestation report, wherein the cluster identity key is generated in the trusted execution environment created by the other nodes, and the first remote attestation report is generated by an authentication server after first self-referral information generated by the other nodes aiming at the created trusted execution environment is verified;
the any node approves the cluster identity key if it is determined that the first remote attestation report indicates that the trusted execution environment of the other node is trusted.
Optionally, the method further includes:
a deployment unit 1405, where, when receiving the target smart contract encrypted by the cluster identity public key in the cluster identity key, the any node decrypts and deploys the target smart contract by the cluster identity private key in the cluster identity key in the trusted execution environment of the any node.
Optionally, before receiving the encrypted target smart contract, deployment unit 1405 is further configured to:
and enabling any node to respond to a challenge initiated by a deployer of the target intelligent contract, and providing a second remote certification report to the deployer, wherein the second remote certification report is generated by an authentication server after verifying second self-recommendation information generated by any node for the created trusted execution environment, and the encrypted target intelligent contract is sent by the deployer under the condition that the trusted execution environment of any node is determined to be trusted according to the second certification report.
Optionally, before the client initiates a call to the target smart contract deployed in any node, sending unit 1404 is further configured to:
the any node provides the cluster remote attestation report to the client, wherein the cluster remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node aiming at the created trusted execution environment;
providing to the client to-be-verified contract information of the target smart contract deployed at the any node, the to-be-verified contract information being signed by the any node within a trusted execution environment of the any node using 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 trusted execution environment of the any node;
and under the condition that the client determines that the trusted execution environment of any node is trusted according to the cluster remote attestation report, the client 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 determines that the target intelligent contract is executed by any node in the trusted execution environment of any node under the condition that the signature verification and the contract information verification pass.
Optionally, second self-recommendation information, generated by the any node for the created trusted execution environment, 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 preset information of the trusted execution environment of the any node, the fourth hash value to be verified is used for the client 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 comparison result is compared with a fourth standard hash value, obtained in advance, of the preset information in the trusted execution environment of the any node, and the comparison result is consistent and used as a precondition for the client to confirm that the trusted execution environment of the any node is trusted.
Optionally, the sending unit 1404 is further configured to:
the any node provides cluster identity information to the client, 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 client to obtain a fifth hash value to be verified;
the any node provides a fifth standard hash value to the client, 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 a trusted execution environment of the any node;
and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the client acquires the cluster identity public key contained in the cluster identity information under the condition that the comparison result is consistent.
Optionally, deployment unit 1405 is further configured to:
the any node receives a calling transaction initiated by the client to the target intelligent contract, 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 privacy computation cluster and forwarded to the any node according to the load condition of the privacy computation cluster;
and the any node decrypts the calling transaction by adopting the cluster identity private key in the cluster identity key in the trusted execution environment of the any node so as to respond to the decrypted calling transaction to execute the target intelligent contract.
Optionally, a contract identity private key in the shared contract identity key is used to sign an execution result obtained by executing the target intelligent contract, and a contract identity public key in the shared contract identity key is used to encrypt an input parameter data used when the target intelligent contract is called.
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 non-transitory and non-transitory, removable and non-removable media, may implement 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 (34)

1. A method of generating a shared contract key, comprising:
determining a target under-link contract which is deployed by any node in an under-link privacy computing cluster, wherein the target under-link contract is deployed at a plurality of nodes in the under-link privacy computing cluster; wherein, in response to invocation of a block link point, the target down-link contract is executable within an down-link trusted execution environment created by each of the plurality of nodes;
and the any node operates on the common factors among the nodes and the global identification information of the target under-chain contract in the under-chain trusted execution environment created by the any node through a key generation algorithm shared among the nodes to generate a shared contract identity key corresponding to the target under-chain contract, wherein the shared contract identity key is used for signing the execution result of the target under-chain contract in the under-chain trusted execution environment.
2. The method of claim 1, the common factor comprising a cluster identity key corresponding to the plurality of nodes, the cluster identity key being used to encrypt and decrypt interaction data and/or to sign a signature during a block chain link interacting with the plurality of nodes to deploy or invoke a chain-down contract.
3. The method of claim 2, the cluster identity key being generated within a chained trusted execution environment created by the any node; the sharing, by the any node, the cluster identity key to other nodes in the down-link privacy computing cluster includes:
the any node acquires a first remote attestation report sent by the other node, wherein the first remote attestation report is generated after an authentication server verifies first self-referral information generated by the other node aiming at the created down-link trusted execution environment;
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 chain of the other nodes 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 chain of the any node 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 created trusted execution environment under the chain.
4. The method of claim 3, the any node determining from the first remote attestation report that an off-chain trusted execution environment of the other node is trusted, comprising:
performing 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-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 chain lower trusted execution environment of the other node;
and comparing a first standard hash value of preset information in the chain trusted execution environment of the other node with the first hash value to be checked, and using the comparison result as a precondition for confirming that the chain trusted execution environment of the other node is trusted.
5. The method of claim 3, the any node, prior to sending the cluster identity key to the other node, further comprising:
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 a linked trusted execution environment of the other node;
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.
6. 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 and other identity information of the any node;
the any node provides a third standard hash value for 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 node identity information of the any node in a linked trusted execution environment of the any node;
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 a trusted execution environment under the chain of the other nodes under the condition that the signature verification is passed.
7. The method of claim 2, the any node obtaining the cluster identity key, comprising:
the any node provides a second remote attestation report to other nodes in the private computing cluster under the chain, wherein the second remote attestation report is generated after an authentication server verifies second self-referral information generated by the any node aiming at the created trusted execution environment under the chain;
the any node receives the cluster identity key and a first remote attestation report which are sent by the other nodes under the condition that the trusted execution environment under the chain of the any node is determined to be trusted according to the second remote attestation report, the cluster identity key is generated in the trusted execution environment under the chain created by the other nodes, and the first remote attestation report is generated by an authentication server after first self-referral information generated by the other nodes aiming at the trusted execution environment under the chain created is verified;
the any node approves the cluster identity key if it is determined that the first remote attestation report indicates that the below-chain trusted execution environment of the other node is trusted.
8. The method of claim 2, further comprising:
and when any node receives the target under-link contract encrypted by the cluster identity public key in the cluster identity key, decrypting the target under-link contract by the cluster identity private key in the cluster identity key in the under-link trusted execution environment of the any node and deploying the target under-link contract.
9. The method of claim 8, the any node, prior to receiving the encrypted target-chain contract, further comprising:
providing a second remote attestation report to a signing party of the target chain contract in response to a challenge initiated by the signing party, the second remote attestation report being generated by an authentication server after verifying second self-referral information generated by the any node for the created chain-down trusted execution environment, the encrypted target chain contract being sent by the signing party with the chain-down trusted execution environment of any node determined to be trusted according to the second remote attestation report.
10. The method of claim 8, the encrypted target down-link contract uploaded by a deployer of the target down-link contract to a control node of the down-link privacy computing cluster and forwarded by the control node to the any node.
11. The method of claim 2, the block chain node initiating a call to the target under-chain contract based on a client-initiated transaction; before a block link point initiates a call to the target under-link contract deployed at the any node through a preplan mechanism, the method further comprises:
the any node provides the cluster remote attestation report to the client, wherein the cluster remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node aiming at the created down-link trusted execution environment;
providing, to the client, 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 under-chain trusted execution environment of the any node using 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 under-chain trusted execution environment of the any node;
and under the condition that the client determines that the under-chain trusted execution environment of any node is trusted according to the cluster remote attestation report, the client 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 under-chain contract of the target, and determines that the under-chain contract of the target is executed by any node in the under-chain trusted execution environment of any node under the condition that the signature verification and the contract information verification pass.
12. The method of claim 11, the any node carried by the cluster remote attestation report including a fourth hash value to be verified within second referral information generated for a created, down-chain trusted execution environment, the fourth hash value to be checked is a hash value of preset information of the under-chain trusted execution environment of any node, the fourth hash value to be verified is used for the client to perform signature verification on the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote attestation report contains a remote authentication result that is authenticated, comparing with a fourth standard hash value of preset information in the chain trusted execution environment aiming at any node obtained in advance, and the consistency of the comparison result is used as a precondition that the client confirms that the chain trusted execution environment of any node is trusted.
13. The method of claim 11, further comprising:
the any node provides cluster identity information to the client, 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 client to obtain a fifth hash value to be verified;
the any node provides a fifth standard hash value to the client, 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 a linked trusted execution environment of the any node;
and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the client acquires the cluster identity public key contained in the cluster identity information under the condition that the comparison result is consistent.
14. The method of claim 11, the client initiating a challenge upon each node in the down-chain privacy computing cluster deploying the target down-chain contract, and the initiated challenge being received by a control node of the down-chain privacy computing cluster and forwarded to the any node.
15. The method of claim 2, further comprising:
the any node receiving block chain node receives a calling transaction initiated by the target under-link contract through a preplan mechanism, the calling transaction is encrypted by a cluster identity public key in the cluster identity key, the calling transaction is received by a control node of the under-link privacy computation cluster and is forwarded to the any node according to the load condition of the under-link privacy computation cluster;
and the any node decrypts the calling transaction by adopting the cluster identity private key in the cluster identity key in the chained trusted execution environment of the any node so as to respond to the decrypted calling transaction to execute the target chained contract.
16. The method of claim 1, wherein a contract identity private key in the shared contract identity key is used to sign an execution result from executing the target down-link contract, and a contract identity public key in the shared contract identity key is used to encrypt import parameter data used when invoking the target down-link contract.
17. A method of generating a shared contract key, comprising:
any node in a privacy computing cluster determines a target intelligent contract which is deployed by the node, wherein the target intelligent contract is deployed at a plurality of nodes in the privacy computing cluster; wherein, in response to invocation by a client, the target smart contract is executable within a trusted execution environment created by each of the plurality of nodes;
and the any node operates on the sharing factors among the plurality of nodes and the global identification information of the target intelligent contract in the trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes to generate a shared contract identity key corresponding to the target intelligent contract, wherein the shared contract identity key is used for signing the execution result of the target intelligent contract in the trusted execution environment.
18. The method of claim 17, the common factor comprising a cluster identity key corresponding to the plurality of nodes, the cluster identity key being used to encrypt and decrypt interaction data and/or to sign a signature during interaction of the client with the plurality of nodes to deploy or invoke a smart contract.
19. The method of claim 18, the cluster identity key being generated within a trusted execution environment created by the any node; the any node sharing the cluster identity key to other nodes in the privacy computing cluster, including:
the any node acquires a first remote attestation report sent by the other node, wherein the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other node aiming at the created trusted execution environment;
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 of the other nodes 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 of the any node 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 created trusted execution environment.
20. The method of claim 19, the any node determining from the first remote attestation report that the trusted execution environment of the other node is trusted, comprising:
performing 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-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 trusted execution environment of the other node;
and comparing a first standard hash value of preset information in the trusted execution environment of the other node, which is obtained in advance, with the first hash value to be verified, and taking the comparison result as a precondition for confirming that the trusted execution environment of the other node is trusted.
21. The method of claim 19, the any node, prior to sending the cluster identity key to the other node, further comprising:
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 a trusted execution environment of the other node;
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.
22. The method of claim 19, 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 and other identity information of the any node;
the any node provides a third standard hash value for 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 a trusted execution environment of the any node;
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 keys 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 of the other nodes under the condition that the signature verification is passed.
23. The method of claim 18, the any node obtaining the cluster identity key, comprising:
the any node provides a second remote attestation report to other nodes in the private computing cluster, wherein 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 created trusted execution environment;
the any node receives the cluster identity key and a first remote attestation report which are sent by the other nodes under the condition that the trusted execution environment of the any node is determined to be trusted according to the second remote attestation report, wherein the cluster identity key is generated in the trusted execution environment created by the other nodes, and the first remote attestation report is generated by an authentication server after first self-referral information generated by the other nodes aiming at the created trusted execution environment is verified;
the any node approves the cluster identity key if it is determined that the first remote attestation report indicates that the trusted execution environment of the other node is trusted.
24. The method of claim 18, further comprising:
and when any node receives the target intelligent contract encrypted by the 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 trusted execution environment of any node and deploying the target intelligent contract.
25. The method of claim 24, the any node, prior to receiving the encrypted target smart contract, further comprising:
and providing a second remote certification report to a signing party in response to a challenge initiated by the signing party of the target intelligent contract, wherein the second remote certification report is generated by an authentication server after verifying second self-recommendation information generated by any node aiming at the created trusted execution environment, and the encrypted target intelligent contract is sent by the signing party under the condition that the trusted execution environment of any node is determined to be trusted according to the second remote certification report.
26. The method of claim 18, prior to the client initiating a call to the target smart contract deployed at the arbitrary node, the method further comprising:
the any node provides the cluster remote attestation report to the client, wherein the cluster remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node aiming at the created trusted execution environment;
providing to the client to-be-verified contract information of the target smart contract deployed at the any node, the to-be-verified contract information being signed by the any node within a trusted execution environment of the any node using 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 trusted execution environment of the any node;
and under the condition that the client determines that the trusted execution environment of any node is trusted according to the cluster remote attestation report, the client 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 determines that the target intelligent contract is executed by any node in the trusted execution environment of any node under the condition that the signature verification and the contract information verification pass.
27. The method of claim 26, wherein any node carried by the cluster remote attestation report includes a fourth hash value to be verified within second referral information generated for a created trusted execution environment, the fourth hash value to be checked is a hash value of preset information of the trusted execution environment of any node, the fourth hash value to be verified is used for the client to perform signature verification on the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote attestation report contains a remote authentication result that is authenticated, comparing with a fourth standard hash value of preset information in a trusted execution environment of the any node obtained in advance, and the consistency of the comparison result is used as a precondition that the client confirms that the trusted execution environment of any node is trusted.
28. The method of claim 26, further comprising:
the any node provides cluster identity information to the client, 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 client to obtain a fifth hash value to be verified;
the any node provides a fifth standard hash value to the client, 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 a trusted execution environment of the any node;
and the fifth standard hash value is used for comparing with the fifth hash value to be verified, and the client acquires the cluster identity public key contained in the cluster identity information under the condition that the comparison result is consistent.
29. The method of claim 18, further comprising:
the any node receives a calling transaction initiated by the client to the target intelligent contract, 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 privacy computation cluster and forwarded to the any node according to the load condition of the privacy computation cluster;
and the any node decrypts the calling transaction by adopting the cluster identity private key in the cluster identity key in the trusted execution environment of the any node so as to respond to the decrypted calling transaction to execute the target intelligent contract.
30. The method of claim 17, wherein a contract identity private key of the shared contract identity key is used to sign an execution result from executing the target smart contract, and wherein a contract identity public key of the shared contract identity key is used to encrypt import parameter data used when invoking the target smart contract.
31. An apparatus for generating a shared contract key, comprising:
a contract determining unit, which enables any node in the private computing cluster to determine a target under-link contract deployed by itself, wherein the target under-link contract is deployed at a plurality of nodes in the private computing cluster; wherein, in response to invocation of a block link point, the target down-link contract is executable within an down-link trusted execution environment created by each of the plurality of nodes;
and a contract key generation unit, which enables the any node to operate on a common factor among the plurality of nodes and global identification information of the target under-chain contract in the under-chain trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generates a shared contract identity key corresponding to the target under-chain contract, wherein the shared contract identity key is used for signing an execution result of the target under-chain contract in the under-chain trusted execution environment.
32. An apparatus for generating a shared contract key, comprising:
a contract determining unit, which enables any node in a privacy computing cluster to determine a target intelligent contract deployed by the node, wherein the target intelligent contract is deployed at a plurality of nodes in the privacy computing cluster; wherein, in response to invocation by a client, the target smart contract is executable within a trusted execution environment created by each of the plurality of nodes;
and a contract key generation unit which enables the any node to operate on the sharing factor among the plurality of nodes and the global identification information of the target intelligent contract in the trusted execution environment created by the any node through a key generation algorithm shared among the plurality of nodes, and generates a shared contract identity key corresponding to the target intelligent contract, wherein the shared contract identity key is used for signing the execution result of the target intelligent contract in the trusted execution environment.
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.
CN202010190878.1A 2020-03-18 2020-03-18 Method and device for generating shared contract key Active CN111092726B (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202010910443.XA CN112152800B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key
CN202010190878.1A CN111092726B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key
PCT/CN2021/073820 WO2021184962A1 (en) 2020-03-18 2021-01-26 Method and apparatus for generating shared contract key

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010190878.1A CN111092726B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202010910443.XA Division CN112152800B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key

Publications (2)

Publication Number Publication Date
CN111092726A true CN111092726A (en) 2020-05-01
CN111092726B CN111092726B (en) 2020-07-28

Family

ID=70400575

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202010190878.1A Active CN111092726B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key
CN202010910443.XA Active CN112152800B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202010910443.XA Active CN112152800B (en) 2020-03-18 2020-03-18 Method and device for generating shared contract key

Country Status (2)

Country Link
CN (2) CN111092726B (en)
WO (1) WO2021184962A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111818186A (en) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 Information sharing method and system
CN112184434A (en) * 2020-09-02 2021-01-05 上海树图区块链研究院 Block chain system, data interaction and processing method, node and storage medium
CN112465501A (en) * 2020-11-11 2021-03-09 中国人民大学 Copyright evidence storage and infringement behavior automatic evidence collection method and system based on block chain
CN112532385A (en) * 2020-11-20 2021-03-19 天翼电子商务有限公司 Data sharing method based on trusted execution environment
CN112926051A (en) * 2021-03-25 2021-06-08 支付宝(杭州)信息技术有限公司 Multi-party security computing method and device
CN113129017A (en) * 2020-08-31 2021-07-16 支付宝(杭州)信息技术有限公司 Information sharing method, device and equipment
WO2021184968A1 (en) * 2020-03-18 2021-09-23 支付宝(杭州)信息技术有限公司 Cluster key sharing method and device
WO2021184962A1 (en) * 2020-03-18 2021-09-23 支付宝(杭州)信息技术有限公司 Method and apparatus for generating shared contract key
CN113726733A (en) * 2021-07-19 2021-11-30 东南大学 Encryption intelligent contract privacy protection method based on trusted execution environment
CN115277259A (en) * 2022-09-27 2022-11-01 南湖实验室 Method for supporting large-scale cross-platform migration of persistent data through privacy calculation
CN112184434B (en) * 2020-09-02 2024-07-02 上海树图区块链研究院 Blockchain system, data interaction and processing method, node and storage medium

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113888163A (en) * 2021-09-24 2022-01-04 国网上海市电力公司 Intelligent contract bill recording and processing method based on completely homomorphic encryption
CN113761582B (en) * 2021-09-29 2023-06-16 山东省计算中心（国家超级计算济南中心） Group signature-based supervision blockchain transaction privacy protection method and system
CN113946864B (en) * 2021-10-15 2024-03-19 北京智融云河科技有限公司 Confidential information acquisition method, device, equipment and storage medium
CN114157415A (en) * 2021-10-15 2022-03-08 中国工商银行股份有限公司 Data processing method, computing node, system, computer device and storage medium
CN114117522B (en) * 2021-11-23 2024-05-28 上海交通大学 Internet of vehicles data sharing implementation method based on block chain and trusted execution environment
CN114329635B (en) * 2022-03-04 2022-06-21 杭州字节方舟科技有限公司 Privacy signature method based on multi-party security calculation and computer system
CN114553590B (en) * 2022-03-17 2023-08-22 抖音视界有限公司 Data transmission method and related equipment
CN114900534B (en) * 2022-03-29 2023-04-07 中南大学 Big data supervision method based on block chain technology
CN115412275A (en) * 2022-05-23 2022-11-29 蚂蚁区块链科技(上海)有限公司 Trusted execution environment-based private computing system and method
CN115065487B (en) * 2022-08-17 2022-12-09 北京锘崴信息科技有限公司 Privacy protection cloud computing method and cloud computing method for protecting financial privacy data
CN115484031B (en) * 2022-09-13 2024-03-08 山东大学 SGX-based trusted-free third-party cloud storage ciphertext deduplication method and system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109831298A (en) * 2019-01-31 2019-05-31 阿里巴巴集团控股有限公司 The method of security update key and node, storage medium in block chain
CN109978693A (en) * 2019-03-29 2019-07-05 上海点融信息科技有限责任公司 For carrying out the method, apparatus and medium of distributed signature in block chain network
CN110011801A (en) * 2018-11-16 2019-07-12 阿里巴巴集团控股有限公司 Remote certification method and device, the electronic equipment of trusted application
CN110520884A (en) * 2018-12-13 2019-11-29 阿里巴巴集团控股有限公司 Intelligent bond service outside chain based on credible performing environment
US10554401B1 (en) * 2019-07-05 2020-02-04 Crypto Mint Inc. Multi-address population based on single address
CN110750803A (en) * 2019-10-18 2020-02-04 支付宝(杭州)信息技术有限公司 Method and device for providing and fusing data

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10108954B2 (en) * 2016-06-24 2018-10-23 PokitDok, Inc. System and method for cryptographically verified data driven contracts
US10853772B2 (en) * 2018-04-04 2020-12-01 Vijay K. Madisetti Method and system for exchange of value or tokens between blockchain networks
CN109003078B (en) * 2018-06-27 2021-08-24 创新先进技术有限公司 Intelligent contract calling method and device based on block chain and electronic equipment
CN110032884B (en) * 2019-01-31 2020-04-17 阿里巴巴集团控股有限公司 Method for realizing privacy protection in block chain, node and storage medium
CN110264200B (en) * 2019-05-29 2021-11-19 中国工商银行股份有限公司 Block chain data processing method and device
CN110580413B (en) * 2019-11-08 2020-03-24 支付宝(杭州)信息技术有限公司 Private data query method and device based on down-link authorization
CN111092726B (en) * 2020-03-18 2020-07-28 支付宝(杭州)信息技术有限公司 Method and device for generating shared contract key

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110011801A (en) * 2018-11-16 2019-07-12 阿里巴巴集团控股有限公司 Remote certification method and device, the electronic equipment of trusted application
CN110520884A (en) * 2018-12-13 2019-11-29 阿里巴巴集团控股有限公司 Intelligent bond service outside chain based on credible performing environment
CN109831298A (en) * 2019-01-31 2019-05-31 阿里巴巴集团控股有限公司 The method of security update key and node, storage medium in block chain
CN109978693A (en) * 2019-03-29 2019-07-05 上海点融信息科技有限责任公司 For carrying out the method, apparatus and medium of distributed signature in block chain network
US10554401B1 (en) * 2019-07-05 2020-02-04 Crypto Mint Inc. Multi-address population based on single address
CN110750803A (en) * 2019-10-18 2020-02-04 支付宝(杭州)信息技术有限公司 Method and device for providing and fusing data

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
网友: ""蚂蚁区块链第10课 可信计算机及TEE硬件隐私合约链智能合约开发实践"", 《HTTPS://WWW.JIANSHU.COM/P/5DBB63A7C08D》 *

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021184968A1 (en) * 2020-03-18 2021-09-23 支付宝(杭州)信息技术有限公司 Cluster key sharing method and device
WO2021184962A1 (en) * 2020-03-18 2021-09-23 支付宝(杭州)信息技术有限公司 Method and apparatus for generating shared contract key
CN111818186B (en) * 2020-08-31 2022-02-25 支付宝(杭州)信息技术有限公司 Information sharing method and system
CN113129017A (en) * 2020-08-31 2021-07-16 支付宝(杭州)信息技术有限公司 Information sharing method, device and equipment
CN111818186A (en) * 2020-08-31 2020-10-23 支付宝(杭州)信息技术有限公司 Information sharing method and system
US11514445B2 (en) 2020-08-31 2022-11-29 Alipay (Hangzhou) Information Technology Co., Ltd. Information sharing methods, apparatuses, and devices
CN113129017B (en) * 2020-08-31 2022-06-24 支付宝(杭州)信息技术有限公司 Information sharing method, device and equipment
US11954686B2 (en) 2020-08-31 2024-04-09 Alipay (Hangzhou) Information Technology Co., Ltd. Information sharing methods and systems
CN112184434A (en) * 2020-09-02 2021-01-05 上海树图区块链研究院 Block chain system, data interaction and processing method, node and storage medium
CN112184434B (en) * 2020-09-02 2024-07-02 上海树图区块链研究院 Blockchain system, data interaction and processing method, node and storage medium
CN112465501A (en) * 2020-11-11 2021-03-09 中国人民大学 Copyright evidence storage and infringement behavior automatic evidence collection method and system based on block chain
CN112532385A (en) * 2020-11-20 2021-03-19 天翼电子商务有限公司 Data sharing method based on trusted execution environment
CN112926051A (en) * 2021-03-25 2021-06-08 支付宝(杭州)信息技术有限公司 Multi-party security computing method and device
CN113726733A (en) * 2021-07-19 2021-11-30 东南大学 Encryption intelligent contract privacy protection method based on trusted execution environment
CN113726733B (en) * 2021-07-19 2022-07-22 东南大学 Encryption intelligent contract privacy protection method based on trusted execution environment
CN115277259A (en) * 2022-09-27 2022-11-01 南湖实验室 Method for supporting large-scale cross-platform migration of persistent data through privacy calculation

Also Published As

Publication number Publication date
CN112152800A (en) 2020-12-29
CN111092726B (en) 2020-07-28
WO2021184962A1 (en) 2021-09-23
CN112152800B (en) 2022-05-13

Similar Documents

Publication Publication Date Title
CN111092727B (en) Method and device for sharing cluster key
CN111090888B (en) Contract verification method and device
CN111092726B (en) Method and device for generating shared contract key
CN111090875B (en) Contract deployment method and device
CN111090876B (en) Contract calling method and device
CN111090874B (en) Contract calling method and device
CN111092914B (en) Method and device for accessing external data
CN111541785B (en) Block chain data processing method and device based on cloud computing
WO2021184975A1 (en) Off-chain privacy calculation method and apparatus for on-chain data
CN111475849B (en) Private data query method and device based on blockchain account
CN110580413B (en) Private data query method and device based on down-link authorization
CN110580412B (en) Permission query configuration method and device based on chain codes
CN110580245B (en) Private data sharing method and device
CN111475850B (en) Intelligent contract-based privacy data query method and device
CN110580411B (en) Permission query configuration method and device based on intelligent contract

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40028999

Country of ref document: HK