WO2021184963A1 - 调用合约的方法及装置 - Google Patents
调用合约的方法及装置 Download PDFInfo
- Publication number
- WO2021184963A1 WO2021184963A1 PCT/CN2021/073846 CN2021073846W WO2021184963A1 WO 2021184963 A1 WO2021184963 A1 WO 2021184963A1 CN 2021073846 W CN2021073846 W CN 2021073846W WO 2021184963 A1 WO2021184963 A1 WO 2021184963A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- chain
- identity
- computing node
- data
- contract
- 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.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
Definitions
- One or more embodiments of this specification relate to the field of verifiable computing technology, and in particular, to a method and device for invoking a contract.
- TEE Trusted Execution Environment
- TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped, and only the pre-defined interface in the code can operate on it.
- plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption, and there is no loss in the efficiency of the calculation process.
- one or more embodiments of this specification provide a method and device for invoking a contract.
- a method for invoking a contract which includes: a data user generates a call request for an off-chain contract, and the call request includes encrypting the target plaintext data The obtained target ciphertext data and a verifiable statement of the right to use the target plaintext data; the data user submits the data to the off-chain privacy computing node deployed with the off-chain contract through the oracle mechanism of the blockchain
- the invocation request, the invocation request is used to instruct the off-chain private computing node to execute the off-chain contract in an off-chain trusted execution environment created by the off-chain private computing node when the invocation conditions are met
- the calling condition includes determining that the data owner of the target plaintext data grants the use right to the data user according to the verifiable statement.
- a method for invoking a contract which includes: the off-chain privacy computing node receives data submitted by the user through the oracle mechanism of the blockchain for the off-chain privacy
- a call request for an off-chain contract deployed by a computing node, the call request includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data; the off-chain privacy
- the computing node executes the off-chain contract in the off-chain trusted execution environment created by the off-chain private computing node to process the target plaintext data when the invocation condition is met, and the invocation condition includes The verifiable statement determines that the data owner of the target plaintext data grants the use right to the data user.
- a method for invoking a contract which includes: a data user generates a call request for a smart contract, and the call request includes the data obtained by encrypting the target plaintext data.
- a method for invoking a contract which includes: a private computing node receives a request for invoking a smart contract deployed by the private computing node submitted by a data user, and The call request includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data; the privacy computing node performs the privacy calculation on the condition that the calling conditions are met.
- the smart contract is executed in the trusted execution environment created by the node to process the target plaintext data, and the calling condition includes determining the data owner of the target plaintext data according to the verifiable statement to the data user The right to use was granted.
- a device for invoking a contract including: a generating unit that enables a data user to generate a call request for an off-chain contract, and the call request includes The target ciphertext data obtained by encrypting the plaintext data and the verifiable statement of the right to use the target plaintext data; the submission unit enables the data user to deploy the off-chain contract through the oracle mechanism of the blockchain.
- the off-chain private computing node submits the invocation request, and the invocation request is used to instruct the off-chain private computing node to perform trusted execution under the chain created by the off-chain private computing node when the invocation conditions are met.
- the off-chain contract is executed in the environment to process the target plaintext data, and the invocation condition includes determining that the data owner of the target plaintext data grants the use to the data user according to the verifiable statement right.
- a device for invoking a contract is proposed.
- the invocation request of the off-chain contract deployed by the off-chain privacy computing node includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data; execution; Unit to enable the off-chain private computing node to execute the off-chain contract in the off-chain trusted execution environment created by the off-chain private computing node to process the target plaintext data when the calling conditions are met
- the calling condition includes determining that the data owner of the target plaintext data grants the use right to the data user according to the verifiable statement.
- a device for invoking a contract which includes: a generating unit that enables a data user to generate a call request for a smart contract, and the call request includes a clear text for the target The target ciphertext data obtained by data encryption and a verifiable statement of the right to use the target plaintext data; a submission unit that causes the data use to submit the call request to the privacy computing node where the smart contract is deployed, so The call request is used to instruct the private computing node to execute the smart contract in the trusted execution environment created by the private computing node to process the target plaintext data when the calling conditions are met.
- the calling condition includes determining that the data owner of the target plaintext data grants the use right to the data user according to the verifiable statement.
- a device for invoking a contract which includes: a receiving unit that enables a private computing node to receive a call to a smart contract deployed by the private computing node submitted by a data user Request, the calling request includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data; the execution unit makes the privacy computing node meet the calling conditions
- the calling condition includes determining the target plaintext data according to the verifiable statement The data owner granted the use right to the data user.
- an electronic device including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions In order to realize the method as described in the first aspect, the second aspect, the third aspect or the fourth aspect.
- a computer-readable storage medium is provided with computer instructions stored thereon.
- the instructions are executed by a processor, the first aspect, the second aspect, and the third aspect are implemented. Aspect or the steps of the method of the fourth aspect.
- Fig. 1 is a flowchart of a method for verifying an off-chain contract according to an exemplary embodiment.
- Fig. 2 is a schematic diagram of a scenario of a method for verifying an off-chain contract provided by an exemplary embodiment.
- Fig. 3 is a schematic diagram of a scenario of a method for verifying an off-chain contract provided by an exemplary embodiment.
- Fig. 4 is a flowchart of a method for invoking a contract on the data consumer side according to an exemplary embodiment.
- Fig. 5 is a schematic diagram of a scene of a method for invoking a contract provided by an exemplary embodiment.
- Fig. 6 is a flowchart of creating a DID provided by an exemplary embodiment.
- Fig. 7 is a flowchart of a data authorization process provided by an exemplary embodiment.
- Fig. 8 is a flowchart of another method for invoking a contract provided by an exemplary embodiment.
- Fig. 9 is a flowchart of a method for invoking a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment.
- Fig. 10 is a flowchart of another method for invoking a contract on the data consumer side provided by an exemplary embodiment.
- Fig. 11 is a flowchart of another method for invoking a contract on the side of a privacy computing node provided by an exemplary embodiment.
- Fig. 12 is a schematic structural diagram of a device according to an exemplary embodiment.
- Fig. 13 is a block diagram of an apparatus for invoking a contract on the data consumer side according to an exemplary embodiment.
- Fig. 14 is a block diagram of an apparatus for invoking a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment.
- Fig. 15 is a block diagram of another device for invoking a contract on the side of a data user provided by an exemplary embodiment.
- Fig. 16 is a block diagram of another device for invoking a contract on the side of a privacy computing node provided by an exemplary embodiment.
- the steps of the corresponding method may not be executed in the order shown and described in this specification.
- the method may include more or fewer steps than described in this specification.
- a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe. It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
- first information may also be referred to as second information
- second information may also be referred to as first information.
- word "if” as used herein can be interpreted as "when” or “when” or "in response to determination”.
- Block chains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
- the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, etc., and each participant (ie, node) can freely join and Exit the network.
- the private chain is the opposite.
- the network's data write permission is controlled by an organization or institution, and the data read permission is regulated by the organization; in simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes.
- consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization".
- Each node in the alliance chain usually has a corresponding entity or organization, and participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.
- blockchain nodes can create a TEE and realize the TEE as a secure execution environment for blockchain transactions.
- TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside.
- TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. At present, the industry is very concerned about TEE solutions.
- TEE solutions such as TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor), etc.
- Blockchain nodes can create enclaves (enclaves or enclaves) based on SGX technology to serve as TEEs for executing blockchain transactions.
- the blockchain node uses the newly added processor instructions in the CPU to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory to reside in the above-mentioned enclave.
- the memory area corresponding to the above EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU.
- MEE Memory Encryption Engine
- the content in the memory area can only be decrypted in the CPU core and used for encryption and decryption.
- the key is only generated and stored in the CPU when the EPC is started.
- the security boundary of the enclave only includes itself and the CPU, and neither privileged or non-privileged software can access the enclave, even the operating system administrator and VMM (virtual machine monitor, or Hypervisor).
- VMM virtual machine monitor, or Hypervisor
- Every blockchain transaction on the blockchain needs to be executed on all blockchain nodes in the blockchain network to ensure that each blockchain node is maintained
- the blockchain ledger data is consistent. If the transaction logic is relatively simple, such as Bitcoin as an example, the blockchain transaction is only used to realize the transfer operation. At this time, even if the blockchain transaction needs to be executed on all blockchain nodes, it will not cause excessive resource consumption. . However, if the blockchain provides the function of a smart contract, and the blockchain transaction calls the smart contract, then the situation may be quite different.
- a smart contract on the blockchain is a contract that can be triggered by a transaction to execute on the blockchain system, and the smart contract can be defined in the form of code.
- EVM Ethereum Virtual Machine
- Every Ethereum node can run EVM.
- EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it.
- Users who publish and call smart contracts in Ethereum run on the EVM.
- virtual machine code virtual machine bytecode, hereinafter referred to as "bytecode"
- the smart contract is divided into two stages: deployment and invocation.
- the user sends a transaction containing information about creating a smart contract to the Ethereum network.
- the data field of the transaction contains the code (such as bytecode) of the smart contract, and the to field of the transaction is empty.
- Each node in the Ethereum network executes this transaction through the EVM and generates a corresponding contract instance.
- the smart contract corresponding to the above transaction is successfully created, and a contract account corresponding to the smart contract appears on the blockchain.
- the contract account has a specific contract address and contract code (i.e., smart contract).
- the code) or the hash value of the contract code is stored in the contract account, and the contract code is used to control the behavior of the corresponding smart contract.
- the user (which can be the same or different from the user who deployed the smart contract) sends a transaction for invoking the smart contract to the Ethereum network.
- the from field of the transaction is the address of the external account corresponding to the user, and the to field is The contract address of the smart contract to be called.
- the data field contains the method and parameters for calling the smart contract.
- EVM is a Turing complete virtual machine; similarly, other blockchains can also use other types of virtual machines, such as WASM (WebAssembly) virtual machines.
- WASM WebAssembly
- the process of executing the code of the smart contract by the node through the virtual machine consumes relatively more computing resources, and because all nodes in the blockchain network need The code that executes the smart contract, so as the number of nodes increases, the consumption of computing resources will increase exponentially. Therefore, although the combination of TEE technology can relatively reduce the resource consumption of a single blockchain node and speed up transaction execution efficiency, it will still cause great resource consumption and waste for the entire blockchain network.
- this manual proposes to deploy private computing nodes (ie, off-chain private computing nodes) under the chain, which can transfer the computing operations that originally needed to be performed on all blockchain nodes to the off-chain private computing nodes for execution.
- the chain node only needs to obtain the calculation result from the off-chain private computing node and update the blockchain ledger data based on the calculation result, and can prove that the above calculation result is indeed in a credible execution based on the verifiable computation (Verifiable Computation) technology
- the environment is executed as expected, which greatly reduces the resource consumption on the chain while ensuring reliability.
- the blockchain node can execute the code of the smart contract to achieve corresponding computing requirements; similarly, the code for performing computing tasks can be deployed off-chain
- the off-chain private computing node can execute code to achieve corresponding computing requirements.
- the contract deployed on the blockchain node is called the on-chain contract
- the contract deployed on the off-chain privacy computing node is called the off-chain contract; of course, whether it is an on-chain contract or an off-chain contract, Its essence is a piece of code that can be executed in a virtual machine.
- a single-node form of off-chain private computing nodes can be configured to perform computing tasks; alternatively, users can be provided with high-concurrency and highly available private computing services in the form of off-chain private computing clusters, thereby solving node load balancing, failover, and Issues such as dynamic expansion and shrinkage.
- the off-chain privacy computing cluster may include a control node and multiple off-chain privacy computing nodes, each node is used to deploy the same off-chain contract (at least one) to perform computing tasks, and the control node will All off-chain privacy computing nodes are managed uniformly.
- off-chain TEE ie, off-chain trusted execution environment
- the off-chain TEE is based on a trusted execution environment implemented by CPU hardware that is completely isolated from the outside.
- the off-chain privacy computing node can implement the deployment operation of the off-chain contract and the call execution operation after deployment through the off-chain TEE, and ensure data security and privacy protection during the operation.
- an off-chain contract can be deployed on an off-chain private computing node
- a WASM virtual machine can be deployed in an off-chain TEE created by the off-chain private computing node.
- the user can initiate a WASM program-based calculation task to the off-chain private computing node, which is used to call the off-chain contract to calculate the target data (that is, the target data is the input data of the off-chain contract). Then the off-chain private computing node can read the off-chain contract into the off-chain TEE and compile it into WASM bytecode, use the WASM virtual machine as the execution engine, and execute the compiled WASM bytecode in the WASM virtual machine to correct Target data is calculated. It should be noted that the off-chain contract in this manual can implement any calculation logic defined by the user.
- the off-chain contract can be used to verify whether the amount of encrypted order data stored on the blockchain is correct, and the verification result is fed back to the chain; for another example, the off-chain contract can be used to secure multi-party data according to a preset algorithm Calculations are safe multi-party calculations, and the calculation results are fed back to the chain, etc., so I won’t repeat them here.
- the client Before the data user calls the off-chain contract through the client, he can challenge the off-chain contract deployed in the off-chain private computing node to ensure that the off-chain contract deployed in the off-chain private computing node is credible, and then perform calculations according to user expectations Task.
- Fig. 1 is a flowchart of a method for verifying an off-chain contract according to an exemplary embodiment. As shown in Fig. 1, the method may include steps 102-106.
- Step 102 The data user obtains a remote certification report for the off-chain trusted execution environment.
- the remote certification report is generated by the authentication server on the off-chain private computing node for the off-chain trusted execution environment. Self-recommendation information is generated after verification.
- the off-chain privacy computing node includes two forms: a single node and an off-chain privacy computing cluster.
- the data user directly initiates a challenge to the off-chain private computing node to receive the remote attestation report returned by the off-chain private computing node.
- the identity information of the off-chain private computing node is the node identity information of the off-chain private computing node
- the identity private key of the off-chain private computing node is the node identity private key of the off-chain private computing node
- the identity public key of the computing node is the node identity public key of the private computing node under the chain.
- the data usage direction initiates a challenge to the control node of the off-chain private computing cluster, and the control node selects the off-chain private computing cluster To respond to the challenge, obtain the remote certification report of the selected node, and return the remote certification report to the data user.
- the off-chain private computing node interacts with external objects on behalf of the off-chain private computing cluster. Therefore, the identity information of the off-chain private computing node is the cluster identity information of the off-chain private computing cluster, and the identity public key of the off-chain private computing node is the cluster identity public key in the cluster identity key of the off-chain private computing cluster.
- the identity private key of the off-chain privacy computing node is the cluster identity private key in the cluster identity key.
- the cluster identity key is used to encrypt and decrypt the interactive data and/or verify the signature.
- the control node of the off-chain privacy computing cluster can select any node in the cluster as the master node to generate the cluster identity key, and share the cluster identity key with other nodes in the cluster.
- Step 104 The data user obtains the pending verification of the off-chain contract deployed at the off-chain privacy computing node under the condition that the off-chain trusted execution environment is determined to be credible according to the remote attestation report Contract information, the contract information to be verified is signed by the off-chain private computing node in the off-chain trusted execution environment using the identity private key of the off-chain private computing node, and the identity private key is signed by the The off-chain private computing nodes are maintained in the off-chain trusted execution environment.
- the remote attestation report is generated from the remote attestation process for the off-chain TEE on the off-chain private computing node.
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommended information is related to the off-chain TEE created on the off-chain private computing node.
- the off-chain private computing node generates the self-recommended information related to the off-chain TEE, and the authentication server verifies the self-recommended information to generate a remote attestation report, so that the remote attestation report can be used to indicate the off-chain TEE on the off-chain private computing node Trustworthy.
- the remote attestation report is generated by the authentication server after verifying the self-recommended information generated by the off-chain private computing node for its own off-chain TEE.
- the off-chain TEE is an enclave created on the off-chain private computing node to implement off-chain privacy computing.
- the remote attestation process also involves another special enclave on the off-chain private computing node, namely quoting enclave (QE for short), QE is an architectural enclave (Architectural Enclave) provided and signed by Intel.
- the above enclave first needs to generate a REPORT structure for local authentication, and QE verifies whether the enclave is on the same platform as itself based on the REPORT structure, and then QE encapsulates the REPORT structure into a structure QUOTE (ie Self-recommended information), and use the EPID (enhanced privacy identification) key to sign.
- the EPID key not only represents the platform of the off-chain private computing node, but also represents the credibility of the underlying hardware of the off-chain private computing node. It can also bind information such as the version of the processor firmware, and only QE can access the EPID key. , To sign the above-mentioned structure QUOTE.
- the above authentication server can be the IAS (Intel Attestation Service) server provided by Intel.
- the off-chain privacy computing node sends the signed structure QUOTE to the IAS server, so that the IAS server can verify the signature and Return the corresponding remote certification report to the off-chain privacy computing node.
- the data user can verify whether the corresponding off-chain private computing node is credible according to the remote attestation report, which specifically refers to verifying the off-chain TEE deployed on the off-chain private computing node Whether it is credible, and when it is determined that the off-chain TEE is credible, the off-chain contract deployed at the off-chain privacy computing node (executed in the trusted off-chain TEE) is further verified.
- the remote attestation report specifically refers to verifying the off-chain TEE deployed on the off-chain private computing node Whether it is credible, and when it is determined that the off-chain TEE is credible, the off-chain contract deployed at the off-chain privacy computing node (executed in the trusted off-chain TEE) is further verified.
- the off-chain private computing node After the off-chain private computing node creates the off-chain TEE, it generates self-recommendation information for remote attestation.
- the self-recommendation information can be used to anchor and solidify the information of the off-chain TEE, so that the final result contains the self-recommendation information.
- the remote attestation report can be used to characterize the status of the off-chain TEE and to verify whether the off-chain TEE is trustworthy.
- the self-recommendation information may include the first hash value to be verified, and the first hash value to be verified is the hash value of the preset information in the off-chain TEE.
- the preset information may include all deployed in the off-chain TEE.
- the code, the public key of the developer of the TEE under the chain, etc. Taking Intel SGX technology as an example, the hash value generated by all codes deployed in the off-chain TEE is MREnclave, and the hash value generated by the developer’s public key corresponding to the off-chain TEE is MRSigner, which is the first waiting
- the verification hash value can include MREnclave and MRSigner.
- the IAS server performs signature verification based on the maintained public key set, and returns a remote certification report (that is, AVR) to the off-chain privacy computing node.
- Report contains: the structure QUOTE and the signature verification result, and the IAS server uses its own private key to sign the remote attestation report.
- the data user can first verify the remote attestation report according to the public key of the IAS server. If the verification is passed, it means that the remote attestation report is indeed generated by the IAS server, and during the data transmission process Has not been tampered with or lost data.
- the data user can obtain the public key of the IAS server through any means. For example, when the remote attestation report is provided to the data user, it can also be associated with the certificate chain that provides the IAS, so that the data user can extract the public key of the IAS server from the certificate chain. key. Then, the data user can extract the structure QUOTE and the signature verification result from the remote attestation report. The data user can first view the signature verification result.
- the off-chain TEE is established on a reliable hardware platform and can continue to execute Other verification operations: If the signature verification result is that the verification fails, the data user can determine that the off-chain privacy computing platform is unreliable, and there is no need to continue other verification operations.
- the data user can extract the above-mentioned hash values MREnclave and MRSigner from the structure QUOTE, that is, the MREnclave to be verified and the MRSigner to be verified; at the same time, the data user has obtained the first standard of the above-mentioned preset information of the off-chain TEE in advance
- the hash value for example, is the trusted value of MREnclave and MRSigner (hereinafter referred to as trusted MREnclave and trusted MRSigner), and compares the MREnclave to be tested with the trusted MRSigner, and compares the MRSigner to be tested with the trusted MRSigner.
- the data user can use "the MREnclave to be tested is consistent with the trusted MREnclave, and the MRSigner to be tested is consistent with the trusted MRSigner" as a prerequisite to confirm the authenticity of the TEE under the chain; in other words, if the MREnclave to be tested is inconsistent with the trusted MREnclave, Or if the MRSigner to be checked is inconsistent with the trusted MRSigner, the data user determines that the off-chain TEE of the privacy computing node under the chain is not trusted, and if all the preconditions set by the data user are met, the off-chain privacy can be confirmed The off-chain TEE of the computing node is trustworthy. In addition, there is no necessary sequence between the operation of the data user to verify the signature verification result and the operation of verifying the MREnclave to be verified and the MRSigner to be verified, and the two can be completely independent.
- data users can also verify the credibility of off-chain private computing nodes through other preconditions. For example, after an off-chain private computing node creates an off-chain TEE, it can generate a key pair representing its own identity information in the off-chain TEE, and the off-chain private computing node creates its own node identity information in the off-chain TEE.
- the node identity information is related to the aforementioned key pair corresponding to the identity information.
- the node identity information may include the public key in the key pair (ie, the node identity public key). Among them, there can be one or more sets of key pairs representing identity information.
- the node identity information may include the signature public key in the signature key pair and the encryption public key in the encryption key pair. In a set of key pairs, corresponding to different encryption algorithms, there may be multiple public keys at the same time, and these public keys are all included in the above-mentioned node identity information.
- the node identity information may also include other information related to the off-chain private computing node (ie, other identity information), such as software version, domain name, partition name, etc. This specification does not limit this.
- the off-chain privacy computing node After the off-chain privacy computing node generates node identity information in its own off-chain TEE (for example, generated when the off-chain TEE is initialized), the generated node identity information can be hashed to obtain the second standard hash value.
- the second standard hash value can be added to the structure QUOTE.
- the data user can perform signature verification from the remote certification report.
- the data user can extract the signature verification result and the second standard hash value contained in the remote attestation report, and verify the signature verification result, and use the second standard hash value to verify the privacy computing node under the chain Whether the identity information of the node is correct, and there is no inevitable sequence between the two verification steps, and the two can be completely independent. It is assumed that the data user first verifies the signature verification result, and continues to use the second standard hash value to verify the node identity information of the off-chain private computing node when the signature verification result is passed.
- the data user In order to verify the node identity information of the off-chain private computing node, the data user needs to obtain the node identity information of the off-chain private computing node. For example, when the remote certification report is provided to the data user, the node identity information can be provided in association. Of course The data user can also obtain the node's identity information in other ways or at other times. Then, the data user can perform a hash calculation on the obtained node identity information to obtain a second hash value to be verified, and compare the calculated second hash value to be verified with the above-mentioned second standard hash value, The consistency of the comparison results is used as a prerequisite for confirming the trustworthiness of the private computing nodes under the chain.
- the second hash value to be verified passes the verification, it can be proved that the obtained node identity information is exactly the node identity information generated by the off-chain privacy computing node in its own off-chain TEE. Then, the private key in the key pair representing the identity information is only owned by the off-chain private computing node, and the off-chain private computing node can complete operations such as signing and encrypting communication.
- the above 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; or, in some cases, only the node identity information may be verified, and the first hash value to be verified may not be verified or partially verified.
- the data user can set a trust level, and determine whether to verify or partially verify the first hash value to be verified according to the trust level.
- the trust level is 0, there is no need to verify the first hash value to be verified, and the trust level is At 1:00, verify the MRSigner in the first hash value to be verified.
- the trust level is 2, verify the MREnclave in the first hash value to be verified.
- the node identity information includes information related to the identity of the off-chain private computing node, such as the node identity public key representing the identity of the node.
- the node identity information can also include information related to the off-chain TEE. Then, after the off-chain privacy computing node generates the node identity information in its own off-chain TEE, the generated node identity information is hashed to obtain the hash value, and When the hash value is added to the structure QUOTE, the hash value is equivalent to simultaneously realizing the functions of the first hash value to be checked and the second standard hash value.
- the node identity information can also include the values of MREnclave and MRSigner, so that the hash value obtained by the hash calculation of the node identity information is also related to the off-chain privacy calculation.
- the identity of the node is related to the off-chain TEE.
- the data user can perform signature verification from the remote certification report.
- the data user can extract the signature verification result and the hash value contained in the remote certification report, and verify the signature verification result, and use the hash value to verify the node identity information of the private computing node under the chain Whether it is correct, and there is no inevitable sequence between the two verification steps, and the two can be completely independent. It is assumed that the data user first verifies the signature verification result, and continues to use the hash value to verify the node identity information of the off-chain private computing node when the signature verification result is passed verification. In order to verify the node identity information of the off-chain private computing node, the data user needs to obtain the node identity information of the off-chain private computing node, which will not be repeated here.
- the data user can perform a hash calculation on the obtained node identity information to obtain the hash value to be verified, and compare the calculated hash value to be verified with the hash value contained in the above remote certification report, and The consistency of the comparison result is used as a prerequisite for confirming the trustworthiness of the off-chain private computing node. It can be seen that this embodiment only needs one comparison to realize the verification in the two aspects mentioned above, which helps to improve the verification efficiency.
- the verification process of the remote attestation report by the data user can also include other operations, such as determining whether the off-chain TEE is running in test mode (there is a risk of data leakage in test mode) based on the content of the remote attestation report, etc. I will not repeat them here.
- Step 106 The data user uses the identity public key of the off-chain privacy computing node to verify the contract information to be verified, and contract the contract information to be verified based on the contract information of the off-chain contract Information verification, and when the signature verification and contract information verification are passed, it is determined that when the data user initiates a call to the off-chain contract through the oracle mechanism, the off-chain contract is protected by the off-chain privacy
- the computing node executes in the trusted execution environment under the chain.
- the cluster identity key may include a cluster encryption key pair and a cluster signature key pair.
- Each private computing node under the chain needs to maintain the cluster encryption private key and the cluster signature private key in its own chain TEE.
- the first identity information provided by the off-chain private computing node is the node identity information of the off-chain private computing node (not including the node identity private key)
- the identity public key is the node identity public key of the private computing node under the chain
- other identity information is the identity information of other nodes of the private computing node under the chain, that is, the node identity information Other node identity information except the node identity public key.
- the first identity information provided by the off-chain private computing node is the cluster identity information of the off-chain private computing cluster
- the identity public key is the cluster identity public key of the off-chain private computing cluster
- other identity information is the above-mentioned other node identity information.
- the second identity information of the off-chain private computing node on the basis of the first identity information, it also contains the hash value of the preset information of the off-chain trusted execution environment, and the other content is the same, so I won’t repeat it here. .
- the challenge process of single node form and cluster form will be described in detail below with reference to Figure 2-3.
- the client 21 of the data user can initiate an off-chain challenge or an on-chain challenge to the off-chain private computing node 22.
- the process of initiating an on-chain challenge can include three steps: Step 1, the client 21 submits to the blockchain network 23 a transaction for initiating a challenge to the off-chain contract, such as a challenge transaction.
- a certain node 23n in the blockchain network 23 receives and executes; step 2, the node 23n calls the pre-deployed oracle contract, which can transmit the challenge information contained in the above-mentioned challenge transaction to the oracle server 24 under the chain
- the oracle contract can generate events containing the challenge information, and the oracle server 24 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 24 sends the challenge information through the off-chain channel Send to the control node 22.
- the client 21 can obtain the remote attestation report for the off-chain TEE created by the off-chain private computing node 22.
- the remote attestation report is calculated by the authentication server on the off-chain privacy calculation.
- the node 22 generates after verifying the self-recommendation information generated by the off-chain TEE.
- the client 21 initiates a challenge to the off-chain private computing node 22, and the challenge target is the off-chain contract deployed by the off-chain private computing node 22, and then receives all the off-chain private computing node 22 returned in response to the challenge.
- the remote certification report and the contract information to be verified responds to the challenge and returns the remote certification report and the contract information to be verified to the client 21 at one time.
- the client 21 initiates a challenge to the off-chain private computing node 22, the challenge target is the off-chain TEE created by the off-chain private computing node 22, and then receives the remote attestation report returned by the off-chain private computing node 22,
- the off-chain privacy computing node 22 is sent to the off-chain privacy computing node 22 an acquisition request for the contract information of the off-chain contract deployed at the off-chain privacy computing node 22, and receiving The off-chain privacy computing node 22 returns the contract information to be verified in response to the acquisition request.
- the off-chain TEE is determined to be untrustworthy according to the remote attestation report, there is no need to request the off-chain privacy computing node 22 for contract information of the
- the client 21 can initiate a challenge to the challenge target through an on-chain challenge. For example, submit a challenge transaction for the challenge target to the blockchain node 23n, and the challenge information contained in the challenge transaction is transmitted to the off-chain private computing node 22 by the blockchain node 23n through the oracle mechanism, and the challenge information is used to challenge The goal initiates a challenge.
- the client 21 directly initiates an off-chain challenge to the challenge target in the off-chain privacy computing node 22.
- the generated node identity information can be hashed to obtain the second standard hash value; wherein, the generated node identity information includes the node identity public key of the off-chain private computing node 22 and other identity information of the off-chain private computing node 22.
- the client 21 can use the second standard hash value to verify the first node identity information provided by the off-chain private computing node 22 (that is, the declared node identity information, including the node identity public key of the off-chain private computing node 22 and the off-chain
- the other identity information of the private computing node 22 may not necessarily be real data.
- the identity information to be verified if the verification is passed, the node contained in the node identity information of the private computing node 22 under the verifiable chain is obtained.
- the identity public key is used to complete the subsequent verification of the off-chain contract by using the node’s identity public key.
- the client 21 performs a hash calculation on the acquired identity information of the first node to obtain the second hash value to be verified, and compares the second hash value to be verified with the second hash value provided by the off-chain privacy computing node 22. The standard hash values are compared, and if the comparison results are consistent, it is determined that the node identity information verification is passed.
- the node identity information is generated by the off-chain privacy computing node 22 in the off-chain TEE and calculated to obtain the second standard hash value, after determining the authenticity of the off-chain TEE according to the remote attestation report, if the second hash value to be verified
- the first node identity information provided by the private computing node 22 is the node identity information generated in the off-chain TEE, so that the node identity public key contained therein is the actual node of the private computing node 22
- the identity public key, and the actual node identity public key of the off-chain private computing node 22 can be used to verify the signature of the private computing node 22.
- the off-chain privacy computing node 22 can send the second standard hash value, the remote certification report, and the identity information of the first node to the client 21 together. It should be noted that this part of the content can refer to the verification process for the off-chain privacy computing node in the aforementioned step 104, which will not be repeated here.
- the off-chain private computing node 22 generates its own node identity information in the off-chain TEE, including the node identity public key of the off-chain private computing node 22, and the off-chain private computing node 22.
- Other identity information and the hash value of the preset information of the off-chain TEE after the off-chain privacy computing node 22 generates the node identity information in its own off-chain TEE, the generated node identity information is hashed to obtain the third standard Hash value, then the third standard hash value is equivalent to simultaneously achieving the functions of the first to-be-checked hash value and the second standard hash value.
- the off-chain privacy computing node 22 can provide the client 21 with a remote certification report, a third standard hash value, and second node identity information (this can be understood as the identity information to be verified).
- the second node identity information includes the node identity public key of the off-chain privacy computing node 22, other identity information of the off-chain privacy computing node 22, and the fourth hash value to be verified, and the fourth hash value to be verified is the chain
- the hash value of the preset information of the lower TEE; at the same time, the second node identity information is the declared node identity information, not necessarily the real node identity information of the off-chain private computing node 22.
- the client 21 performs signature verification on the remote attestation report according to the public key of the authentication server, and when the signature verification is passed and the remote attestation result contained in the remote attestation report is authenticated, the obtained second node identity
- the information is hashed to obtain the third hash value to be verified, and the third hash value to be verified is compared with the third standard hash value.
- the comparison result is consistent, it means that the second node identity information provided by the privacy computing node 22 is the node identity information generated in the off-chain TEE, that is, the fourth hash value to be verified is the actual value of the off-chain TEE.
- the hash value of the preset information is consistent.
- the pre-obtained fourth standard hash value for the preset information of the off-chain TEE is further compared with the fourth hash value to be verified, and the comparison result is consistent as a prerequisite for confirming the authenticity of the off-chain TEE condition.
- the node identity public key included in the second node identity information can be determined as the actual node identity public key of the privacy computing node 22, which can be used to perform signature verification on the contract information to be verified.
- the off-chain privacy computing node 22 can send the third standard hash value, the remote certification report, and the identity information of the second node to the client 21 together. It should be noted that this part of the content can refer to the verification process for the off-chain privacy computing node in the aforementioned step 104, which will not be repeated here.
- the client 21 determines that the off-chain TEE is trustworthy according to the remote attestation report, it obtains the contract information to be verified of the off-chain contract deployed at the off-chain private computing node 22, and the to-be-verified contract information is accessed by the off-chain private computing node 22.
- the off-chain TEE uses its own node identity private key for signing, and the node identity private key is generated by the off-chain privacy computing node 22 in the off-chain TEE.
- the off-chain privacy computing node 22 can read the deployed off-chain contract into the off-chain TEE and sign it with its own node identity private key.
- the client 21 uses the node identity public key of the off-chain private computing node 22 to perform signature verification on the contract information to be verified, and to perform contract information verification on the contract information to be verified based on the contract information of the off-chain contract.
- the node identity public key is in a public state, for example, the off-chain privacy computing node 22 publicly releases the node identity public key to the client 21 to obtain it.
- the client 21 obtains the node identity information of the private computing node 22 under the above-mentioned verification chain.
- the contract information of the off-chain contract can also be in a public state, for example, the deployment of the off-chain contract publicly releases the contract information to the client 21 to obtain it.
- the contract information may include the name, description, version number, bytecode hash value, contract identity public key and other information of the off-chain contract, which is not restricted in this specification.
- the client 21 can determine that when the client 21 initiates a call to the off-chain contract through the oracle mechanism of the blockchain node, the off-chain contract is registered by the off-chain privacy computing node 22 Execute in the trusted execution environment of the off-chain TEE.
- the process of verifying the off-chain contract in this manual is to first verify that the off-chain TEE of the off-chain private computing node 22 is trusted.
- the off-chain TEE of the off-chain private computing node 22 is trusted, if the signature is verified to be off-chain
- the contract information to be verified provided by the privacy computing node 22 is indeed signed by the node identity private key (maintained in the off-chain TEE) of the off-chain privacy computing node 22, and it can be determined that the currently challenged off-chain contract is running in off-chain privacy computing
- the off-chain contract in the off-chain TEE of the node 22 ensures that the off-chain contract deployed in the off-chain private computing node 22 is credible and can perform computing tasks as expected by the user.
- the client 31 can initiate an off-chain challenge or an on-chain challenge to the control node 32.
- the process of initiating a challenge on the chain can include three steps: Step 1, the client 31 submits to the blockchain network 33 a transaction for initiating a challenge to the off-chain contract, for example, it is called a challenge transaction.
- a certain node 33n in the block chain network 33 receives and executes; step 2, the node 33n calls the pre-deployed oracle contract, which can transmit the challenge information contained in the above-mentioned challenge transaction to the oracle server 34 under the chain
- the oracle contract can generate events containing the challenge information, and the oracle server 34 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 34 sends the challenge information through the off-chain channel Send to the control node 32.
- the off-chain privacy computing cluster as a whole provides the function of performing computing tasks.
- each node in the cluster is deployed with the same off-chain contract, then each node can perform computing tasks on behalf of the cluster, for example, the computing tasks can be distributed by the control node. Therefore, when each node interacts with the outside on behalf of the cluster, it uses the cluster identity key representing the identity of the cluster to decrypt or sign the data interacting with the outside, instead of using the node identity key of the node itself.
- an external object interacts with the cluster through the client, it regards the cluster as a whole and does not need to care about the internal structure of the cluster, so the cluster identity key is used for encryption or signature verification.
- the user can initiate a challenge to the off-chain contract deployed in the cluster through the client 31 before calling the off-chain contract in the cluster through the client 31.
- the control node 32 can select any node in the cluster to respond to the challenge.
- the master node used to generate the cluster identity key can be selected, or the slave node in the cluster can be selected.
- This specification does not limit the method of selecting the node that responds to the challenge. Take the node 32n responding to the challenge as an example for description.
- the control node 32 selects the node 32n to respond to the challenge on behalf of the cluster, and provides the challenger with a cluster remote certification report on behalf of the cluster.
- the cluster remote certification report is generated by the authentication server after verifying the self-recommendation information generated by the node 32n for its own off-chain TEE, that is, the cluster remote certification report is a remote certification report corresponding to the off-chain TEE of node 32n.
- the self-recommendation information carried in the cluster remote certification report contains the first to-be-verified hash value.
- the first to-be-verified hash value is the hash value of the preset information of the off-chain TEE of node 32n.
- the verification hash value is used by the challenger to verify the signature of the cluster remote attestation report according to the public key of the authentication server, and the signature verification is passed, and the remote attestation result contained in the cluster remote attestation report is certified.
- the first standard hash value of the off-chain TEE (for example, the trusted hash value of the above-mentioned preset information of the off-chain TEE) is compared, and the comparison result is consistent as a prerequisite for the challenger to confirm the authenticity of the off-chain TEE.
- the process of the challenger verifying the off-chain TEE according to the cluster remote certification report can refer to the content of the aforementioned control node to verify the off-chain TEE of the node to be added, which will not be repeated here.
- the off-chain TEE verified by the challenger according to the cluster remote attestation report is the off-chain TEE of node 32n.
- node 32n when node 32n generates its own node identity information in the off-chain TEE, it can also generate cluster identity information representing the cluster in the off-chain TEE, and perform a check on the generated cluster identity information.
- the hash calculation obtains the second standard hash value; wherein the generated cluster identity information includes the cluster identity public key and the node identity information of the node 32n other than the node identity public key.
- the difference between the node identity information of the node 32n and the cluster identity information is that the public key recorded in the node identity information is the node identity public key, and the public key recorded in the cluster identity information is the cluster Identity public key; other than this, other identity information is the same.
- the client 31 can use the second standard hash value to verify the first cluster identity information provided by the node 32n (that is, the declared cluster identity information, including the cluster identity public key and other identity information of the node 32n, which is not necessarily real data. At this time, it can be understood as the identity information to be verified), and if the verification is passed, the cluster identity public key included in the cluster identity information is obtained, so as to use the cluster identity public key to complete subsequent verification of the off-chain contract.
- the first cluster identity information provided by the node 32n that is, the declared cluster identity information, including the cluster identity public key and other identity information of the node 32n, which is not necessarily real data.
- the identity information to be verified it can be understood as the identity information to be verified
- the cluster identity public key included in the cluster identity information is obtained, so as to use the cluster identity public key to complete subsequent verification of the off-chain contract.
- the client performs a hash calculation on the acquired first cluster identity information to obtain the second hash value to be verified, and performs the second hash value to be verified with the second standard hash value provided by the node 32n Compare, and determine that the cluster identity verification is passed if the comparison results are consistent.
- the cluster identity information is generated by the node 32n in the off-chain TEE and calculated to obtain the second standard hash value, after determining the authenticity of the off-chain TEE according to the remote attestation report, if the second hash value to be verified is consistent with the second standard If the hash value is the same, it means that the first cluster identity information provided by the privacy computing node 32 is the cluster identity information generated in the off-chain TEE, so that the cluster identity public key contained therein is the actual maintenance of the privacy computing node 32 corresponding to the cluster.
- the cluster identity public key, and the cluster identity public key actually maintained by the private computing node 32 can be used to verify the signature of the private computing node 32.
- the node 32n can send the second standard hash value, the remote certification report, and the first cluster identity information to the client 31 through the control node 32. It should be noted that this part of the content can refer to the process of verifying the off-chain privacy computing node in the aforementioned step 104, which will not be repeated here.
- the cluster identity information generated by the node 32n in the off-chain TEE may include the cluster identity public key, other identity information other than the node identity public key in the node identity information of the node 32n, and The hash value of the preset information of the off-chain TEE, then after the node 32n generates the cluster identity information in its own off-chain TEE, it hashes the generated cluster identity information to obtain the third standard hash value, then the third standard The hash value is equivalent to simultaneously achieving the functions of the first hash value to be checked and the second standard hash value.
- the node 32n can provide the client 31 with a remote certification report, a third standard hash value, and second cluster identity information (this can be understood as the identity information to be verified).
- the second cluster identity information includes the cluster identity public key, other identity information of the node 32n, and a fourth hash value to be verified, and the fourth hash value to be verified is the hash value of the preset information of the off-chain TEE;
- the second cluster identity information is the declared cluster identity information, and not necessarily the real cluster identity information provided by the node 32n.
- the client 31 performs signature verification on the remote certification report according to the public key of the authentication server, and when the signature verification is passed and the remote certification result contained in the remote certification report is certified, the acquired second cluster identity
- the information is hashed to obtain the third hash value to be verified, and the third hash value to be verified is compared with the third standard hash value.
- the comparison result is consistent, it means that the second cluster identity information provided by the privacy computing node 32 is the cluster identity information generated in the off-chain TEE, that is, the fourth hash value to be verified is the actual value of the off-chain TEE.
- the hash value of the preset information is consistent.
- the pre-obtained fourth standard hash value for the preset information of the off-chain TEE is further compared with the fourth hash value to be verified, and the comparison result is consistent as a prerequisite for confirming the authenticity of the off-chain TEE condition.
- the cluster identity public key included in the second cluster identity information can be determined as the cluster identity public key actually maintained by the privacy computing node 32, which can be used to perform signature verification on the contract information to be verified.
- the node 32n can send the third standard hash value, the remote certification report, and the second cluster identity information to the client 31 through the control node 32. It should be noted that this part of the content can refer to the verification process for the off-chain privacy computing node in the aforementioned step 104, which will not be repeated here.
- the cluster remote certification report and the contract information to be verified are sent by the node 32n to the control node 32, and then forwarded by the control node 32 to the client 31.
- the control node 32 can provide the cluster remote certification report and the contract information to be verified to the client 31 together, or can provide the cluster remote certification report first, and obtain the pending verification from the node 32n after the client 31 passes the verification according to the cluster remote certification report. Contract information to provide the client 31 with contract information to be verified.
- the contract information to be verified is the contract information of the off-chain contract deployed at node 32n, and is signed by node 32n in the off-chain TEE of node 32n using the cluster identity private key (maintained in the off-chain TEE of node 32n) .
- the node 32n reads the off-chain contract deployed at the node 32n into the off-chain TEE, and uses the cluster identity private key to sign.
- the client 31 uses the cluster identity public key to treat Verify the contract information for signature verification, and verify the contract information to be verified based on the contract information of the off-chain contract.
- the cluster identity public key is in a public state, for example, the control node 31 publicly releases the cluster identity public key to the client 31 to obtain it.
- the client 31 obtains the cluster identity information through the above-mentioned method of verifying cluster identity information.
- the contract information of the off-chain contract can also be in a public state, for example, the deployment of the off-chain contract publicly releases the contract information to the client 31 to obtain it.
- the contract information may include the name, description, version number, bytecode hash value, contract identity public key and other information of the off-chain contract, which is not restricted in this specification.
- the client 31 can determine that the client 31 initiates a call to the off-chain contract through the oracle mechanism of the blockchain node At this time, the off-chain contract is executed by the node 32n in the off-chain TEE trusted execution environment, that is, it is ensured that the off-chain contract deployed in the node 32n is credible and can perform computing tasks as expected by the user.
- various remote attestation reports can have a certain time limit, such as 30 minutes or other durations, and the time-out remote attestation report is judged to be invalid.
- the remote certification report involved in the process of sharing the cluster identity key is obtained by the node from the authentication server control node in real time, and the cluster remote certification report can be cached locally by the control node and the aging time can be set.
- the blockchain node can allocate computing tasks to the off-chain private computing node, and call the off-chain contract deployed on the off-chain private computing node, through the creation of the off-chain private computing node
- the off-chain contract is executed in the off-chain TEE to complete the above-mentioned calculation tasks.
- the blockchain node can update the blockchain ledger data according to the calculation result, can solidify the calculation result, and can support the later verification of the calculation result.
- the calculation result generated based on the off-chain contract is relatively shorter. Therefore, when the calculation result is uploaded to the chain, it is helpful to save Storage space on the chain.
- the blockchain node updates the blockchain ledger data according to the calculation result, or it is called uploading the calculation result to the chain.
- the method can include: generating a blockchain transaction and adding the calculation result to the data field of the transaction. After the block chain transaction has passed the consensus, it can be added by each block chain node to the block body of the latest block, thereby realizing the update of the block chain ledger data, that is, completing the chaining of the calculation result; or,
- the blockchain node updates the state of the related account according to the calculation result.
- the related account can be, for example, the external account corresponding to the user or the contract account corresponding to the contract on the chain.
- the update of the state of the related account will cause the state tree to change.
- the value of the root of the tree changes, and the root of the state tree will be included in the block header of the latest block, thereby realizing the update of the blockchain ledger data, which is equivalent to uploading the calculation result to the chain.
- target data is used as the input data of the off-chain contract, it also belongs to the private data of the data owner of the target data. Therefore, for privacy protection, for users who need to call an off-chain contract to process target data (hereinafter referred to as data users), the data owner can control the rights of these users to use the target data.
- the target data in plaintext form is only held by the data owner, and the data owner can encrypt the target data in plaintext form (hereinafter referred to as target plaintext data) to obtain target data in ciphertext form (hereinafter referred to as target ciphertext data) ), and the target ciphertext data can be decrypted only in the off-chain TEE of the off-chain privacy computing node.
- the data owner can provide the target ciphertext data to the user who has been granted the right to use, so that the user can subsequently call the off-chain privacy computing node to decrypt the target ciphertext data in the off-chain TEE and execute the off-chain contract to decrypt the obtained data.
- the target plaintext data is processed. The following describes the method of invoking an off-chain contract based on data permission control in conjunction with Figures 4-7.
- Fig. 4 is a flowchart of a method for invoking a contract on the data consumer side according to an exemplary embodiment. As shown in FIG. 4, the method may include steps 402 to 404.
- Step 402 The data user generates a call request for the off-chain contract, the call request includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data.
- the prerequisites for the data user to process the target plaintext data (that is, understand as using the target plaintext data) in the contract under the call execution chain include: the data owner of the target plaintext data grants the target plaintext data to the data user. Right to use plaintext data. For example, the data owner can encrypt the target plaintext data it holds to obtain the target ciphertext data, and declare that the target ciphertext data can be used only after the authorization of the data owner. Then, before invoking the off-chain contract, the data user needs to initiate an authorization request for the target plaintext data to the data owner, and the data owner will review the data user, and after the review is passed, the data user will be issued an authorization request for the data user.
- VC Very Claim
- the data user obtains the verifiable statement, it can show the verifiable statement to the off-chain privacy computing node when the off-chain contract is subsequently called to process the target plaintext data, and the off-chain privacy computing node will verify the verifiable statement according to the verifiable statement.
- the verification data user has the right to use the target plaintext data, and executes the off-chain contract to complete the processing of the target plaintext data if the verification is passed.
- the way in which the data user submits the call request to the off-chain private computing node is also different.
- the off-chain private computing node is in the form of a single node
- the data user submits a call request to the blockchain node
- the blockchain node forwards the call request to the off-chain private computing node through the oracle mechanism.
- the data user submits a call request to the blockchain node
- the blockchain node forwards the call request to the control node of the off-chain private computing cluster through the oracle mechanism.
- the control node forwards the call request to the off-chain privacy computing node in the cluster.
- the client 51 of the data user wants to call the deployed off-chain contract (for example, after the verification of the off-chain contract is passed).
- the client 51 can send a call request to the control node 52 through an off-chain channel.
- the call request is encrypted using the cluster identity public key.
- the control node 52 can allocate the call request to an off-chain privacy calculation in the cluster based on the load balancing algorithm.
- the node 52n responds to the call request.
- the node 52n decrypts the call request through the cluster identity private key in the TEE created by itself, thereby obtaining the input parameter data contained in the call request.
- the node 52n can execute the bytecode of the off-chain contract in the off-chain TEE to process the input parameter data, so as to obtain the corresponding call result. Further, the node 52n may encrypt the call result in the off-chain TEE, and then feed it back to the client 51 via the control node 52.
- the client 51 can send a call request to the control node 52 through an on-chain channel.
- the client 51 may submit an off-chain contract invocation transaction to the blockchain network 53.
- the off-chain contract invocation transaction includes a invocation request, and the invocation request is encrypted by the client 51 using the cluster identity public key.
- the off-chain contract call transaction itself can also be encrypted transmission, such as using the cluster identity public key to encrypt the call transaction, or other encryption methods. For this, please refer to the content of data encryption transmission described above, which will not be repeated here.
- the off-chain contract call transaction can call the oracle contract, so that the oracle contract generates a corresponding contract event for the call request contained in the exchange.
- the oracle server 54 After the contract event is monitored by the oracle server 54, the oracle server 54 obtains the call request and Transmitted to the control node 52. Then, the control node 52 distributes the call request to, for example, the off-chain privacy computing node 52n to respond. And, the control node 52 can feed back the call result to the chain through the oracle mechanism, and the node 53n can actively initiate a transaction to upload the call result to the chain, or the node 53n can feed back the call result to the client 51, and the client The terminal 51 re-initiates a transaction to upload the call result to the chain.
- the input data is blockchain data
- the target ciphertext data provided by the data owner to the data user is stored on the blockchain and can be obtained by the data user from the blockchain.
- the client 51 can submit an encrypted off-chain contract invocation transaction to the blockchain network 53.
- the off-chain contract invocation transaction contains the information of the incoming parameter data, and the off-chain contract invocation transaction invokes the information used to obtain the incoming parameter data.
- Contract on the chain After node 53n receives the encrypted off-chain contract call transaction, it decrypts it in the on-chain TEE, and then executes the called on-chain contract through the virtual machine deployed in the on-chain TEE to obtain the block that is used as the input data.
- node 53n can decrypt it into plaintext in the on-chain TEE, and then package the plaintext block chain data into the call request, and use the cluster identity public key in the on-chain TEE to encrypt the call request, and then based on
- the oracle mechanism is transmitted to the control node 52, and the control node 52 distributes the call request to, for example, the off-chain privacy computing node 52n for response.
- the control node 52 can feed back the call result to the chain through the oracle mechanism, and the node 53n can upload the call result to the chain.
- an off-chain privacy computing cluster is taken as an example for description.
- the client 51 can also directly interact with a single off-chain private computing node to invoke the off-chain contract deployed on the off-chain private computing node, which will not be repeated here.
- Step 404 the data user submits the invocation request to the off-chain private computing node where the off-chain contract is deployed through the oracle mechanism of the blockchain, and the invocation request is used to instruct the off-chain private computing node
- the off-chain contract is executed in the off-chain trusted execution environment created by the off-chain privacy computing node to process the target plaintext data
- the calling conditions include The verifiable statement determines that the data owner of the target plaintext data grants the use right to the data user.
- the data owner's identity, the data user's identity and the verifiable statement are recorded in the call request, and these information are all written into the call request by the data user.
- the above-mentioned information contained in the call request is provided by the data user to declare that the verifiable claim is a verifiable claim issued to the data user by the data owner of the target plaintext data, and the above-mentioned information in the call request is forged possible.
- forgery includes at least one of the following: the identity of the data owner recorded in the call request is not the identity of the actual data owner, and the identity of the data user recorded in the call request is not the identity of the actual data user.
- the verifiable statement contained in the call request is not issued by the actual data owner, and the verifiable statement contained in the call request is not issued to the actual data user. Therefore, after receiving the call request, the off-chain privacy computing node should first perform the verification operation for the above situation to find the forgery problem, thereby improving the security of the data. As an exemplary embodiment, if the following verification operations are passed, the off-chain privacy computing node can verify that the verifiable claim in the call request is the data owner (the actual data owner) of the target plaintext data.
- a verifiable statement issued by the data user that is, the actual data user who submitted the call request
- the data owner recorded in the call request The first authenticity check operation of the identity, the second authenticity check operation for the identity of the data user recorded in the call request, and the third authenticity check operation for the actual issuer of the verifiable claim as the data owner
- the fourth authenticity check operation for the actual issuance object of the verifiable claim as the data user is: the issuer issues a verifiable statement to the issuing object. It should be noted that there is no restriction on the execution order between the first authenticity verification operation and the fourth authenticity verification operation.
- An identity can be created for each user through DIS (Decentralized Identifier Service).
- DIS can provide users with a DID (Decentralized Identifier) that is not restricted by any single registration center, identity service provider, or authentication center, and is completely controlled by the user.
- DID Decentralized Identifier
- the data owner Based on the DID to indicate the identity of the data user and the data owner, in addition to issuing a verifiable statement to the data user and providing the target ciphertext data, the data owner also provides the private key corresponding to the data owner’s DID
- the first signature information obtained by signing the target plaintext data can be used to prove the identity of the data owner. For example, it is possible to directly sign the target plaintext data itself to obtain the first signature information, or perform a hash calculation on the target plaintext data to obtain a hash value, and then sign the hash value to obtain the first signature information.
- the private key corresponding to the DID of the data user is used to sign the call request to obtain the corresponding second signature information, and the second signature information is added.
- the signature information is added to the call request.
- the call request includes at least the target ciphertext data, the verifiable statement, the DID of the data user, the first signature information corresponding to the target plaintext data, the DID of the data owner, and the second signature information corresponding to the call request.
- the off-chain privacy computing node can use the first user public key to perform signature verification on the first signature information corresponding to the target plaintext data in the call request; where the first user public key is recorded in the call request Corresponding to the first DID of the data owner (not necessarily the actual data owner).
- the party Since only the actual data owner holds the target plaintext data (provided to other users is the target ciphertext data obtained by encrypting the target plaintext data), then in the case of signature verification (indicating that the first signature information is owned by the actual data) The party uses its own private key to sign the target plaintext data.) Next, explain that the first DID of the data owner recorded in the call request is the DID of the actual data owner, then the first authenticity verification operation can be determined to pass .
- the off-chain privacy computing node uses the second user public key to perform signature verification on the second signature information corresponding to the call request in the call request and the signature verification is passed, it can determine that the second authenticity verification operation is passed. ; Among them, the second user public key corresponds to the second DID of the data user recorded in the call request.
- the DID of the actual issuer of the verifiable claim matches the first DID
- the inspection operation passed.
- the DID of the actual issuing object of the verifiable claim matches the above-mentioned second DID
- the issuer of the verifiable statement issues the verifiable statement, it records its own DID and the DID of the issuing object in the verifiable statement; at the same time, it uses the private key corresponding to its own DID to the verifiable statement.
- the verification statement is signed and the signature is recorded in the verifiable statement to prove its identity.
- the DID of the actual issuer of the verifiable claim and the DID of the actual issuer of the verifiable claim can be determined by the following methods: read the DID of the issuer of the verifiable claim record in the call request, and obtain and read the DID
- the third user public key corresponding to the DID uses the third user public key to perform signature verification on the signature of the verifiable claim record in the call request, and if the signature verification is passed, the DID of the issuer of the verifiable claim record in the call request As the DID of the actual issuer; and, use the DID of the issuing object in the verifiable claim record in the call request as the DID of the actual issuing object.
- the verifiable statement contains the calling rules for the target plaintext data defined by the data owner, that is, it specifies how the issuing object of the verifiable statement uses the target plaintext data.
- Calling rules can be used to fine-tune the right to use the target plaintext data; for example, the contract function that allows the processing of target plaintext data in the off-chain contract, the validity period of the right to use the target plaintext data, and the permission to call the off-chain contract to the target The number of times the plaintext data is processed and the frequency at which the off-chain contract is allowed to be called to process the target plaintext data.
- the off-chain privacy computing node in step 404 determines that the data owner of the target plaintext data has granted the use right to the data user based on the verifiable statement, it needs to further verify whether the invoking operation indicated by the invoking request complies with the verifiable statement definition
- the calling rules that is, the calling conditions also include that the calling operation indicated by the calling request conforms to the calling rules defined by the verifiable claim.
- the data owner can use the contract identity public key of the off-chain contract to encrypt the target plaintext data to obtain the target ciphertext data, thereby ensuring that the target plaintext data can only be obtained by the called off-chain contract. Will be obtained by other off-chain contracts.
- the off-chain privacy computing node maintains the contract identity private key corresponding to the contract identity public key in the off-chain TEE, then the off-chain privacy computing node can use this in the off-chain TEE after receiving the call request for the off-chain contract
- the private key of the contract identity decrypts the target ciphertext data in the call request.
- the off-chain privacy computing node gets the call result (that is, the execution result obtained by executing the off-chain contract), it can use the contract identity private key of the called off-chain contract to sign the call result in the off-chain TEE, and After the client of the data user obtains the execution result of the off-chain privacy computing node fed back to the blockchain node through the oracle mechanism, it can use the contract identity public key of the called off-chain contract to perform signature verification on the execution result, and If the signature verification is passed, the judgment execution result is generated by the called off-chain contract.
- the encryption and decryption in this manual can use the same set of key pairs, or configure a set of encryption key pairs and a set of signature key pairs separately.
- a group of key pairs corresponding to different encryption algorithms, there may be multiple public keys and corresponding private keys at the same time.
- the following takes the node identity key as an example for description.
- the cluster identity key and contract identity key are similar.
- the node identity key is a set of key pairs, including the node identity public key and the node identity private key.
- the node identity public key can be used to encrypt data, then the node identity private key can be used to decrypt the data; the node identity private key can be used to sign the data, then the node identity public key can be used to sign and verify the data .
- two sets of key pairs can be configured, namely a node encryption key pair and a node signature key pair. Among them, the node encryption key pair is used to encrypt and decrypt data, and the node signature key pair is used to sign data and verify the signature.
- the data owner can encrypt the target plaintext data it owns to obtain the target ciphertext data, provide the target ciphertext data to the data user, and issue the right to use the target plaintext data to the data user
- the verifiable statement of can realize the authority control over the right to use the target plaintext data, that is, control the target plaintext data by which users are allowed to call the off-chain contract for processing.
- the right to use the target plaintext data is controlled by the data owner, which can effectively improve the privacy security of the data owner.
- the introduction of DID to represent the identity of each user during authorization can make the identity of the user truly owned and controlled by the user, and the user can independently create his own identity and completely decentralized identity management.
- Fig. 6 is a flowchart of creating a DID provided by an exemplary embodiment. As shown in FIG. 6, the method may include steps 602 to 608.
- step 602 the data consumer creates a DID, a public key and a private key corresponding to the DID, and a corresponding DID document through the consumer client.
- the public key corresponding to the data user DID needs to be published to the blockchain for storage, while the private key corresponding to the data user DID is kept by the data user, for example, stored in the user client .
- a DID (Decentralized Identifier, decentralized identity identifier) corresponds to an entity (for example, data user, data owner and other users), and the specific usage of the DID is determined by the corresponding DID
- the DID document (DID Document) description.
- the DID document is used to describe how to use the corresponding DID, including at least the public key of the corresponding DID; in addition, it can also record information such as encryption method, proof purpose, verification method, and service endpoint. Among them, the purpose of proof is combined with the verification method to provide a mechanism to prove things.
- a DID document can specify a specific verification method, such as a password public key or a pseudonym biometric protocol, which can be used to verify a method created for the purpose.
- the service endpoint supports trusted interaction with the DID controller.
- DID and DID documents can be directly registered on the blockchain or other distributed networks, without the need to apply to a centralized registration agency.
- hash encryption and other distributed network technologies such as blockchain, it can be realized.
- Digital identities are truly owned and controlled by users, and there is no longer any intermediary (even DID technology providers) that has access to the identities and data that control users.
- step 604 the user client creates a transaction for depositing DID and DID documents.
- step 606 the user client initiates the transaction for depositing the DID and DID document to the blockchain node.
- step 608 the blockchain node stores the DID and DID documents on the blockchain.
- the blockchain for depositing DID and DID documents can be the same blockchain or different blockchains as the blockchain that uses the oracle mechanism to call the off-chain contract.
- step 610 the user client obtains a receipt of successful DID creation from the blockchain node.
- the blockchain node after the blockchain node deposits the DID and DID documents, it can generate an event for recording the success of depositing the DID and the DID document, and store it in the blockchain log. Then, the user client can obtain the event through the callback mechanism of the blockchain to determine that the DID and DID documents have been stored on the blockchain, that is, the data user successfully created the DID. At the same time, a corresponding prompt message can be generated for the data user to view, to inform the data user that the DID is successfully created on the chain.
- Fig. 7 is a flowchart of a data authorization process provided by an exemplary embodiment. As shown in FIG. 7, the process may include step 702 to step 722.
- step 702 the data consumer creates an authorization request (including the consumer DID, the consumer information, and the signature) for the target plaintext data through the consumer client.
- the user information is recorded in the authorization request for the data owner to review whether the data user has the right to use the target plaintext data, that is, the data owner is based on the user information To decide whether to authorize the target plaintext data use right to the data user.
- the user client uses the private key corresponding to the user DID to sign the authorization request, and records the obtained signature in the authorization request to indicate the identity of the data user.
- Step 704 The user client sends an authorization request to the owner client of the data owner.
- Step 706 The owner client reads the data consumer DID included in the authorization request.
- step 708 the owner client initiates a query transaction for the user DID to the blockchain node.
- Step 710 the blockchain node queries the DID document corresponding to the user DID.
- Step 712 The owner client obtains the queried DID document.
- Step 714 The owner client uses the public key in the DID document to perform signature verification on the signature in the authorization request.
- the DID file of the user DID records the public key corresponding to the user DID
- the public key can be used to verify whether the user DID in the authorization request is It is the actual DID of the data user, that is, to verify whether the data user is the legal owner of the user DID in the authorization request.
- the owner client can also initiate an authentication challenge for the DID to the user client to complete the verification of the use of the DID. Specifically, there is no need to add a signature to the DID authorization request created by the user client. Instead, the owner client initiates the DID to the user client after obtaining the public key recorded in the DID file corresponding to the user DID An authentication challenge (DID auth challenge) message, which contains a random character string, is used to require the user client to use the private key of the user DID to sign the character string. After receiving the DID authentication challenge message, the consumer client uses the private key of the consumer DID to sign the string, and sends the string and signature to the owner client. Then, the owner client can use the public key in the DID document to perform signature verification on the signature, and then, if the signature verification is passed, confirm that the data user is the legal owner of the user DID recorded in the authorization request.
- DID auth challenge which contains a random character string
- Step 716 If the signature verification is passed, the owner client reviews the user information in the authorization request to determine whether to grant the data user the right to use the target plaintext data.
- the data user may also provide the user information to the data owner offline for the data owner to review.
- the specific review method can be flexibly set according to the actual situation; of course, this manual does not limit this.
- step 718 if the review is passed, the owner client creates a verifiable statement of the user's right to use the target plaintext data.
- the DID is the identity of an entity, and specific information such as permissions, capabilities, behaviors, and assets owned by the entity are expressed through verifiable statements. It should be noted that a DID can have one or more verifiable claims. For example, the following fields can be included in the verifiable statement:
- the content of the claim which can be plaintext, ciphertext, hash, etc.;
- proof proof of validity.
- the data owner has also created its own DID in advance using the method shown in Figure 6 above. Then, the data owner can record its own DID in the issuer, record the DID of the data user who passed the audit in didsubject, record the validity period of the right to use the target plaintext data in expire, and record the verifiable statement in issuance date.
- the data owner needs to use its own private key to sign the verifiable statement and record the signature in the proof.
- the above description of the fields and calling rules contained in the verifiable statement is only an example, and can be flexibly adjusted according to actual conditions in actual applications.
- Step 720 The owner client returns the verifiable statement and the signature body of the data owner to the user client.
- the signature body of the data owner includes at least the first signature information, and the first signature information is obtained by signing the target plaintext data by the owner client using the private key corresponding to its own DID.
- step 722 the user client saves the verifiable statement and the signature body.
- Fig. 8 is a flowchart of another method for invoking a contract provided by an exemplary embodiment. As shown in FIG. 8, the calling process may include steps 802 to 830.
- step 802 the consumer client creates a call request.
- the user client can obtain the target ciphertext data obtained by the data owner using the contract identity public key of the off-chain contract to encrypt the target plaintext data, and then call the off-chain contract to process the target plaintext data.
- the call request contains the target ciphertext data, the verifiable statement obtained from the data owner, the data user's DID, the data user's signature, and the data owner's signature body.
- the user client can use the private key corresponding to the data user's DID to sign the call request.
- the call request can also contain information related to the call operation, such as the contract ID of the off-chain contract, the function name of the called function, and so on.
- the contract ID can be, for example, the hash value of the bytecode of the off-chain contract, so that the off-chain privacy computing node (which may be deployed with multiple off-chain contracts) can find the bytecode of the corresponding deployed off-chain contract.
- the off-chain contract may contain multiple functions, so the function name can indicate the function that the data consumer wants to call; if the off-chain contract contains only one function, or the data consumer wants to call all functions in the off-chain contract, then the call request is also You can omit the function name information.
- the target ciphertext data as the input data may be blockchain data, so the call request does not need to include the target ciphertext data itself, but contains the description information of the input parameter data (for example, the input data is in the blockchain Index or storage address, etc.).
- the user client can send a call request to the off-chain private computing node through the on-chain channel.
- the user client can submit an off-chain contract invocation transaction to the blockchain network.
- the off-chain contract invocation transaction contains the invocation request, and the The off-chain contract call transaction is used to call the on-chain contract that obtains the input data of the deposit certificate on the blockchain.
- the off-chain contract call transaction itself can also be encrypted transmission, which can refer to the content of data encrypted transmission described above, which will not be repeated here.
- the blockchain node receives the encrypted off-chain contract invocation transaction, it decrypts it in its own on-chain TEE, and then executes the invoked on-chain contract through the virtual machine deployed in the on-chain TEE, thereby according to the invocation request
- the description information recorded in obtains the blockchain data (that is, the target ciphertext data) that is used as the input data.
- the blockchain node can send the blockchain data and the call request to the off-chain privacy computing node through the oracle mechanism.
- the blockchain node can write the blockchain data into the call request, or package the blockchain data with the call request and send it to the off-chain privacy computing node, or read the verifiable statement contained in the call request, Signature body, DID and other data, and based on these data and the blockchain data, a call request is regenerated, and the regenerated call request is sent to the off-chain privacy computing node.
- step 804 the user client submits a call request to the off-chain privacy computing node.
- step 806 the off-chain privacy computing node decrypts the target ciphertext data in the off-chain TEE.
- step 808 the off-chain privacy computing node initiates a query transaction for the data user DID and the data owner DID to the blockchain node.
- the data owner DID and the data user DID can be directly recorded in the call request.
- the data owner's signature body may include the data owner's DID.
- the data owner DID is used as the first DID of the data owner recorded in the call request
- the data user DID is used as the second DID of the data user recorded in the call request.
- the issuer recorded in the verifiable statement in the call request is used as the first DID, and the call request can be The issuance object recorded in the verification statement serves as the above-mentioned second DID.
- the query transaction includes the data user DID and the data owner DID, so that the corresponding DID document can be queried from the blockchain (the blockchain used to store DID and DID documents).
- the off-chain private computing node queries the blockchain for the DID document of the data user, and the DID document of the query data owner can be independent of each other, and there is no priority.
- off-chain private computing nodes can also query the blockchain for the DID document of the data user, and then query the DID document of the data owner; or, first query the blockchain for the DID document of the data owner, and then query the data usage Party’s DID file.
- step 810 the blockchain node queries the DID document of the data user and the DID document of the data owner.
- Step 812 the off-chain privacy computing node obtains the DID document queried by the blockchain node.
- Step 814 the off-chain privacy computing node verifies the signature of the data owner.
- Step 816 the off-chain privacy computing node verifies the signature of the data user.
- the data owner DID, data user DID, and verifiable statement are recorded in the call request. These information are all provided by the data user to declare that the verifiable statement is the data owner of the target plaintext data.
- the verifiable statement issued by the user, and the above information in the call request may be forged.
- forgery includes at least one of the following: the data owner DID recorded in the call request is not the actual data owner DID (the actual data owner DID is the DID of the actual owner of the target plaintext data), the call request The recorded data user DID is not the actual data user DID (for example, the data user who initiated the call request fills in the DID of another user to impersonate the user), the verifiable statement contained in the call request is not by the actual data owner The verifiable statement contained in the issuance and call request is not issued to the actual data user.
- the off-chain privacy computing node can perform signature verification on the signature recorded in the signature body (ie, the first signature information) through the public key recorded in the DID file of the data owner (ie, the first user public key). Since only the actual data owner holds the target plaintext data (provided to other users is the target ciphertext data), can the target plaintext data be signed, and other users cannot sign the target plaintext data, then after the signature verification is passed In the case (indicating that the signature in the signature body is obtained by the actual data owner using the private key corresponding to its own DID to sign the target plaintext data), it indicates that the data owner DID (i.e., the first DID) recorded in the call request is actual Data owner DID.
- the data owner DID i.e., the first DID
- the data owner when the data owner provides the signature body, it hashes the target plaintext data to obtain the first hash value, and then uses the private key corresponding to its own DID to sign the first hash value.
- the first signature information, and the first signature information is added to the signature body.
- the off-chain privacy computing node decrypts the target ciphertext data to obtain the target plaintext data in step 806, and performs a hash calculation on the target plaintext data to obtain the second hash value, which is based on the second hash value and the record in the DID file of the data owner Perform signature verification on the first signature information with the public key of, so that if the signature verification is passed, it is determined that the data owner DID recorded in the call request is the actual data owner DID, thereby eliminating the possibility of forging the data owner DID.
- the data owner may have multiple pairs of asymmetric keys for signing, so when the data owner provides the signature body, it can add the public key ID to the signature body, and the public key corresponding to the public key ID,
- the private key used to sign the target plaintext data is a pair of asymmetric key pairs.
- the second signature information recorded in the call request is obtained by the data user using the private key corresponding to the data user's DID to sign the call request. Therefore, the off-chain privacy computing node can use the public key recorded in the DID document of the data user (that is, the second user public key) to perform signature verification on the second signature information, and if the signature verification is passed, determine that the call request is in progress.
- the recorded second DID of the data consumer is the actual data consumer DID.
- step 818 the off-chain privacy computing node verifies whether the actual issuer of the verifiable claim is the data owner.
- step 820 the off-chain privacy computing node verifies whether the actual issuance object of the verifiable claim is the data user.
- the verifiable statement in the call request is a verifiable statement issued by the data owner to the data user. For example, in the case where the data owner DID and the data user DID recorded in the call request are verified, if the actual issuer DID of the verifiable claim matches the data owner DID, the verifiable claim in the call request is indicated Issued by the actual data owner. And, if the DID of the actual issuance object of the verifiable claim matches the DID of the data user, it means that the verifiable claim in the call request is received by the actual data user (that is, it is issued to the actual data user). It should be noted that there is no restriction on the time sequence between steps 814-820, and the sequence in this embodiment is only an example.
- the issuer DID of the issuer record of the verifiable claim is obtained from the issuer DID of the issuer record of the verifiable claim, and obtain the third user public key corresponding to the read issuer DID (that is, the public key recorded in the DID file of the data owner), and use the first
- the three-user public key performs signature verification on the signature recorded in the proof, and confirms that the verifiable statement is verified if the signature verification is passed, that is, confirms that the issuer DID of the verifiable claim record is the actual issuer’s DID (also the actual issuer’s DID).
- the data owner DID of the verifiable claim record is the DID of the actual issuing object (also the actual data user DID).
- Step 822 The off-chain privacy computing node verifies whether the calling operation complies with the calling rule defined in the verifiable statement.
- the off-chain privacy computing node can recognize the calling rules defined in the verifiable claim, that is, the calling rules defined in the verifiable claim are credible. Then, the data user's right to use the target plaintext data can be further controlled according to the calling rules.
- step 824 it can be verified whether the calling operation indicated by the calling request complies with the calling rules defined in the verifiable statement. If yes, go to step 824; otherwise, it is determined that the data user is prohibited from executing the off-chain contract to process the target plaintext data. For example, when it is determined that the data user's right to use the target plaintext data has expired according to the expire in the verifiable statement, it is prohibited to execute the off-chain contract to process the target plaintext data. For another example, when the contract function that the data user needs to call does not meet the contract function defined in the calling rules that allows processing the target plaintext data, it is forbidden to execute the off-chain contract to process the target plaintext data.
- the specific content of the calling rule can be flexibly set according to actual needs, and this specification does not limit it.
- step 824 the off-chain privacy computing node executes the off-chain contract in the TEE.
- step 826 the off-chain privacy computing node uses the contract identity private key of the off-chain contract to sign the execution result in the TEE.
- step 828 the off-chain privacy computing node feeds back the execution result to the user client.
- step 830 the user client uses the contract identity public key of the off-chain contract to verify the execution result.
- the data owner can encrypt the target plaintext data it owns to obtain the target ciphertext data, provide the target ciphertext data to the data user, and issue the right to use the target plaintext data to the data user
- the verifiable statement of can realize the authority control over the right to use the target plaintext data, that is, control the target plaintext data by which users are allowed to call the off-chain contract for processing.
- the right to use the target plaintext data is controlled by the data owner, which can effectively improve the privacy security of the data owner.
- the introduction of DID to represent the identity of each user during authorization can make the identity of the user truly owned and controlled by the user, and the user can independently create his own identity and completely decentralized identity management.
- this specification also proposes an embodiment on the side of the off-chain privacy computing node.
- the description involved in the embodiment on the data user side can also be applied to the implementation on the side of the off-chain privacy computing node. For example, I won’t repeat this in the following.
- FIG. 9 is a flowchart of a method for invoking a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment. As shown in FIG. 9, the method may include step 902 to step 904.
- step 902 the off-chain private computing node receives a call request for the off-chain contract deployed by the off-chain private computing node submitted by the data user through the oracle mechanism of the blockchain.
- the encrypted target ciphertext data and the verifiable statement of the right to use the target plaintext data are obtained.
- the off-chain privacy computing node receives the call request forwarded by the blockchain node through the oracle mechanism, and the call request is submitted by the data user to the blockchain node ;or,
- the off-chain privacy computing node receives the invocation request forwarded by the control node of the off-chain privacy computing cluster, and the invocation request is sent by the The data user submits to the blockchain node, and is forwarded to the control node by the blockchain node through the oracle mechanism.
- step 904 the off-chain private computing node executes the off-chain contract in the off-chain trusted execution environment created by the off-chain private computing node to process the target plaintext data when the calling conditions are met,
- the calling condition includes determining that the data owner of the target plaintext data grants the use right to the data user according to the verifiable statement.
- the off-chain privacy computing node determines that the data owner has granted the use right to the data user when the following verification operations are passed: for all the data recorded in the call request
- the first authenticity check operation of the identity of the data owner, the second authenticity check operation of the identity of the data user recorded in the call request, and the actual issuer of the verifiable claim are The third authenticity check operation of the data owner, and the fourth authenticity check operation of the data user that the actual issuance object of the verifiable statement is the data user.
- the off-chain privacy computing node performs signature verification on the first signature information corresponding to the target plaintext data in the call request through the first user public key, and the signature verification is passed, it determines that The first authenticity verification operation is passed, and the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; the off-chain privacy computing node is In the case where the second signature information corresponding to the call request in the call request is verified by the second user public key and the signature verification is passed, it is determined that the second authenticity verification operation is passed, and the second authenticity verification operation is passed.
- the user public key corresponds to the second decentralized identity identifier of the data user recorded in the call request; the decentralized identity of the off-chain privacy computing node in the actual issuer of the verifiable statement In the case where the identifier matches the first decentralized identity identifier, it is determined that the third authenticity verification operation is passed; the off-chain privacy computing node is in the actual issuing object of the verifiable statement. In the case that the centralized identity identifier matches the second decentralized identity identifier, it is determined that the fourth authenticity verification operation is passed.
- the off-chain privacy computing node can read the decentralized identity identifier of the issuer of the verifiable statement record in the call request, and obtain the decentralized identity identifier corresponding to the read decentralized identity identifier.
- the third user public key; the third user public key is used to perform signature verification on the signature of the verifiable claim record in the call request, and if the signature verification is passed, the verifiable claim record in the call request is issued
- the decentralized identity identifier of the party is used as the decentralized identity identifier of the actual issuer; and, the decentralized identity identifier of the issuance object of the verifiable claim record in the call request is used as the actual issuance object Decentralized identity identifier.
- the invocation condition also includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: the contract function in the off-chain contract that allows the processing of the target plaintext data, the validity period of the right to use the target plaintext data, and the permission to call the off-chain contract The number of times the target plaintext data is processed and the frequency at which the off-chain contract is allowed to be invoked to process the target plaintext data.
- the target ciphertext data is obtained by the data owner using the contract identity public key of the off-chain contract to encrypt the target plaintext data, and the corresponding off-chain trusted execution environment is maintained in the corresponding In the contract identity private key of the contract identity public key, the target ciphertext data is decrypted by the off-chain privacy computing node in the off-chain trusted execution environment using the contract identity private key.
- the off-chain private computing node uses the contract identity private key of the off-chain contract in the off-chain trusted execution environment to sign the execution result obtained by executing the off-chain contract; the chain The lower privacy computing node feeds back the execution result to the blockchain node through the oracle mechanism to be obtained by the data user, and the data user uses the contract identity public key of the off-chain contract to pair the When the execution result is subjected to signature verification and the signature verification is passed, it is determined that the execution result is generated by the off-chain contract.
- the off-chain private computing node before receiving the call request, provides the data user with a remote certification report for the trusted execution environment off the chain, and the remote certification report is verified by the authentication server on the off-chain
- the private computing node is generated after verifying the self-recommended information generated by the off-chain trusted execution environment; the off-chain private computing node provides the data user with the off-chain deployment at the off-chain private computing node
- the contract information to be verified is signed by the off-chain private computing node in the off-chain trusted execution environment using the identity private key of the off-chain private computing node, and the identity private The key is maintained by the off-chain private computing node in the off-chain trusted execution environment; the to-be-verified contract information is determined by the data user based on the remote attestation report to determine the off-chain trusted execution environment.
- the identity public key of the off-chain privacy computing node is used to perform signature verification on the contract information to be verified, and the contract information to be verified is verified according to the contract information of the off-chain contract, And in the case that the signature verification and contract information verification pass, it is determined that when the data user initiates a call to the off-chain contract through the oracle mechanism of the blockchain node, the off-chain contract is protected by the off-chain privacy
- the computing node executes in the trusted execution environment under the chain.
- the off-chain privacy computing node receives the challenge initiated by the off-chain privacy computing node by the data user, and returns the remote attestation report to the data user; or, in the off-chain privacy
- the computing node belongs to the off-chain privacy computing cluster after the control node of the off-chain privacy computing cluster receives the challenge initiated by the data user, it sends the remote attestation report to the control node, and the remote The certification report is returned by the control node to the data user.
- the self-recommendation information carried in the remote attestation report contains the first hash value to be verified, and the first hash value to be verified is the hash value of the preset information of the trusted execution environment under the chain.
- the first hash value to be verified is used by the data user to verify the signature of the remote attestation report according to the public key of the authentication server, and the remote attestation report contains the remote attestation report. If the authentication result is passed authentication, it is compared with the pre-obtained first standard hash value for the trusted execution environment of the chain, and the comparison result is consistent as the data user confirms the authenticity of the chain A prerequisite for a credible execution environment.
- the off-chain private computing node provides first identity information to the data user, and the first identity information includes the identity public key of the off-chain private computing node and the off-chain private computing node
- the first identity information is hashed by the data user to obtain the second to-be-verified hash value
- the off-chain privacy computing node provides the data user with the second standard Ha
- the second standard hash value is obtained by hashing the generated identity information after the off-chain privacy computing node generates its own identity information in the off-chain trusted execution environment; the second The standard hash value is used for comparison with the second hash value to be verified, and the data user obtains the identity contained in the first identity information of the privacy computing node when the comparison result is consistent. Public key.
- the off-chain privacy computing node provides its own second identity information to the data user, and the second identity information includes the identity public key of the off-chain privacy computing node, and the off-chain privacy Calculate other identity information of the node and the fourth hash value to be verified, where the fourth hash value to be verified is the hash value of the preset information of the trusted execution environment off-chain; the off-chain privacy calculation
- the node provides a third standard hash value to the data user.
- the third standard hash value is generated by the off-chain privacy computing node after generating its own identity information in the off-chain trusted execution environment.
- the identity information is obtained by hash calculation; the second identity information is when the data user performs signature verification on the remote certification report according to the public key of the authentication server, and when the signature verification is passed and the remote certification report contains If the remote authentication result is that the authentication is passed, the data user performs a hash calculation to obtain the third hash value to be verified; wherein, the precondition for confirming that the off-chain trusted execution environment is trustworthy is included in all In the case where the third hash value to be verified is consistent with the third standard hash value, the fourth hash value to be verified and the data user's pre-obtained for the trusted execution of the chain The fourth standard hash value of the environment is consistent; the identity public key included in the second identity information is used to perform signature verification on the contract information to be verified.
- the identity private key corresponding to the identity public key is maintained in the off-chain trusted execution environment; the off-chain private computing node uses the identity private key in the off-chain trusted execution environment.
- the key decrypts the call request, and the call request is encrypted by the data user using the identity public key of the off-chain privacy computing node.
- the identity private key of the off-chain private computing node is the node identity private key in the node identity key of the off-chain private computing node
- the identity public key of the off-chain private computing node is the The node identity public key in the node identity key; wherein, in the process of the blockchain node interacting with the off-chain privacy computing node to deploy or call the off-chain contract, the node identity key is used to exchange data Perform encryption and decryption and/or signature verification; or, in the case that the off-chain private computing node belongs to the off-chain private computing cluster, the identity public key of the off-chain private computing node is that of the off-chain private computing cluster
- the cluster identity public key in the cluster identity key, the identity private key of the off-chain privacy computing node is the cluster identity private key in the cluster identity key; wherein, the blockchain node and the off-chain privacy calculation In the process of each node in the cluster interacting to deploy or call an off-chain contract, the cluster identity key is used to encrypt and de
- the data user can also directly interact with the private computing node through the user client to complete the deployment of smart contracts on the private computing node, challenge smart contracts, verify smart contracts, and call smart contracts, etc.
- the above operations do not need to be completed through the oracle mechanism of the blockchain, and the calculation results obtained by invoking the smart contract deployed on the privacy computing node do not need to be fed back to the blockchain.
- off-chain private computing nodes will be referred to as “private computing nodes”
- “off-chain trusted execution environment” will be referred to as “trusted execution environment”.
- the "target chain contract” is called the "target smart contract”.
- the principle of the technical solution is similar to the foregoing embodiment, and the involved implementation details can also refer to the foregoing embodiment, so the detailed description will not be given below.
- Fig. 10 is a flowchart of another method for invoking a contract on the data consumer side provided by an exemplary embodiment. As shown in FIG. 10, the method may include step 1002 to step 1004.
- Step 1002 The data user generates a call request for the smart contract, the call request includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data.
- Step 1004 The data user submits the invocation request to the privacy computing node where the smart contract is deployed.
- the invocation request is used to instruct the privacy computing node in the case where the invocation condition is met, in the privacy computing node.
- the smart contract is executed in the trusted execution environment created by the node to process the target plaintext data, and the calling condition includes determining the data owner of the target plaintext data according to the verifiable statement to the data user The right to use was granted.
- the privacy computing node determines that the data owner has granted the use right to the data user: for the data recorded in the call request: The first authenticity check operation of the identity of the data owner, the second authenticity check operation of the identity of the data user recorded in the call request, and the actual issuer of the verifiable claim The third authenticity check operation of the data owner, and the fourth authenticity check operation of the data user that the actual issuance object of the verifiable statement is the data user.
- the first signature information corresponding to the target plaintext data in the call request is signed and verified by the first user public key, and the signature verification is passed, it is determined that the first authenticity check
- the operation is passed, the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; in the call request through the second user public key, it corresponds to
- the second signature information of the call request is subjected to signature verification and the signature verification is passed, it is determined that the second authenticity verification operation is passed, and the second user public key is combined with the data recorded in the call request
- the user’s second decentralized identity identifier corresponds to the user’s
- the third authenticity verification operation is passed; in the case that the decentralized identity identifier of the actual issuance object of the verifiable claim matches the second decentralized identity identifier, the fourth authenticity is determined
- the sex check operation passed.
- the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer are determined by the following method: the issuer who reads the verifiable claim record in the call request And obtain the third user public key corresponding to the read decentralized identity identifier; use the third user public key to sign the verifiable statement record in the call request Signature verification, and if the signature verification is passed, the decentralized identity identifier of the issuer of the verifiable claim record in the call request is used as the decentralized identity identifier of the actual issuer; and The decentralized identity identifier of the issuing object in the verifiable claim record in the call request is used as the decentralized identity identifier of the actual issuing object.
- the invocation condition also includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: the contract function in the smart contract that allows the processing of the target plaintext data, the validity period of the right to use the target plaintext data, and the permission to call the smart contract to all The number of times the target plaintext data is processed and the frequency of allowing the smart contract to be called to process the target plaintext data.
- the data user before submitting the call request, the data user obtains the remote certification report for the trusted execution environment, and the remote certification report is verified by the authentication server on the private computing node against the trusted
- the self-recommendation information generated by the execution environment is generated after verification; the data user obtains the smart contract deployed at the private computing node when the trusted execution environment is determined to be credible according to the remote attestation report
- the contract information to be verified is signed by the private computing node in the trusted execution environment using the identity private key of the private computing node, and the identity private key is used by the private computing node Maintained in the trusted execution environment;
- the data user uses the identity public key of the private computing node to perform signature verification on the to-be-verified contract information, and to verify the to-be-verified contract information according to the smart contract’s contract information
- the contract information is verified by the contract information, and when the signature verification and the contract information verification pass, it is determined that when the data user initiates a call to the smart contract, the smart contract is used by the
- the data user performs signature verification on the remote certification report according to the public key of the certification server; in the case where the signature verification is passed and the remote certification result contained in the remote certification report is certified,
- the first to-be-verified hash value is extracted from the self-recommendation information carried in the remote attestation report, and the first to-be-verified hash value is the hash value of the preset information of the trusted execution environment;
- the obtained first standard hash value for the trusted execution environment is compared with the first hash value to be verified, and the comparison result is consistent as a prerequisite for confirming that the trusted execution environment is trustworthy.
- the data user obtains the first identity information provided by the privacy computing node, and hashes the obtained first identity information to obtain the second hash value to be verified.
- One identity information includes the identity public key of the private computing node and other identity information of the private computing node; the data user obtains the second standard hash value provided by the private computing node, and the second standard Ha
- the hope value is obtained by hashing the generated identity information after the privacy computing node generates its own identity information in the trusted execution environment; the data user compares the second hash value to be verified with The second standard hash value is compared, and the identity public key included in the first identity information of the privacy computing node is obtained if the comparison result is consistent.
- the data user performs signature verification on the remote certification report according to the public key of the certification server, and when the signature verification is passed and the remote certification result contained in the remote certification report is certified, Obtain the second identity information provided by the privacy computing node, and perform a hash calculation on the acquired second identity information to obtain a third hash value to be verified.
- the second identity information includes the privacy computing node's An identity public key, other identity information of the privacy computing node, and 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;
- the third standard hash value provided by the privacy computing node, and the third hash value to be verified is compared with a third standard hash value, and the third standard hash value is determined by the privacy computing node
- the generated identity information is hashed to obtain; in the case that the third hash value to be verified is consistent with the third standard hash value, Comparing the pre-obtained fourth standard hash value for the trusted execution environment with the fourth hash value to be verified, and the consistency of the comparison result is used as a prerequisite for confirming that the trusted execution environment is trustworthy;
- the identity public key included in the second identity information is used to perform signature verification on the contract information to be verified.
- FIG. 11 is a flowchart of a method for invoking a contract on the side of a privacy computing node provided by an exemplary embodiment. As shown in FIG. 11, the method may include step 1102 to step 1104.
- Step 1102 The privacy computing node receives a call request for the smart contract deployed by the privacy computing node submitted by the data user.
- the call request includes the target ciphertext data obtained by encrypting the target plaintext data and the target ciphertext data. A verifiable statement of the right to use plaintext data.
- Step 1104 The private computing node executes the smart contract in a trusted execution environment created by the private computing node to process the target plaintext data when the calling condition is met, and the calling condition includes The verifiable statement determines that the data owner of the target plaintext data grants the use right to the data user.
- the privacy computing node determines that the data owner has granted the use right to the data user under the condition that the following verification operations are all passed: for the data recorded in the call request
- the first authenticity check operation for the identity of the owner, the second authenticity check operation for the identity of the data user recorded in the call request, and the actual issuer of the verifiable statement is the The third authenticity check operation of the data owner, and the fourth authenticity check operation of the data user that the actual issuance object of the verifiable statement is the data user.
- the privacy computing node determines that the first signature information corresponding to the target plaintext data in the call request is signed and verified by the first user public key and the signature verification is passed.
- An authenticity verification operation is passed, and the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; the privacy computing node is passing the second user
- the public key performs signature verification on the second signature information corresponding to the call request in the call request and the signature verification is passed, it is determined that the second authenticity verification operation is passed, and the second user public key and The second decentralized identity identifier of the data user recorded in the call request corresponds;
- the decentralized identity identifier of the actual issuer of the verifiable statement by the privacy computing node corresponds to the first decentralized identity identifier In the case that a decentralized identity identifier matches, it is determined that the third authenticity verification operation is passed; the decentralized identity identifier of the actual issuance object of the verifiable statement is determined by the privacy computing node and the In the case
- the determination by the privacy computing node of the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer includes: reading the verifiable statement in the call request Record the decentralized identity identifier of the issuer, and obtain the third user public key corresponding to the read decentralized identity identifier; use the third user public key to verify the statement in the call request Perform signature verification on the recorded signature, and use the decentralized identity identifier of the issuer of the verifiable claim record in the call request as the decentralized identity identifier of the actual issuer if the signature verification is passed; and And use the decentralized identity identifier of the issuance object of the verifiable claim record in the call request as the decentralized identity identifier of the actual issuance object.
- the invocation condition also includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: the contract function in the smart contract that allows the processing of the target plaintext data, the validity period of the right to use the target plaintext data, and the permission to call the smart contract to all The number of times the target plaintext data is processed and the frequency of allowing the smart contract to be called to process the target plaintext data.
- the private computing node before receiving the call request, provides the data user with a remote attestation report for the trusted execution environment, and the remote attestation report is sent by the authentication server to the private computing node against the private computing node.
- the self-recommended information generated by the trusted execution environment is generated after verification; the private computing node provides the data user with the contract information to be verified of the smart contract deployed at the private computing node, and the contract information to be verified Signed by the private computing node in the trusted execution environment using the private identity key of the private computing node, and the private identity key is maintained by the private computing node in the trusted execution environment;
- the data user uses the identity public key of the private computing node to perform signature verification on the contract information to be verified when the data user determines that the trusted execution environment is credible according to the remote attestation report , And perform contract information verification on the contract information to be verified according to the contract information of the smart contract, and if the signature verification and contract information verification are passed, determine that the data user initiates
- the self-recommendation information carried in the remote attestation report contains the first hash value to be verified, and the first hash value to be verified is the hash value of the preset information of the trusted execution environment
- the first hash value to be verified is used by the data user to verify the signature of the remote attestation report according to the public key of the authentication server, and the signature verification is passed and the remote attestation report contains the remote authentication result In the case of passing the authentication, it is compared with the pre-obtained first standard hash value for the trusted execution environment, and the comparison result is consistent as the premise for the data user to confirm that the trusted execution environment is trustworthy condition.
- the private computing node provides first identity information to the data user, and the first identity information includes the identity public key of the private computing node and other identity information of the private computing node, so The first identity information is hashed by the data user to obtain a second hash value to be verified; the privacy calculation node provides a second standard hash value to the data user, and the second standard The hash value is obtained by hashing the generated identity information after the privacy computing node generates its own identity information in the trusted execution environment; the second standard hash value is used to compare with the second waiting The hash value is verified for comparison, and the data user obtains the identity public key included in the first identity information of the privacy computing node when the comparison result is consistent.
- the private computing node provides its own second identity information to the data user, and the second identity information includes the identity public key of the private computing node and other identity information of the private computing node And 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;
- the privacy computing node provides a third Standard hash value, the third standard hash value is obtained by hashing the generated identity information after the privacy computing node generates its own identity information in the trusted execution environment; the second identity information
- the data user performs signature verification on the remote certification report according to the public key of the authentication server, and when the signature verification is passed and the remote certification result contained in the remote certification report is certified, the data The user performs a hash calculation to obtain the third hash value to be verified; wherein the precondition for confirming that the trusted execution environment is credible is included in the third hash value to be verified and the third standard hash value. If the desired value is consistent, the fourth hash value to be verified is consistent with the fourth standard
- this specification also provides an embodiment of a device for invoking a contract.
- the embodiment of the apparatus for invoking a contract in this specification can be applied to an electronic device.
- the device embodiments can be implemented by software, or can be implemented by hardware or a combination of software and hardware.
- Taking software implementation as an example as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.
- FIG. 12 is a schematic structural diagram of a device provided by an exemplary embodiment.
- the device includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile memory 1210, and of course, it may also include hardware required for other services.
- the processor 1202 reads the corresponding computer program from the non-volatile memory 1210 to the memory 1208 and then runs it, forming a device for calling the contract on a logical level.
- one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and so on. That is to say, the execution subject of the following processing flow is not limited to each
- the logic unit can also be a hardware or a logic device.
- the device for invoking a contract on the data user side may include: a generating unit 1301, which enables the data user to generate a call request for the off-chain contract.
- the target ciphertext data obtained by encrypting the target plaintext data and the verifiable statement of the right to use the target plaintext data; the submission unit 1302 enables the data user to deploy the chain through the oracle mechanism of the blockchain
- the off-chain privacy computing node of the next contract submits the invocation request, and the invocation request is used to instruct the off-chain privacy computing node in the case that the invocation conditions are met, the off-chain privacy computing node created by the off-chain privacy computing node can be
- the off-chain contract is executed in the trust execution environment to process the target plaintext data, and the invocation condition includes determining that the data owner of the target plaintext data grants the data user to the data user according to the verifiable statement. The right to use.
- the submission unit 1302 is specifically configured to: enable the data user to submit the invocation request to a blockchain node, and the blockchain node will send the data to the off-chain private computing node through the oracle mechanism. Forward the invocation request; or, in the case that the off-chain privacy computing node belongs to the off-chain privacy computing cluster, the data user submits the invocation request to the blockchain node, and the blockchain node passes the The oracle mechanism forwards the invocation request to the control node of the off-chain privacy computing cluster, and the invocation request is forwarded by the control node to the off-chain privacy computing node.
- the off-chain privacy computing node determines that the data owner has granted the use right to the data user: for all records recorded in the call request.
- the first authenticity check operation of the identity of the data owner, the second authenticity check operation of the identity of the data user recorded in the call request, and the actual issuer of the verifiable claim are The third authenticity check operation of the data owner, and the fourth authenticity check operation of the data user that the actual issuance object of the verifiable statement is the data user.
- the first authenticity verification operation is determined Pass
- the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; in the call request through the second user public key, it corresponds to all
- the second signature information of the call request is subjected to signature verification and the signature verification is passed
- it is determined that the second authenticity verification operation is passed
- the second user public key is used with the data recorded in the call request Corresponding to the second decentralized identity identifier of the party; in the case that the decentralized identity identifier of the actual issuer of the verifiable claim matches the first decentralized identity identifier, it is determined that the The third authenticity verification operation is passed; in the case that the decentralized identity identifier of the actual issuance object of the verifiable claim matches the second decentralized identity identifier, the fourth authenticity is determined The verification operation passed.
- the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer are determined by the following method: read the issuer’s verifiable claim record in the call request Decentralized identity identifier, and obtain the third user public key corresponding to the read decentralized identity identifier; use the third user public key to sign the signature of the verifiable statement record in the call request Verify, and use the decentralized identity identifier of the issuer of the verifiable claim record in the call request as the decentralized identity identifier of the actual issuer if the signature verification is passed;
- the decentralized identity identifier of the issuing object in the verifiable statement record in the request is used as the decentralized identity identifier of the actual issuing object.
- the invocation condition further includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: a contract function in the off-chain contract that allows processing of the target plaintext data, the validity period of the right to use the target plaintext data, and permission to call the off-chain contract pair The number of times the target plaintext data is processed and the frequency at which the off-chain contract is allowed to be invoked to process the target plaintext data.
- the target ciphertext data is obtained by encrypting the target plaintext data by the data owner using the contract identity public key of the off-chain contract, and the off-chain trusted execution environment is maintained in the corresponding The contract identity private key of the contract identity public key, and the target ciphertext data is decrypted by the off-chain privacy computing node in the off-chain trusted execution environment using the contract identity private key.
- the submission unit 1302 is specifically configured to: enable the data user to obtain the execution result that the off-chain privacy computing node feeds back to the blockchain node through the oracle mechanism, and the execution result is determined by the The off-chain privacy computing node is obtained by executing the off-chain contract, and is signed using the contract identity private key of the off-chain contract in the off-chain trusted execution environment; the data user is using the off-chain In the case where the contract identity public key of the contract performs signature verification on the execution result and the signature verification is passed, it is determined that the execution result is generated by the off-chain contract.
- the device before submitting the invocation request, the device further includes: a report obtaining unit 1303, which enables the data user to obtain a remote attestation report for the trusted execution environment under the chain, where the remote attestation report is generated by The authentication server verifies the self-recommended information generated by the off-chain private computing node for the off-chain trusted execution environment; the information acquisition unit 1304 enables the data user to determine the chain according to the remote attestation report When the trusted execution environment is credible, obtain the contract information to be verified of the off-chain contract deployed at the off-chain private computing node, and the contract to be verified is stored by the off-chain private computing node.
- a report obtaining unit 1303 which enables the data user to obtain a remote attestation report for the trusted execution environment under the chain, where the remote attestation report is generated by The authentication server verifies the self-recommended information generated by the off-chain private computing node for the off-chain trusted execution environment; the information acquisition unit 1304 enables the data user to determine the chain according to the remote
- the off-chain trusted execution environment is signed using the identity private key of the off-chain private computing node, and the identity private key is maintained by the off-chain private computing node in the off-chain trusted execution environment; verification unit 1305.
- Make the data user use the identity public key of the off-chain privacy computing node to perform signature verification on the to-be-verified contract information, and perform a contract on the to-be-verified contract information according to the contract information of the off-chain contract Information verification, and when the signature verification and contract information verification are passed, it is determined that when the data user initiates a call to the off-chain contract through the oracle mechanism, the off-chain contract is protected by the off-chain privacy
- the computing node executes in the trusted execution environment under the chain.
- the report obtaining unit 1303 is specifically configured to: enable the data user to initiate a challenge to the off-chain private computing node, and receive a remote attestation report returned by the off-chain private computing node; or In the case that the off-chain privacy computing node belongs to the off-chain privacy computing cluster, the data user initiates a challenge to the control node of the off-chain privacy computing cluster, and receives a remote certification report returned by the control node.
- the information acquisition unit 1304 is specifically configured to: enable the data user to perform signature verification on the remote certification report according to the public key of the authentication server; If the remote authentication result is passed authentication, extract the first to-be-verified hash value from the self-recommendation information carried in the remote attestation report, and the first to-be-verified hash value is the trusted execution off-chain
- the hash value of the preset information of the environment; the first standard hash value obtained in advance for the trusted execution environment of the chain is compared with the first hash value to be verified, and the comparison result is consistent as confirmation The prerequisite for the trustworthiness of the trusted execution environment under the chain.
- the verification unit 1305 is specifically configured to: enable the data user to obtain the first identity information provided by the off-chain privacy computing node, and perform a hash calculation on the obtained first identity information to obtain the first identity information 2.
- the hash value to be verified, the first identity information includes the identity public key of the off-chain privacy computing node and other identity information of the off-chain privacy computing node; the data user obtains the off-chain privacy
- the second standard hash value provided by the computing node.
- the second standard hash value is used by the off-chain private computing node to generate its own identity information in the off-chain trusted execution environment. Greek calculation; the data user compares the second hash value to be verified with the second standard hash value, and obtains the first identity of the privacy computing node if the comparison result is consistent
- the identity public key contained in the information is specifically configured to: enable the data user to obtain the first identity information provided by the off-chain privacy computing node, and perform a hash calculation on the obtained first identity information to obtain the first identity information 2.
- the information acquisition unit 1304 is specifically configured to: enable the data user to perform signature verification on the remote certification report according to the public key of the authentication server, and verify the signature of the remote certification report after the signature verification is passed and the remote certification report contains information If the remote authentication result is that the authentication is passed, the second identity information provided by the off-chain privacy computing node is obtained, and the obtained second identity information is hashed to obtain the third hash value to be verified, so
- the second identity information includes the identity public key of the off-chain privacy computing node, other identity information of the off-chain privacy computing node, and a fourth hash value to be verified, and the fourth hash value to be verified.
- the hash value of the preset information of the off-chain trusted execution environment obtain the third standard hash value provided by the off-chain privacy computing node, and compare the third hash value to be verified with the third standard
- the hash value is compared, and the third standard hash value is obtained by hashing the generated identity information after the off-chain privacy computing node generates its own identity
- the call request is encrypted by the data user using the identity public key of the off-chain private computing node, and the identity private key corresponding to the identity public key is maintained in the off-chain trusted execution environment.
- the invocation request is decrypted by the off-chain private computing node using the identity private key in the off-chain trusted execution environment.
- the identity private key of the off-chain private computing node is the node identity private key in the node identity key of the off-chain private computing node
- the identity public key of the off-chain private computing node is the node The node identity public key in the identity key; wherein, in the process of the blockchain node interacting with the off-chain privacy computing node to deploy or call the off-chain contract, the node identity key is used to perform interactive data Encryption and decryption and/or signature verification; or, in the case that the off-chain private computing node belongs to the off-chain private computing cluster, the identity public key of the off-chain private computing node is the cluster of the off-chain private computing cluster
- the cluster identity public key in the identity key, the identity private key of the off-chain private computing node is the cluster identity private key in the cluster identity key; wherein, the blockchain node and the off-chain private computing cluster In the process of each node interacting to deploy or call an off-chain contract, the cluster identity key is used to encrypt and de
- the device for invoking the contract on the side of the off-chain private computing node may include: a receiving unit 1401, which enables the off-chain private computing node to receive data from the user through the oracle mechanism of the blockchain A submitted call request for the off-chain contract deployed by the off-chain privacy computing node, the call request includes the target ciphertext data obtained by encrypting the target plaintext data and the permission for the right to use the target plaintext data Verification statement; execution unit 1402, enabling the off-chain private computing node to execute the off-chain contract in the off-chain trusted execution environment created by the off-chain private computing node when the calling conditions are satisfied
- the target plaintext data is processed, and the calling condition includes determining that the data owner of the target plaintext data grants the use right to the data user according to the verifiable statement.
- the off-chain privacy computing node receives the call request forwarded by the blockchain node through the oracle mechanism, and the call request is submitted to the blockchain node by the data user;
- the off-chain privacy computing node receives the invocation request forwarded by the control node of the off-chain privacy computing cluster, and the invocation request is determined by The data user submits to the blockchain node, and is forwarded to the control node by the blockchain node through the oracle mechanism.
- the off-chain privacy computing node determines that the data owner has granted the use right to the data user when the following verification operations are passed: for the data recorded in the call request The first authenticity check operation of the identity of the data owner, the second authenticity check operation of the identity of the data user recorded in the call request, and the actual issuer of the verifiable claim The third authenticity check operation of the data owner, and the fourth authenticity check operation of the data user that the actual issuance object of the verifiable statement is the data user.
- the off-chain privacy computing node performs signature verification on the first signature information corresponding to the target plaintext data in the call request by using the first user public key, and the signature verification is passed, determine the The first authenticity verification operation is passed, and the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; the off-chain privacy computing node is passing If the second user public key performs signature verification on the second signature information corresponding to the call request in the call request and the signature verification is passed, it is determined that the second authenticity verification operation is passed, and the second user The public key corresponds to the second decentralized identity identifier of the data user recorded in the call request; the decentralized identity of the off-chain privacy computing node in the actual issuer of the verifiable statement In the case where the ID matches the first decentralized identity identifier, it is determined that the third authenticity verification operation is passed; the off-chain privacy computing node is decentralized in the actual issuance of the verifiable statement. In the case that the identity identifier matches the second
- the execution unit 1402 is specifically configured to: enable the off-chain privacy computing node to read the decentralized identity identifier of the issuer of the verifiable statement record in the call request, and obtain and read the decentralized identity identifier
- the third user public key corresponding to the decentralized identity identifier; the third user public key is used to perform signature verification on the signature of the verifiable statement record in the call request, and if the signature verification is passed, the call
- the decentralized identity identifier of the issuer of the verifiable claim record in the request is used as the decentralized identity identifier of the actual issuer; and the decentralized identity of the issuer of the verifiable claim record in the call request
- the identifier serves as the decentralized identity identifier of the actual issuance object.
- the invocation condition further includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: a contract function in the off-chain contract that allows processing of the target plaintext data, the validity period of the right to use the target plaintext data, and permission to call the off-chain contract pair The number of times the target plaintext data is processed and the frequency at which the off-chain contract is allowed to be called to process the target plaintext data.
- the target ciphertext data is obtained by encrypting the target plaintext data by the data owner using the contract identity public key of the off-chain contract, and the off-chain trusted execution environment is maintained in the corresponding The contract identity private key of the contract identity public key, and the target ciphertext data is decrypted by the off-chain privacy computing node in the off-chain trusted execution environment using the contract identity private key.
- the execution unit 1402 is specifically configured to: the off-chain private computing node uses the contract identity private key pair of the off-chain contract in the off-chain trusted execution environment to execute the off-chain contract.
- the execution result is signed; the off-chain privacy computing node feeds back the execution result to the blockchain node through the oracle mechanism to be obtained by the data user, and the data user is using the off-chain contract
- the contract identity public key of the performs signature verification on the execution result and the signature verification is passed, it is determined that the execution result is generated by the off-chain contract.
- the device before receiving the invocation request, further includes: a report providing unit 1403, which enables the off-chain private computing node to provide the data user with a remote attestation report for the off-chain trusted execution environment.
- the remote certification report is generated by the authentication server after verifying the self-recommended information generated by the off-chain private computing node for the off-chain trusted execution environment; the information providing unit 1404 enables the off-chain private computing node to use the data
- the party provides the to-be-verified contract information of the off-chain contract deployed at the off-chain private computing node, and the to-be-verified contract information is used by the off-chain private computing node in the off-chain trusted execution environment.
- the identity private key of the off-chain private computing node is signed, and the identity private key is maintained by the off-chain private computing node in the off-chain trusted execution environment; the contract information to be verified is used by the data user In the case that the off-chain trusted execution environment is determined to be credible according to the remote attestation report, the identity public key of the off-chain private computing node is used to perform signature verification on the contract information to be verified, and according to the chain
- the contract information of the next contract performs contract information verification on the contract information to be verified, and if the signature verification and contract information verification pass, it is determined that the data user is checking the chain through the oracle mechanism of the blockchain node.
- the off-chain contract is executed by the off-chain privacy computing node in the off-chain trusted execution environment.
- the report providing unit 1403 is specifically configured to: enable the off-chain privacy computing node to receive a challenge initiated by the off-chain privacy computing node by the data user, and return the remote attestation to the data user Report; or, in the case that the off-chain privacy computing node belongs to the off-chain privacy computing cluster, after the control node of the off-chain privacy computing cluster receives the challenge initiated by the data user, it sends to the control node The remote certification report is sent, and the remote certification report is returned by the control node to the data user.
- the self-recommendation information carried in the remote attestation report includes a first to-be-verified hash value
- the first to-be-verified hash value is a hash of preset information of the off-chain trusted execution environment
- the first hash value to be verified is used by the data user to verify the signature of the remote attestation report according to the public key of the authentication server and verify the signature and the remote attestation contained in the remote attestation report If the result is authenticated, it is compared with the pre-obtained first standard hash value for the trusted execution environment of the chain, and the comparison result is consistent as the data user confirms the trusted execution of the chain A prerequisite for a credible environment.
- the information providing unit 1404 is specifically configured to: enable the off-chain private computing node to provide first identity information to the data user, where the first identity information includes the identity of the off-chain private computing node The public key and other identity information of the off-chain privacy computing node, the first identity information is hashed by the data user to obtain a second hash value to be verified; and the data user is provided with the first identity information
- Two standard hash values the second standard hash value is obtained by hashing the generated identity information after the off-chain privacy computing node generates its own identity information in the off-chain trusted execution environment; The second standard hash value is used for comparison with the second hash value to be verified, and if the comparison result is consistent, the data user obtains the information contained in the first identity information of the privacy computing node The identity public key.
- the information providing unit 1404 is specifically configured to: enable the off-chain private computing node to provide its own second identity information to the data user, where the second identity information includes the off-chain private computing node The identity public key of the off-chain privacy computing node, and the fourth hash value to be verified, where the fourth hash value to be verified is the value of the preset information of the trusted execution environment off-chain Hash value; provide a third standard hash value to the data user, after the third standard hash value is generated by the off-chain privacy computing node in the off-chain trusted execution environment The generated identity information is obtained by hash calculation; the data user performs signature verification on the remote attestation report according to the public key of the authentication server, and when the signature verification is passed and the remote attestation In the case where the remote authentication result contained in the report is passed authentication, the data user performs a hash calculation to obtain the third hash value to be verified; among them, it is a prerequisite to confirm that the off-chain trusted execution environment is trustworthy In the case where the third hash value
- the identity private key corresponding to the identity public key is maintained in the off-chain trusted execution environment; the receiving unit 1401 is specifically configured to:
- the off-chain private computing node uses the identity private key to decrypt the invocation request in the off-chain trusted execution environment, and the invocation request is used by the data user using the off-chain private computing node’s
- the identity public key is encrypted.
- the identity private key of the off-chain private computing node is the node identity private key in the node identity key of the off-chain private computing node
- the identity public key of the off-chain private computing node is the node The node identity public key in the identity key; wherein, in the process of the blockchain node interacting with the off-chain privacy computing node to deploy or call the off-chain contract, the node identity key is used to perform interactive data Encryption and decryption and/or signature verification; or,
- the identity public key of the off-chain privacy computing node is the cluster identity public key in the cluster identity key of the off-chain privacy computing cluster
- the identity private key of the off-chain private computing node is the cluster identity private key in the cluster identity key
- the blockchain node interacts with each node in the off-chain private computing cluster to deploy or call the chain
- the cluster identity key is used to encrypt and decrypt interactive data and/or verify signatures.
- the device for invoking a contract on the data user side may include: a generating unit 1501, which enables the data user to generate a call request for the smart contract.
- the target ciphertext data obtained by encrypting the target plaintext data and the verifiable statement of the right to use the target plaintext data; the submission unit 1502, causing the data use to submit the call to the privacy computing node where the smart contract is deployed Request, the invocation request is used to instruct the private computing node to execute the smart contract in the trusted execution environment created by the private computing node to process the target plaintext data when the invocation condition is met
- the calling condition includes determining that the data owner of the target plaintext data grants the use right to the data user according to the verifiable statement.
- the privacy computing node determines that the data owner has granted the use right to the data user: for the data recorded in the call request
- the first authenticity check operation for the identity of the owner, the second authenticity check operation for the identity of the data user recorded in the call request, and the actual issuer of the verifiable statement is the The third authenticity check operation of the data owner, and the fourth authenticity check operation of the data user that the actual issuance object of the verifiable statement is the data user.
- the first authenticity verification operation is determined Pass
- the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; in the call request through the second user public key, it corresponds to all
- the second signature information of the call request is subjected to signature verification and the signature verification is passed
- it is determined that the second authenticity verification operation is passed
- the second user public key is used with the data recorded in the call request Corresponding to the second decentralized identity identifier of the party; in the case that the decentralized identity identifier of the actual issuer of the verifiable claim matches the first decentralized identity identifier, it is determined that the The third authenticity verification operation is passed; in the case that the decentralized identity identifier of the actual issuance object of the verifiable claim matches the second decentralized identity identifier, the fourth authenticity is determined The verification operation passed.
- the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer are determined by the following method: read the issuer’s verifiable claim record in the call request Decentralized identity identifier, and obtain the third user public key corresponding to the read decentralized identity identifier; use the third user public key to sign the signature of the verifiable statement record in the call request Verify, and use the decentralized identity identifier of the issuer of the verifiable claim record in the call request as the decentralized identity identifier of the actual issuer if the signature verification is passed;
- the decentralized identity identifier of the issuing object in the verifiable statement record in the request is used as the decentralized identity identifier of the actual issuing object.
- the invocation condition further includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: a contract function in the smart contract that allows processing of the target plaintext data, the validity period of the right to use the target plaintext data, and permission to call the smart contract to the The number of times the target plaintext data is processed and the frequency of allowing the smart contract to be invoked to process the target plaintext data.
- the device before submitting the invocation request, the device further includes: a report obtaining unit 1503, which enables the data user to obtain a remote certification report for the trusted execution environment, and the remote certification report is issued by the authentication server
- the information acquisition unit 1504 After verifying the self-recommended information generated by the private computing node for the trusted execution environment, the information acquisition unit 1504 enables the data user to determine that the trusted execution environment is trustworthy according to the remote attestation report. In this case, the contract information to be verified of the smart contract deployed at the private computing node is acquired, and the contract information to be verified is used by the private computing node in the trusted execution environment.
- the identity private key is signed by the private computing node in the trusted execution environment; the verification unit 1505 enables the data user to use the identity public key of the private computing node to Perform signature verification on the contract information to be verified, and perform contract information verification on the contract information to be verified according to the contract information of the smart contract, and if the signature verification and contract information verification pass, it is determined that the data user is
- the smart contract initiates a call, the smart contract is executed by the privacy computing node in the trusted execution environment.
- the report obtaining unit 1503 is specifically configured to: perform signature verification on the remote certification report according to the public key of the certification server; when the signature verification is passed and the remote certification result contained in the remote certification report is certified Next, extract a first to-be-verified hash value from the self-recommendation information carried in the remote attestation report, where the first to-be-verified hash value is a hash value of preset information of the trusted execution environment; The pre-obtained first standard hash value for the trusted execution environment is compared with the first hash value to be checked, and the comparison result is consistent as a prerequisite for confirming that the trusted execution environment is trustworthy.
- the information obtaining unit 1504 is specifically configured to: the data user obtains the first identity information provided by the privacy computing node, and performs a hash calculation on the obtained first identity information to obtain the second to-be-verified Hash value, the first identity information includes the identity public key of the private computing node and other identity information of the private computing node; the data user obtains the second standard hash value provided by the private computing node The second standard hash value is obtained by hashing the generated identity information after the privacy computing node generates its own identity information in the trusted execution environment; the data user calculates the second The hash value to be verified is compared with the second standard hash value, and the identity public key included in the first identity information of the privacy computing node is obtained if the comparison result is consistent.
- the information acquisition unit 1504 is specifically configured to: perform signature verification on the remote certification report according to the public key of the certification server, and when the signature verification is passed and the remote certification result contained in the remote certification report is certified Next, obtain the second identity information provided by the privacy calculation node, and perform a hash calculation on the obtained second identity information to obtain a third hash value to be verified, where the second identity information includes the privacy calculation The identity public key of the node, other identity information of the privacy computing node, and 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 ; Obtain a third standard hash value provided by the privacy computing node, and compare the third hash value to be verified with a third standard hash value, and the third standard hash value is determined by the privacy After the computing node generates its own identity information in the trusted execution environment, it is obtained by hashing the generated identity information; in the case that the third hash value to be verified is consistent with the third standard hash value
- the device for invoking a contract on the side of a privacy computing node may include: a receiving unit 1601, which enables the privacy computing node to receive a smart contract for deployment on the privacy computing node submitted by a data user
- the call request includes the target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the right to use the target plaintext data;
- the execution unit 1602 causes the privacy computing node to call If the condition is met, execute the smart contract in the trusted execution environment created by the privacy computing node to process the target plaintext data, and the call condition includes determining the target according to the verifiable statement
- the data owner of the plaintext data grants the use right to the data user.
- the privacy computing node determines that the data owner has granted the use right to the data user under the condition that the following verification operations are all passed: ownership of the data recorded in the call request
- the first authenticity check operation of the identity of the party, the second authenticity check operation of the identity of the data user recorded in the call request, and the actual issuer of the verifiable claim is the data
- the privacy computing node performs signature verification on the first signature information corresponding to the target plaintext data in the invocation request by using the first user public key, and the signature verification is passed, determines that the first The authenticity verification operation is passed, the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the call request; the privacy computing node is passing the second user public key If the key performs signature verification on the second signature information corresponding to the call request in the call request and the signature verification is passed, it is determined that the second authenticity verification operation is passed, and the second user public key is the same as the The second decentralized identity identifier of the data user recorded in the call request corresponds; the decentralized identity identifier of the actual issuer of the verifiable statement of the privacy computing node corresponds to the first decentralized identity identifier In the case that the decentralized identity identifier matches, it is determined that the third authenticity verification operation is passed; the privacy computing node determines that the decentralized identity identifier of the actual issuance object of the verifiable
- the determination by the privacy computing node of the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer includes: reading the verifiable statement record in the call request The decentralized identity identifier of the issuer of the issuer, and obtain the third user public key corresponding to the read decentralized identity identifier; use the third user public key to record the verifiable statement in the call request Perform signature verification on the signature of, and use the decentralized identity identifier of the issuer of the verifiable claim record in the call request as the decentralized identity identifier of the actual issuer if the signature verification is passed; and, The decentralized identity identifier of the issuing object in the verifiable claim record in the call request is used as the decentralized identity identifier of the actual issuing object.
- the invocation condition further includes that the invocation operation indicated by the invocation request complies with the invocation rule defined by the verifiable statement.
- the calling rule includes at least one of the following: a contract function in the smart contract that allows processing of the target plaintext data, the validity period of the right to use the target plaintext data, and permission to call the smart contract to the The number of times the target plaintext data is processed and the frequency of allowing the smart contract to be invoked to process the target plaintext data.
- the device before receiving the call request, the device further includes: a report providing unit 1603, which enables the privacy computing node to provide a data user with a remote attestation report for the trusted execution environment, where the remote attestation report is determined by The authentication server verifies the self-recommended information generated by the private computing node for the trusted execution environment and generates it; the information providing unit 1604 enables the private computing node to provide the data user with deployment at the private computing node
- the contract information to be verified of the smart contract, the contract information to be verified is signed by the privacy computing node in the trusted execution environment using the identity private key of the privacy computing node, and the identity private key is The privacy computing node is maintained in the trusted execution environment; the contract information to be verified is used by the data user when it is determined that the trusted execution environment is credible according to the remote attestation report
- the identity public key of the privacy computing node performs signature verification on the contract information to be verified, and performs contract information verification on the contract information to be verified according to the contract information of the smart contract, and
- the self-recommendation information carried in the remote attestation report includes a first to-be-verified hash value
- the first to-be-verified hash value is a hash value of preset information of the trusted execution environment
- the first hash value to be verified is used by the data user to verify the signature of the remote certification report according to the public key of the authentication server, and the signature verification is passed, and the remote certification result contained in the remote certification report is In the case of passing the authentication, it is compared with the pre-obtained first standard hash value for the trusted execution environment, and the comparison result is consistent as a prerequisite for the data user to confirm that the trusted execution environment is trustworthy .
- the information providing unit 1604 is specifically configured to: the privacy computing node provides first identity information to the data user, where the first identity information includes the identity public key of the privacy computing node and the privacy computing node Other identity information of the node, the first identity information is hashed by the data user to obtain a second hash value to be verified; the privacy calculation node provides the data user with a second standard hash The second standard hash value is obtained by hashing the generated identity information after the privacy computing node generates its own identity information in the trusted execution environment; the second standard hash value is When comparing with the second hash value to be verified, and the data user obtains the identity public key included in the first identity information of the privacy computing node when the comparison result is consistent.
- the information providing unit 1604 is specifically configured to: the private computing node provides its own second identity information to the data user, where the second identity information includes the identity public key of the private computing node, the The other identity information of the privacy computing node and the fourth hash value to be verified, where the fourth hash value to be verified is the hash value of the preset information of the trusted execution environment;
- the data user provides a third standard hash value, and the third standard hash value is obtained by hashing the generated identity information after the privacy computing node generates its own identity information in the trusted execution environment
- the second identity information performs signature verification on the remote attestation report according to the public key of the authentication server by the data user, and after the signature verification is passed and the remote attestation report contains the remote attestation result is certified
- a hash calculation is performed by the data user to obtain a third hash value to be verified; wherein the precondition for confirming that the trusted execution environment is credible is included in the third hash value to be verified If the hash value is consistent with the third standard
- a typical implementation device is a computer.
- the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
- this specification can be provided as a method, a system, or a computer program product. Therefore, this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
- computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
- program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
- This specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network.
- program modules can be located in local and remote computer storage media including storage devices.
- These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
- the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
- These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
- the instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
- the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
- the memory may include non-permanent 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 computer readable media.
- RAM random access memory
- ROM read-only memory
- flash RAM flash memory
- Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
- the information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media, can be used to store information that can be accessed by computing devices.
- computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Medical Informatics (AREA)
- Storage Device Security (AREA)
Abstract
本说明书提供一种调用合约的方法及装置,该方法可以包括: 数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明; 所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。上述调用合约的过程可确保数据安全和隐私保护。
Description
本说明书一个或多个实施例涉及可验证计算技术领域,尤其涉及一种调用合约的方法及装置。
针对各种场景下的隐私需求,一种方式是通过同态加密(Homomorphic encryption)和零知识证明(Zero-knowledge proof)等加密技术实现隐私保护,但也随之带来了严重的性能损失。可信执行环境(Trusted Execution Environment,TEE)是另一种解决方式。TEE可以起到硬件中的黑箱作用,在TEE中执行的代码和数据操作系统层都无法偷窥,只有代码中预先定义的接口才能对其进行操作。在效率方面,由于TEE的黑箱性质,在TEE中进行运算的是明文数据,而不是同态加密中的复杂密码学运算,计算过程效率没有损失。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种调用合约的方法及装置。
根据本说明书一个或多个实施例的第一方面,提出了一种调用合约的方法,包括:数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第二方面,提出了一种调用合约的方法,包括:链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述链下隐私计算节点在调用条件被满足的情况下在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第三方面,提出了一种调用合约的方法,包括:数据使用方生成针对智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述数据使用方向部署有所述智能合约的隐私计算节点提交所述调用请求,所述调用请求用于指示所述隐私计算节点在调用条件被满足的情况下,在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第四方面,提出了一种调用合约的方法,包括:隐私计算节点接收数据使用方提交的针对所述隐私计算节点部署的智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述隐私计算节点在调用条件被满足的情况下在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第五方面,提出了一种调用合约的装置,包括:生成单元,使数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目 标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;提交单元,使所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第六方面,提出了一种调用合约的装置,包括:接收单元,使链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;执行单元,使所述链下隐私计算节点在调用条件被满足的情况下在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第七方面,提出了一种调用合约的装置,包括:生成单元,使数据使用方生成针对智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;提交单元,使所述数据使用方向部署有所述智能合约的隐私计算节点提交所述调用请求,所述调用请求用于指示所述隐私计算节点在调用条件被满足的情况下,在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第八方面,提出了一种调用合约的装置,包括:接收单元,使隐私计算节点接收数据使用方提交的针对所述隐私计算节点部署的智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;执行单元,使所述隐私计算节点在调用条件被满足的情况下在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
根据本说明书一个或多个实施例的第九方面,提出了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如第一方面、第二方面、第三方面或第四方面所述的方法。
根据本说明书一个或多个实施例的第十方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如第一方面、第二方面、第三方面或第四方面所述方法的步骤。
图1是一示例性实施例提供的一种验证链下合约的方法的流程图。
图2是一示例性实施例提供的验证链下合约的方法的场景示意图。
图3是一示例性实施例提供的验证链下合约的方法的场景示意图。
图4是一示例性实施例提供的一种数据使用方侧的调用合约的方法的流程图。
图5是一示例性实施例提供的一种调用合约的方法的场景示意图。
图6是一示例性实施例提供的创建DID的流程图。
图7是一示例性实施例提供的数据授权过程的流程图。
图8是一示例性实施例提供的另一种调用合约的方法的流程图。
图9是一示例性实施例提供的一种链下隐私计算节点侧的调用合约的方法的流程图。
图10是一示例性实施例提供的另一种数据使用方侧的调用合约的方法的流程图。
图11是一示例性实施例提供的另一种隐私计算节点侧的调用合约的方法的流程图。
图12是一示例性实施例提供的一种设备的示意结构图。
图13是一示例性实施例提供的一种数据使用方侧的调用合约的装置的框图。
图14是一示例性实施例提供的一种链下隐私计算节点侧的调用合约的装置的框图。
图15是一示例性实施例提供的另一种数据使用方侧的调用合约的装置的框图。
图16是一示例性实施例提供的另一种隐私计算节点侧的调用合约的装置的框图。
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。应当理解,尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
区块链一般被划分为三种类型:公有链(Public Blockchain)、私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外,还有多种类型的结合,比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等,且各参与者(即节点)可自由加入以及退出网络。私有链则相反,该网络的数据写入权限由某个组织或者机构控制,数据读取权限受组织规定;简单来说,私有链可以为一个弱中心化系统,参与节点具有严格限制且少,因而私有链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织,参与者通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
在区块链网络中,通过向区块链节点提交相应的区块链交易(简称交易),并由区块链节点执行区块链交易,以实现相应的操作目的。对于上述任何类型的区块链而言,区块链节点均可以通过创建TEE,并将TEE实现为区块链交易的安全执行环境。TEE是基于CPU硬件的安全扩展,且与外部完全隔离的可信执行环境。TEE最早是由Global Platform提出的概念,用于解决移动设备上资源的安全隔离,平行于操作系统为应用程序提供可信安全的执行环境。目前工业界十分关注TEE的方案,几乎所有主流的芯片和软件联盟都有自己的TEE解决方案,比如软件方面的TPM(Trusted Platform Module,可信赖平台模块)以及硬件方面的Intel SGX(Software Guard Extensions,软件保护扩展)、ARM Trustzone(信任区)和AMD PSP(Platform Security Processor,平台安全处理器)等。
以Intel SGX(以下简称SGX)技术为例。区块链节点可以基于SGX技术创建enclave(围圈或飞地),以作为用于执行区块链交易的TEE。其中,区块链节点利用CPU中新增的处理器指令,在内存中可以分配一部分区域EPC(Enclave Page Cache,围圈页面缓存或飞地页面缓存),以用于驻留上述的enclave。上述EPC对应的内存区域被CPU 内部的内存加密引擎MEE(Memory Encryption Engine)加密,该内存区域中的内容(enclave中的代码和数据)只有在CPU内核中才能够被解密,且用于加解密的密钥只有在EPC启动时生成并存储在CPU中。可见,enclave的安全边界只包含其自身和CPU,无论是特权或非特权软件都无法访问enclave,即便是操作系统管理员和VMM(virtual machine monitor,虚拟机监视器;或称为,Hypervisor)也无法影响enclave中的代码和数据,因而具有极高的安全性,并且在上述安全性保障的前提下,CPU能够在enclave中对明文形式的区块链交易进行处理,具有极高的运算效率,从而兼顾了数据安全性和计算效率。
基于区块链网络的去中心化架构,使得区块链上的每笔区块链交易都需要在区块链网络内的所有区块链节点上执行,以确保每个区块链节点所维护的区块链账本数据一致。如果交易逻辑较为简单,比如以比特币为例,区块链交易仅用于实现转账操作,此时即便区块链交易需要在所有区块链节点都执行,也不会导致过多的资源消耗。但是,如果区块链提供了智能合约的功能,而区块链交易调用了智能合约,那么情况可能大不相同。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约,智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑,这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,虚拟机直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”)。智能合约分为部署和调用两个阶段。
在部署阶段,用户将一个包含创建智能合约信息的交易发送至以太坊网络,该交易的data字段包含智能合约的代码(如字节码),该交易的to字段为空。以太坊网络中的各个节点分别通过EVM执行这个交易,并生成对应的合约实例。在节点间通过共识机制达成一致后,上述交易对应的智能合约创建成功,区块链上出现一个与该智能合约对应的合约账户,该合约账户拥有一个特定的合约地址,合约代码(即智能合约的代码)或合约代码的哈希值保存在该合约账户中,该合约代码用于控制相应的智能合约的行为。
在调用阶段,用户(可以与部署智能合约的用户相同或不同)将一个用于调用智能合约的交易发送到以太坊网络,该交易的from字段是该用户对应的外部账户的地址,to字段是所需调用的智能合约的合约地址,data字段包含调用智能合约的方法和参数。在节点间通过共识机制达成一致后,上述交易声明调用的智能合约以规定的方式在以太坊网络的每个节点上独立执行,所有执行记录和数据都保存在区块链上,所以当交易完成后,区块链上就保存了无法篡改、不会丢失的交易凭证。
如前所述,EVM是一个图灵完备的虚拟机;类似地,其他区块链也可以采用其他类型的虚拟机,比如WASM(WebAssembly)虚拟机等。总之,当交易调用的智能合约用于实现相对复杂的逻辑时,节点通过虚拟机执行该智能合约的代码的过程会消耗相对较多的计算资源,并且由于区块链网络内的所有节点都需要执行该智能合约的代码,因此随着节点数量的增加会导致计算资源的消耗量成倍增长。因此,虽然结合TEE技术可以相对减少单个区块链节点的资源消耗、加快交易执行效率,但就整个区块链网络而言,仍然会造成极大的资源消耗和浪费。
为此,本说明书提出了在链下部署隐私计算节点(即链下隐私计算节点),可以将原本需要在所有区块链节点上执行的计算操作转移至链下隐私计算节点处执行,区块链节点只需要从链下隐私计算节点处获取计算结果并基于该计算结果更新区块链账本数据即可,并且可以基于可验证计算(Verifiable Computation)技术证明上述的计算结果确实是在可信执行环境内按照预期执行,从而在确保可靠性的同时,极大地降低了链 上的资源消耗。
如前所述,通过在区块链节点部署智能合约,使得区块链节点可以执行该智能合约的代码以实现相应的计算需求;类似地,可以将用于执行计算任务的代码部署在链下隐私计算节点处,使得链下隐私计算节点可以执行代码以实现相应的计算需求。为了便于理解,本说明书中将部署于区块链节点的合约称为链上合约、将部署于链下隐私计算节点的合约称为链下合约;当然,无论是链上合约还是链下合约,其本质都是一段可以在虚拟机内执行的代码。可配置单节点形式的链下隐私计算节点来执行计算任务;或者,可通过链下隐私计算集群的形式向用户提供高并发和高可用的隐私计算服务,从而解决节点的负载均衡、故障转移、动态扩展缩容等问题。其中,该链下隐私计算集群可以包含一控制节点和多个链下隐私计算节点,各节点用于部署相同的链下合约(至少一个)以执行计算任务,并由该控制节点对集群内的所有链下隐私计算节点进行统一管理。
与上述区块链节点类似,可在链下隐私计算节点上创建链下TEE(即链下可信执行环境),该链下TEE基于CPU硬件实现的与外部完全隔离的可信执行环境。链下隐私计算节点通过创建链下TEE,可以通过该链下TEE实现对链下合约的部署操作以及部署后的调用执行操作,并确保操作过程中的数据安全和隐私保护。举例而言,可在链下隐私计算节点上部署链下合约,并在该链下隐私计算节点创建的链下TEE内部署WASM虚拟机。用户作为目标数据的数据使用方,可向链下隐私计算节点发起一基于WASM程序的计算任务,用于调用链下合约对目标数据进行计算(即目标数据为链下合约的入参数据),那么链下隐私计算节点可将链下合约读入链下TEE内并编译成WASM字节码,以WASM虚拟机作为执行引擎,将编译得到的WASM字节码在WASM虚拟机中执行,以对目标数据进行计算。需要说明的是,本说明书中的链下合约可以实现用户定义的任何计算逻辑。例如,链下合约可以用于验证区块链上存储的加密订单数据的金额是否正确,并将验证结果反馈至链上;再例如,链下合约可以用于根据预设算法对多方数据进行安全计算,即安全多方计算,并将计算结果反馈至链上等,此处不再一一赘述。
数据使用方通过客户端调用链下合约之前,可对链下隐私计算节点中部署的链下合约发起挑战,以确保链下隐私计算节点中部署的链下合约可信,进而按照用户预期执行计算任务。
图1是一示例性实施例提供的一种验证链下合约的方法的流程图。如图1所示,该方法可以包括步骤102~106。
步骤102,所述数据使用方获取针对所述链下可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点针对所述链下可信执行环境产生的自荐信息进行验证后生成。
在本实施例中,链下隐私计算节点包含单节点和链下隐私计算集群两种形式。针对单节点形式,数据使用方直接向链下隐私计算节点发起挑战,从而接收链下隐私计算节点返回的远程证明报告。在该情况下,链下隐私计算节点的身份信息为该链下隐私计算节点的节点身份信息,链下隐私计算节点的身份私钥为该链下隐私计算节点的节点身份私钥,链下隐私计算节点的身份公钥为该链下隐私计算节点的节点身份公钥。针对链下隐私计算集群的形式,在链下隐私计算节点属于链下隐私计算集群的情况下,数据使用方向链下隐私计算集群的控制节点发起挑战,由控制节点来选取链下隐私计算集群中的节点来响应挑战,从而获取选取出的节点的远程证明报告,并向数据使用方返回该远程证明报告。在该情况下,链下隐私计算节点代表链下隐私计算集群与外部对象交互。因此,链下隐私计算节点的身份信息为该链下隐私计算集群的集群身份信息,链下隐私计算节点的身份公钥为该链下隐私计算集群的集群身份密钥中的集群身份公钥,链下隐私计算节点的身份私钥为集群身份密钥中的集群身份私钥。其中,在区块链节点与链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中,集群身份密钥用于 对交互数据进行加密解密和/或签名签名验证。而针对集群身份密钥的生成,可由链下隐私计算集群的控制节点选取集群中的任一节点作为主节点来生成集群身份密钥,并向集群内的其他节点共享集群身份密钥。
步骤104,所述数据使用方在根据所述远程证明报告确定所述链下可信执行环境可信的情况下,获取部署于所述链下隐私计算节点处的所述链下合约的待验证合约信息,所述待验证合约信息被所述链下隐私计算节点在所述链下可信执行环境内采用所述链下隐私计算节点的身份私钥进行签名,所述身份私钥由所述链下隐私计算节点在所述链下可信执行环境内维护。
在本实施例中,远程证明报告产生于针对链下隐私计算节点上的链下TEE的远程证明过程。远程证明报告由认证服务器对链下隐私计算节点产生的自荐信息进行验证后生成,该自荐信息与链下隐私计算节点上创建的链下TEE相关。链下隐私计算节点通过产生与链下TEE相关的自荐信息,并由认证服务器对该自荐信息进行验证后产生远程证明报告,使得远程证明报告可以用于表明链下隐私计算节点上的链下TEE可信任。换言之,远程证明报告由认证服务器对链下隐私计算节点针对自身的链下TEE产生的自荐信息进行验证后生成。
以Intel SGX技术为例,链下TEE为链下隐私计算节点上创建的用于实现链下隐私计算的enclave,远程证明过程还涉及到链下隐私计算节点上另一个特殊的enclave,即quoting enclave(简称QE),QE是由英特尔提供并签名的架构型enclave(Architectural Enclave)。上述enclave首先需要生成一用于本地认证的REPORT(报告)结构,并由QE基于该REPORT结构验证该enclave是否与自身处于同一平台上,而后由QE将该REPORT结构封装为一结构体QUOTE(即自荐信息),并使用EPID(enhanced privacy identification)密钥进行签名。EPID密钥不仅代表链下隐私计算节点这一平台,还代表链下隐私计算节点的底层硬件的可信度,还可以绑定处理器固件的版本等信息,并且只有QE才能访问到EPID密钥,以用于对上述的结构体QUOTE进行签名。在SGX技术中,上述的认证服务器可以为英特尔公司提供的IAS(Intel Attestation Service)服务器,链下隐私计算节点向IAS服务器发送经过签名的上述结构体QUOTE,使得IAS服务器可以对签名进行验证,并向链下隐私计算节点返回相应的远程证明报告。
数据使用方在获得链下隐私计算节点的远程证明报告之后,可以根据该远程证明报告来验证相应的链下隐私计算节点是否可信,具体指验证该链下隐私计算节点上部署的链下TEE是否可信,并在确定链下TEE可信的情况下进一步对部署于该链下隐私计算节点处的链下合约(在该可信的链下TEE内执行)进行校验。
具体而言,链下隐私计算节点在创建链下TEE后,产生用于实现远程证明的自荐信息,该自荐信息可以用于锚定和固化链下TEE的信息,使得最终得到的包含该自荐信息的远程证明报告可以用于表征链下TEE的状态,并用于验证该链下TEE是否可信。例如,自荐信息中可以包含第一待检验哈希值,该第一待检验哈希值为链下TEE中预设信息的哈希值,比如该预设信息可以包括链下TEE内部署的所有代码、该链下TEE的开发者的公钥等。以Intel SGX技术为例,对应于链下TEE内部署的所有代码所生成的哈希值为MREnclave,对应于链下TEE的开发者的公钥所生成的哈希值为MRSigner,即第一待检验哈希值可以包括MREnclave和MRSigner。
仍以Intel SGX技术为例。如前所述,链下隐私计算节点向IAS服务器发送经过签名的结构体QUOTE后,由IAS服务器根据所维护的公钥集合进行签名验证,并向链下隐私计算节点返回远程证明报告(即AVR报告),该远程证明报告中包含:结构体QUOTE和签名验证结果,并且IAS服务器采用自身持有的私钥对该远程证明报告进行签名。
相应地,数据使用方在获取远程证明报告后,可以首先根据IAS服务器的公钥对该远程证明报告进行签名验证,如果验证通过则表明该远程证明报告确实由IAS服务器 生成,且在数据传输过程中未被篡改或丢失数据。数据使用方可以通过任意途径获得IAS服务器的公钥,譬如远程证明报告被提供至数据使用方时,还可以关联提供IAS的证书链,使得数据使用方可以从该证书链中提取IAS服务器的公钥。然后,数据使用方可以从远程证明报告中提取结构体QUOTE和签名验证结果。数据使用方可以首先查看签名验证结果,如果签名验证结果为通过验证,表明链下隐私计算节点的CPU持有由Intel提供的私钥,因而链下TEE建立在可靠的硬件平台上,可以继续执行其他验证操作;如果签名验证结果为未通过验证,数据使用方可以判定链下隐私计算平台不可靠,无需继续其他验证操作。然后,数据使用方可以从结构体QUOTE内提取上述的哈希值MREnclave和MRSigner,即待检验MREnclave和待检验MRSigner;同时,数据使用方预先获得了链下TEE的上述预设信息的第一标准哈希值,比如为MREnclave和MRSigner的可信值(以下称之为可信MREnclave和可信MRSigner),并将待检验MREnclave与可信MREnclave进行比较、将待检验MRSigner与可信MRSigner进行比较。那么,数据使用方可以将“待检验MREnclave与可信MREnclave一致,且待检验MRSigner与可信MRSigner一致”作为确认链下TEE可信的前提条件;换言之,如果待检验MREnclave与可信MREnclave不一致,或者待检验MRSigner与可信MRSigner不一致,数据使用方就判定该链下隐私计算节点的链下TEE不可信,而如果数据使用方设定的所有前提条件都被满足,就可以确认该链下隐私计算节点的链下TEE可信。此外,数据使用方对于签名验证结果进行验证的操作,与针对待检验MREnclave和待检验MRSigner进行验证的操作之间,并不存在必然的先后顺序,两者之间可以完全独立。
除了MREnclave和MRSigner之外,数据使用方还可以通过其他的前提条件对链下隐私计算节点的可信度进行验证。例如,链下隐私计算节点在创建链下TEE后,可以在链下TEE内生成代表自身的身份信息的密钥对,并且链下隐私计算节点在链下TEE中创建自身的节点身份信息,该节点身份信息与上述对应于身份信息的密钥对相关,比如该节点身份信息可以包含该密钥对中的公钥(即节点身份公钥)。其中,代表身份信息的密钥对可以存在一组或多组,比如一组密钥对为用于签名与签名验证的密钥对(即签名密钥对),一组密钥对为用于加密与解密的密钥对(即加密密钥对),则节点身份信息可以包括签名密钥对中的签名公钥和加密密钥对中的加密公钥。在一组密钥对中,对应于不同的加密算法,可能同时存在多个公钥,这些公钥均被包含于上述的节点身份信息中。此外,节点身份信息还可以包含其他与链下隐私计算节点相关的信息(即其他身份信息),比如软件版本、所在域名、所在分区名等,本说明书并不对此进行限制。那么,链下隐私计算节点在自身的链下TEE内生成节点身份信息(比如在链下TEE初始化时生成)后,可对生成的节点身份信息进行哈希计算得到第二标准哈希值。而链下隐私计算节点在生成结构体QUOTE时,可以将该第二标准哈希值添加至结构体QUOTE中。
相应的,数据使用方在收到远程证明报告后,可以从该远程证明报告进行签名验证。在签名验证通过的情况下,数据使用方可以提取远程证明报告所含的签名验证结果和第二标准哈希值,并验证签名验证结果,以及利用第二标准哈希值验证链下隐私计算节点的节点身份信息是否正确,且两验证步骤之间并不存在必然的先后顺序,两者之间可以完全独立。假定数据使用方首先验证签名验证结果,并在签名验证结果为通过验证的情况下,继续利用第二标准哈希值对链下隐私计算节点的节点身份信息进行验证。为了对链下隐私计算节点的节点身份信息进行验证,数据使用方需要获取链下隐私计算节点的节点身份信息,比如远程证明报告被提供至数据使用方的同时,可以关联提供节点身份信息,当然数据使用方也可以通过其他方式或在其他时刻获得该节点身份信息。然后,数据使用方可以对获得的节点身份信息进行哈希计算得到第二待校验哈希值,将计算得到的第二待校验哈希值与上述的第二标准哈希值进行比较,并将比较结果一致作为确认链下隐私计算节点可信的前提条件。如果第二待检验哈希值通过验证,可以证明获 得的节点身份信息正是链下隐私计算节点在自身的链下TEE内生成的节点身份信息。那么,上述代表身份信息的密钥对中的私钥仅由链下隐私计算节点所拥有,且该链下隐私计算节点能够完成签名、加密通讯等操作。
以上列举了两种针对链下隐私计算节点进行验证时采用的判断条件,即针对第一待检验哈希值的验证、针对节点身份信息的验证。还可以采用其他的判断条件,此处不再一一列举。在针对链下隐私计算节点进行可信验证时,可以选用上述的一个或多个判断条件。例如,可以同时针对第一待检验哈希值和节点身份信息进行验证;或者,在一些情况下,可以仅验证节点身份信息,而对第一待检验哈希值可以不验证或者部分验证。例如,数据使用方上可以设置信任等级,并根据信任等级确定是否验证或部分验证第一待检验哈希值,比如信任等级为0时,不需要验证第一待检验哈希值,信任等级为1时,验证第一待检验哈希值中的MRSigner,信任等级为2时,验证第一待检验哈希值中的MREnclave等。
在上述实施例中,节点身份信息包含了链下隐私计算节点的身份相关的信息,比如代表节点身份的节点身份公钥等。节点身份信息还可以包含与链下TEE相关的信息,那么链下隐私计算节点在自身的链下TEE内生成节点身份信息后,对生成的节点身份信息进行哈希计算得到哈希值,并将该哈希值添加至结构体QUOTE时,该哈希值相当于同时实现了上述第一待检验哈希值和第二标准哈希值的作用。例如,节点身份信息除了包含签名公钥和加密公钥等信息之外,还可以包含MREnclave和MRSigner的值,使得对该节点身份信息进行哈希计算得到的哈希值,同时与链下隐私计算节点的身份、链下TEE相关。相应的,数据使用方在收到远程证明报告后,可以从该远程证明报告进行签名验证。在签名验证通过的情况下,数据使用方可以提取远程证明报告所含的签名验证结果和该哈希值,并验证签名验证结果,以及利用该哈希值验证链下隐私计算节点的节点身份信息是否正确,且两验证步骤之间并不存在必然的先后顺序,两者之间可以完全独立。假定数据使用方首先验证签名验证结果,并在签名验证结果为通过验证的情况下,继续利用该哈希值对链下隐私计算节点的节点身份信息进行验证。为了对链下隐私计算节点的节点身份信息进行验证,数据使用方需要获取链下隐私计算节点的节点身份信息,此处不再赘述。然后,数据使用方可以对获得的节点身份信息进行哈希计算得到待校验哈希值,将计算得到的待校验哈希值与上述远程证明报告所含的哈希值进行比较,并将比较结果一致作为确认链下隐私计算节点可信的前提条件。可见,本实施例仅需一次比较,即可实现前文中两方面的验证,有助于提升验证效率。
需要说明的是,数据使用方对远程证明报告的验证过程,还可以包括其他操作,比如根据远程证明报告的内容确定链下TEE是否运行于测试模式(测试模式下存在数据泄露的风险)等,此处不再一一赘述。
步骤106,所述数据使用方采用所述链下隐私计算节点的身份公钥对所述待验证合约信息进行验签,以及根据所述链下合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在通过所述预言机机制对所述链下合约发起调用时,所述链下合约由所述链下隐私计算节点在所述链下可信执行环境中执行。
在本实施例中,针对集群的形式,在完成对链下隐私计算集群的建立后,需要为这些链下隐私计算节点生成统一的身份信息,比如称为集群身份密钥。集群身份密钥可以包括集群加密密钥对和集群签名密钥对,各个链下隐私计算节点均需在各自的链下TEE内维护集群加密私钥、集群签名私钥。通过为链下隐私计算集群中的各个节点生成统一的身份信息,与链下隐私计算集群对接的外部对象并不需要关注对方为单个链下隐私计算节点或者链下隐私计算集群,只需要将其作为一个对象并与该对象进行交互即可,无需关注于背后的节点或集群的细节。以链下隐私计算节点的第一身份信息为例,针对单节点形式,链下隐私计算节点提供的第一身份信息为该链下隐私计算节点的节点身份 信息(不包含节点身份私钥),身份公钥为该链下隐私计算节点的节点身份公钥,其他身份信息(身份信息中除身份公钥以外的其他身份信息)为链下隐私计算节点的其他节点身份信息,即节点身份信息中除节点身份公钥以外的其他节点身份信息。针对链下隐私计算集群的形式,链下隐私计算节点提供的第一身份信息为链下隐私计算集群的集群身份信息,身份公钥为链下隐私计算集群的集群身份公钥,其他身份信息(身份信息中除身份公钥以外的其他身份信息)为上述其他节点身份信息。而针对链下隐私计算节点的第二身份信息,在第一身份信息的基础上,还包含链下可信执行环境的预设信息的哈希值,包含的其他内容相同,在此不再赘述。下面结合图2-3分别对单节点形式和集群形式的挑战过程进行详细说明。
如图2所示,针对单节点的形式,数据使用方的客户端21可向链下隐私计算节点22发起链下挑战或者链上挑战。链上挑战的发起过程可以包括三个步骤:步骤①,客户端21向区块链网络23提交一笔用于向链下合约发起挑战的交易,比如称之为挑战交易,该挑战交易可由区块链网络23内的某一节点23n接收和执行;步骤②,节点23n调用预先部署的预言机合约,该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器24,比如预言机合约可以产生包含该挑战信息的事件,而预言机服务器24可以通过监听预言机合约产生的事件,从而获取上述的挑战信息;步骤③,预言机服务器24将挑战信息通过链下渠道发送至控制节点22。
通过对链下隐私计算节点22部署的链下合约发起挑战,客户端21可获取针对链下隐私计算节点22创建的链下TEE的远程证明报告,该远程证明报告由认证服务器对链下隐私计算节点22针对链下TEE产生的自荐信息进行验证后生成。在一种情况下,由客户端21向链下隐私计算节点22发起挑战,挑战目标为链下隐私计算节点22部署的链下合约,进而接收链下隐私计算节点22响应于该挑战返回的所述远程证明报告和所述待验证合约信息,即链下隐私计算节点22响应于该挑战,将所述远程证明报告和所述待验证合约信息一次性返回至客户端21。在另一种情况下,由客户端21向链下隐私计算节点22发起挑战,挑战目标为链下隐私计算节点22创建的链下TEE,进而接收链下隐私计算节点22返回的远程证明报告,并在根据所述远程证明报告确定所述链下TEE可信的情况下,向链下隐私计算节点22发送针对部署于链下隐私计算节点22处的链下合约的合约信息的获取请求,接收链下隐私计算节点22响应于所述获取请求返回的待验证合约信息。而在根据所述远程证明报告确定所述链下TEE不可信的情况下,则无需再向链下隐私计算节点22请求获取链下合约的合约信息(即待验证合约信息)。
其中,客户端21可通过链上挑战向挑战目标发起挑战。比如,向区块链节点23n提交针对挑战目标的挑战交易,该挑战交易包含的挑战信息由区块链节点23n通过预言机机制传输至链下隐私计算节点22,所述挑战信息用于向挑战目标发起挑战。或者,客户端21直接向链下隐私计算节点22中的挑战目标发起链下挑战。
如图2所示,在一实施例中,链下隐私计算节点22在链下TEE内生成自身的节点身份信息后,可对生成的节点身份信息进行哈希计算得到第二标准哈希值;其中,所生成的节点身份信息中包含链下隐私计算节点22的节点身份公钥和链下隐私计算节点22的其他身份信息。那么,客户端21可利用第二标准哈希值验证链下隐私计算节点22提供的第一节点身份信息(即声明的节点身份信息,包含链下隐私计算节点22的节点身份公钥和链下隐私计算节点22的其他身份信息,不一定为真实数据,此时可理解为待验证身份信息),并在验证通过的情况下获取可验证链下隐私计算节点22的节点身份信息中包含的节点身份公钥,从而利用该节点身份公钥完成后续对链下合约的验证。比如,客户端21对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值,并将第二待校验哈希值与链下隐私计算节点22提供的第二标准哈希值进行比较,从而在比较结果一致的情况下判定节点身份信息验证通过。由于节点身份信息由链下隐私计算节点22在链下TEE内生成并计算得到第二标准哈希值,那么在根据远程证明报告判 定链下TEE可信后,若第二待校验哈希值与第二标准哈希值相同,则说明隐私计算节点22提供的第一节点身份信息为在链下TEE内生成的节点身份信息,从而其中包含的节点身份公钥为隐私计算节点22实际的节点身份公钥,而链下隐私计算节点22实际的节点身份公钥可用于验证隐私计算节点22的签名。其中,链下隐私计算节点22可将第二标准哈希值、远程证明报告、第一节点身份信息一同发送至客户端21。需要说明的是,此部分内容可参考前述步骤104中针对链下隐私计算节点进行验证的过程,在此不再赘述。
如图2所示,在另一实施例中,链下隐私计算节点22在链下TEE内生成自身的节点身份信息包含链下隐私计算节点22的节点身份公钥、链下隐私计算节点22的其他身份信息和链下TEE的预设信息的哈希值,那么链下隐私计算节点22在自身的链下TEE内生成节点身份信息后,对生成的节点身份信息进行哈希计算得到第三标准哈希值,那么第三标准哈希值相当于同时实现了上述第一待检验哈希值和第二标准哈希值的作用。具体而言,链下隐私计算节点22可向客户端21提供远程证明报告、第三标准哈希值和第二节点身份信息(此时可理解为待验证身份信息)。其中,第二节点身份信息包含链下隐私计算节点22的节点身份公钥、链下隐私计算节点22的其他身份信息和第四待校验哈希值,第四待校验哈希值为链下TEE的预设信息的哈希值;同时,第二节点身份信息为声明的节点身份信息,并不一定为链下隐私计算节点22的真实节点身份信息。那么,客户端21在根据认证服务器的公钥对远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,对获取到的第二节点身份信息进行哈希计算以得到第三待校验哈希值,并将第三待校验哈希值与第三标准哈希值进行比较。当比较结果为一致时,说明隐私计算节点22提供的第二节点身份信息为在链下TEE内生成的节点身份信息,也即其中包含的第四待校验哈希值为链下TEE的实际预设信息的哈希值。因此,进一步将预先获得的针对所述链下TEE预设信息的第四标准哈希值与第四待检验哈希值进行比较,并将比较结果一致作为确认所述链下TEE可信的前提条件。同时,第二节点身份信息包含的节点身份公钥可判定为隐私计算节点22实际的节点身份公钥,可用于对待验证合约信息进行签名验证。其中,链下隐私计算节点22可将第三标准哈希值、远程证明报告、第二节点身份信息一同发送至客户端21。需要说明的是,此部分内容可参考前述步骤104中针对链下隐私计算节点进行验证的过程,在此不再赘述。
客户端21在根据远程证明报告确定链下TEE可信的情况下,获取部署于链下隐私计算节点22处的链下合约的待验证合约信息,待验证合约信息被链下隐私计算节点22在链下TEE内采用自身的节点身份私钥进行签名,节点身份私钥由链下隐私计算节点22在链下TEE内生成。比如,链下隐私计算节点22可将部署的链下合约读入链下TEE内并采用自身的节点身份私钥进行签名。
客户端21采用链下隐私计算节点22的节点身份公钥对待验证合约信息进行签名验证,以及根据链下合约的合约信息对待验证合约信息进行合约信息验证。其中,节点身份公钥处于公开状态,比如链下隐私计算节点22向外公开发布节点身份公钥以由客户端21获取。或者,客户端21通过上述验证链下隐私计算节点22的节点身份信息的方式获取。同时,链下合约的合约信息也可处于公开状态,比如链下合约的部署方向外公开发布合约信息以由客户端21获取。其中,合约信息可以包括链下合约的名称、描述、版本号、字节码哈希值、合约身份公钥等信息,本说明书并不对此进行限制。
在签名验证和合约信息验证通过的情况下,客户端21可确定客户端21在通过区块链节点的预言机机制对链下合约发起调用时,该链下合约由链下隐私计算节点22在链下TEE可信执行环境中执行。本说明书中验证链下合约的过程为先验证链下隐私计算节点22的链下TEE可信,那么在验证链下隐私计算节点22的链下TEE可信的情况下,若验证签名得到链下隐私计算节点22提供的待验证合约信息确实由链下隐私计算 节点22的节点身份私钥(维护在链下TEE内)签名,则可确定出当前挑战的链下合约为运行在链下隐私计算节点22的链下TEE内的链下合约,即确保链下隐私计算节点22中部署的链下合约可信,可按照用户预期执行计算任务。
下面结合图3针对集群形式的挑战过程进行说明。如图3所示,客户端31可向控制节点32发起链下挑战或者链上挑战。链上挑战的发起过程可以包括三个步骤:步骤①,客户端31向区块链网络33提交一笔用于向链下合约发起挑战的交易,比如称之为挑战交易,该挑战交易可由区块链网络33内的某一节点33n接收和执行;步骤②,节点33n调用预先部署的预言机合约,该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器34,比如预言机合约可以产生包含该挑战信息的事件,而预言机服务器34可以通过监听预言机合约产生的事件,从而获取上述的挑战信息;步骤③,预言机服务器34将挑战信息通过链下渠道发送至控制节点32。
链下隐私计算集群作为一个整体向外提供执行计算任务的功能。其中,集群内各个节点均部署有相同的链下合约,那么各个节点均可以代表集群来执行计算任务,比如,计算任务可由控制节点来分配。因此,各个节点在代表集群与外部进行数据交互时,使用代表集群身份的集群身份密钥来对与外部交互的数据进行解密或签名,而非使用节点自身的节点身份密钥。相应的,外部对象在通过客户端与集群进行交互时,将集群视为一个整体而无需关心集群内部的结构,因此采用集群身份密钥进行加密或验证签名。
如图3所示,用户在通过客户端31调用集群中的链下合约之前,可通过客户端31对集群中部署的链下合约发起挑战。控制节点32在接收到挑战后,可选取集群中的任意节点来响应该挑战。比如,可选取上述用于生成集群身份密钥的主节点,或者选取集群中的从节点,本说明书并不对选取响应挑战的节点的方式进行限制。以节点32n响应挑战为例进行说明。控制节点32选取节点32n来代表集群响应挑战,向挑战方提供代表集群的集群远程证明报告。其中,集群远程证明报告由认证服务器对节点32n针对自身的链下TEE产生的自荐信息进行验证后生成,即集群远程证明报告为对应于节点32n的链下TEE的远程证明报告。具体而言,集群远程证明报告携带的自荐信息内包含第一待检验哈希值,该第一待检验哈希值为节点32n的链下TEE的预设信息的哈希值,该第一待检验哈希值用于挑战方在根据认证服务器的公钥对集群远程证明报告进行签名验证并签名验证通过,且集群远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对链下TEE的第一标准哈希值(比如,为链下TEE的上述预设信息的可信哈希值)进行比较,且比较结果一致被作为挑战方确认链下TEE可信的前提条件。其中,挑战方根据集群远程证明报告验证链下TEE的过程可参考前述控制节点验证待加入节点的链下TEE的内容,在此不再赘述。实际上,挑战方根据集群远程证明报告验证的链下TEE为节点32n的链下TEE。
如图3所示,在一实施例中,节点32n在链下TEE内生成自身的节点身份信息时,还可在链下TEE内生成代表集群的集群身份信息,并对生成的集群身份信息进行哈希计算得到第二标准哈希值;其中,所生成的集群身份信息中包含集群身份公钥和节点32n的节点身份信息中除节点身份公钥以外的其他身份信息。换言之,基于通过节点32n来代表集群,节点32n的节点身份信息与集群身份信息之间的差异在于:节点身份信息中记录的公钥为节点身份公钥,集群身份信息中记录的公钥为集群身份公钥;持此之外,其他身份信息相同。那么,客户端31可利用第二标准哈希值验证节点32n提供的第一集群身份信息(即声明的集群身份信息,包含集群身份公钥和节点32n的其他身份信息,不一定为真实数据,此时可理解为待验证身份信息),并在验证通过的情况下获取集群身份信息中包含的集群身份公钥,从而利用该集群身份公钥完成后续对链下合约的验证。比如,客户端对获取到的第一集群身份信息进行哈希计算以得到第二待校验哈希值,并将第二待校验哈希值与节点32n提供的第二标准哈希值进行比较,从而在比较结果一致的情况下判定集群身份验证通过。由于集群身份信息由节点32n在链下TEE内生成并 计算得到第二标准哈希值,那么在根据远程证明报告判定链下TEE可信后,若第二待校验哈希值与第二标准哈希值相同,则说明隐私计算节点32提供的第一集群身份信息为在链下TEE内生成的集群身份信息,从而其中包含的集群身份公钥为隐私计算节点32实际维护的对应于集群的集群身份公钥,而隐私计算节点32实际维护的集群身份公钥可用于验证隐私计算节点32的签名。其中,节点32n可通过控制节点32将第二标准哈希值、远程证明报告、第一集群身份信息一同发送至客户端31。需要说明的是,此部分内容可参考前述步骤104中针对链下隐私计算节点进行验证的过程,在此不再赘述
如图3所示,在另一实施例中,节点32n在链下TEE内生成的集群身份信息可包含集群身份公钥、节点32n的节点身份信息中除节点身份公钥以外的其他身份信息和链下TEE的预设信息的哈希值,那么节点32n在自身的链下TEE内生成集群身份信息后,对生成的集群身份信息进行哈希计算得到第三标准哈希值,那么第三标准哈希值相当于同时实现了上述第一待检验哈希值和第二标准哈希值的作用。具体而言,节点32n可向客户端31提供远程证明报告、第三标准哈希值和第二集群身份信息(此时可理解为待验证身份信息)。其中,第二集群身份信息包含集群身份公钥、节点32n的其他身份信息和第四待校验哈希值,第四待校验哈希值为链下TEE的预设信息的哈希值;同时,第二集群身份信息为声明的集群身份信息,并不一定为节点32n提供的真实集群身份信息。那么,客户端31在根据认证服务器的公钥对远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,对获取到的第二集群身份信息进行哈希计算以得到第三待校验哈希值,并将第三待校验哈希值与第三标准哈希值进行比较。当比较结果为一致时,说明隐私计算节点32提供的第二集群身份信息为在链下TEE内生成的集群身份信息,也即其中包含的第四待校验哈希值为链下TEE的实际预设信息的哈希值。因此,进一步将预先获得的针对所述链下TEE预设信息的第四标准哈希值与第四待检验哈希值进行比较,并将比较结果一致作为确认所述链下TEE可信的前提条件。同时,第二集群身份信息包含的集群身份公钥可判定为隐私计算节点32实际维护的集群身份公钥,可用于对待验证合约信息进行签名验证。其中,节点32n可通过控制节点32将第三标准哈希值、远程证明报告、第二集群身份信息一同发送至客户端31。需要说明的是,此部分内容可参考前述步骤104中针对链下隐私计算节点进行验证的过程,在此不再赘述。
与上述图2所示的实施例类似,集群远程证明报告和待验证合约信息由节点32n发送至控制节点32,再由控制节点32转发至客户端31。控制节点32可一并向客户端31提供集群远程证明报告和待验证合约信息,也可先提供集群远程证明报告,并在客户端31根据集群远程证明报告验证通过后再向节点32n获取待验证合约信息以向客户端31提供待验证合约信息。其中,待验证合约信息为部署在节点32n处的链下合约的合约信息,并由节点32n在节点32n的链下TEE内采用集群身份私钥(维护在节点32n的链下TEE内)进行签名。比如,节点32n将部署在节点32n处的链下合约读入链下TEE内,并采用集群身份私钥进行签名。
客户端31在根据集群远程证明报告确定链下TEE可信(即节点32n的链下TEE,由节点32n代表集群,用户感知不到集群内的其他节点)的情况下,采用集群身份公钥对待验证合约信息进行签名验证,以及根据链下合约的合约信息对待验证合约信息进行合约信息验证。其中,集群身份公钥处于公开状态,比如控制节点31向外公开发布集群身份公钥以由客户端31获取。或者,客户端31通过上述验证集群身份信息的方式获取。同时,链下合约的合约信息也可处于公开状态,比如链下合约的部署方向外公开发布合约信息以由客户端31获取。其中,合约信息可以包括链下合约的名称、描述、版本号、字节码哈希值、合约身份公钥等信息,本说明书并不对此进行限制。
与上述单节点形式中验证链下合约的原理类似,在签名验证和合约信息验证通过的情况下,客户端31可确定客户端31在通过区块链节点的预言机机制对链下合约发起 调用时,该链下合约由节点32n在链下TEE可信执行环境中执行,即确保节点32n中部署的链下合约可信,可按照用户预期执行计算任务。
需要说明的是,在链下隐私计算集群的形式中,各类远程证明报告可以具有一定的时限性,比如30分钟或其他时长,超时的远程证明报告被判定为失效。比如,共享集群身份密钥过程中涉及的远程证明报告均由节点实时向认证服务器控制节点获取,而集群远程证明报告可由控制节点在本地缓存并设定老化时长。
在本说明书的链下合约调用方案中,区块链节点可以将计算任务分配至链下隐私计算节点,并调用链下隐私计算节点上部署的链下合约,通过在链下隐私计算节点创建的链下TEE内执行该链下合约,以完成上述的计算任务。通过远程证明、加密传输、基于签名的身份验证等技术,可以确保链下隐私计算节点得到的计算结果可靠,并且在计算过程中不会造成数据泄露,具有极高的安全性。在计算完成后,区块链节点可以根据计算结果对区块链账本数据进行更新,可以对计算结果进行固化存证,而且可以支持针对该计算结果的后期验证。同时,相比于区块链节点在执行链上合约后所产生的上链数据而言,基于链下合约产生的计算结果本身相对更加简短,因而将该计算结果上链时,有助于节省链上存储空间。
区块链节点根据计算结果更新区块链账本数据,或者称为对计算结果进行上链,其方式可以包括:生成一笔区块链交易,将计算结果添加至交易的data字段,当该区块链交易通过共识后,可被各个区块链节点添加至最新区块的区块体中,从而实现了区块链账本数据的更新,亦即完成了对该计算结果的上链;或者,区块链节点根据计算结果对相关账户的状态进行更新,该相关账户譬如可以为用户对应的外部账户或者链上合约对应的合约账户,该相关账户的状态更新会导致状态树(state tree)的树根发生取值变化,而该状态树的树根会被包含于最新区块的区块头,从而实现了区块链账本数据的更新,亦即相当于将该计算结果上链。
进一步的,目标数据作为链下合约的入参数据的同时,也属于目标数据的数据拥有方的隐私数据。因此,出于隐私保护,对于需要调用链下合约对目标数据进行处理的用户(以下称为数据使用方),数据拥有方可对这些用户针对目标数据的使用权进行权限控制。同时,明文形式的目标数据仅由数据拥有方持有,数据拥有方可对明文形式的目标数据进行加密(以下称为目标明文数据)得到密文形式的目标数据(以下称为目标密文数据),并且仅在链下隐私计算节点的链下TEE内可对目标密文数据进行解密。那么,数据拥有方可对已授予使用权的用户提供目标密文数据,以供该用户后续调用链下隐私计算节点在链下TEE内对目标密文数据进行解密并执行链下合约对解密得到的目标明文数据进行处理。下面结合图4-7对基于数据权限控制的链下合约调用方法进行说明。
图4是一示例性实施例提供的一种数据使用方侧的调用合约的方法的流程图。如图4所示,该方法可以包括步骤402~步骤404。
步骤402,数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明。
在本实施例中,数据使用方在调用执行链下合约对目标明文数据进行处理(即理解为使用目标明文数据)的前提条件包括:目标明文数据的数据拥有方向该数据使用方授予了针对目标明文数据的使用权。比如,数据拥有方可对自身持有的目标明文数据进行加密得到目标密文数据,并声明该目标密文数据需要经该数据拥有方的授权才可使用。那么,数据使用方在调用链下合约之前,需向数据拥有方发起针对目标明文数据的授权请求,由数据拥有方对该数据使用方进行审核,并在审核通过后向该数据使用方颁发针对目标明文数据的使用权的VC(Verifiable Claim,可验证声明),以及提供目标密文数据。数据使用方在获得可验证声明后,便可在后续调用链下合约对目标明文数据进行 处理时,向链下隐私计算节点出示该可验证声明,由链下隐私计算节点根据该可验证声明校验数据使用方针对目标明文数据的使用权,并在校验通过的情况下执行链下合约以完成对目标明文数据的处理。
在本实施例中,类似的,针对单节点形式和集群形式,数据使用方向链下隐私计算节点提交调用请求的方式也不同。在链下隐私计算节点为单节点形式的情况下,数据使用方向区块链节点提交调用请求,由该区块链节点通过预言机机制向链下隐私计算节点转发调用请求。在链下隐私计算节点属于链下隐私计算集群的情况下,数据使用方向区块链节点提交调用请求,由该区块链节点通过预言机机制向链下隐私计算集群的控制节点转发调用请求,再由控制节点将调用请求转发至集群中的链下隐私计算节点。下面结合图5对集群形式的情况进行详细说明,单节点形式的情况与此类似。
如图5所示,假定数据使用方的客户端51希望对已部署的链下合约进行调用(比如在验证链下合约通过之后)。客户端51可以通过链下渠道向控制节点52发送调用请求,该调用请求采用集群身份公钥进行加密,控制节点52可以基于负载均衡算法将该调用请求分配至集群内的某个链下隐私计算节点,比如节点52n,由该节点52n对调用请求进行响应。节点52n在自身创建的链下TEE中通过集群身份私钥解密调用请求,从而获得调用请求中包含的入参数据。然后,节点52n可以在链下TEE中执行链下合约的字节码,以针对入参数据进行处理,从而得到相应的调用结果。进一步的,节点52n可以在链下TEE中对该调用结果进行加密后,经由控制节点52反馈至客户端51。
客户端51可以通过链上渠道向控制节点52发送调用请求。客户端51可以向区块链网络53提交链下合约调用交易,该链下合约调用交易中包含调用请求,该调用请求由客户端51采用集群身份公钥进行加密。当然,链下合约调用交易本身也可以是加密传输的,比如采用集群身份公钥对调用交易进行加密,或者其他加密方式,这可以参考前文所述的数据加密传输的内容,此处不再赘述。链下合约调用交易可以调用预言机合约,使得预言机合约针对该交易所含的调用请求产生相应的合约事件,该合约事件被预言机服务器54监听到之后,由预言机服务器54获取调用请求并传输至控制节点52。然后,控制节点52将调用请求分配至诸如链下隐私计算节点52n进行响应。以及,控制节点52可以通过预言机机制将调用结果反馈至链上,而节点53n可以主动发起一笔交易,将该调用结果上链,或者节点53n可以将调用结果反馈至客户端51,由客户端51重新发起一笔交易将该调用结果上链。
如果入参数据为区块链数据,即数据拥有方向数据使用方提供的目标密文数据存证在区块链上,可由数据使用方从区块链上获取。客户端51可以向区块链网络53提交加密后的链下合约调用交易,该链下合约调用交易中包含入参数据的信息,并且该链下合约调用交易调用了用于获取入参数据的链上合约。节点53n收到加密后的链下合约调用交易后,在链上TEE中进行解密,然后通过链上TEE内部署的虚拟机执行被调用的链上合约,以获取被作为入参数据的区块链数据,节点53n可以在链上TEE内解密为明文,然后将该明文的区块链数据打包至调用请求中,并在链上TEE内采用集群身份公钥对该调用请求进行加密,而后基于预言机机制传输至控制节点52,由控制节点52将调用请求分配至诸如链下隐私计算节点52n进行响应。以及,控制节点52可以通过预言机机制将调用结果反馈至链上,而节点53n可以将该调用结果上链。
在图5所示实施例中,以链下隐私计算集群为例进行描述。实际上,客户端51也可以直接与单个链下隐私计算节点进行交互,以调用该链下隐私计算节点上部署的链下合约,此处不再赘述。
步骤404,所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出 所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
在本实施例中,调用请求中记录有数据拥有方的身份、数据使用方的身份和可验证声明,这些信息均由数据使用方写入该调用请求中。换言之,调用请求中包含的上述信息均由数据使用方提供,用于声明可验证声明为目标明文数据的数据拥有方向该数据使用方颁发的可验证声明,而调用请求中的上述信息存在伪造的可能。具体而言,伪造的情况包含以下至少之一:调用请求中记录的数据拥有方的身份并非实际的数据拥有方的身份、调用请求中记录的数据使用方的身份并非实际的数据使用方的身份、调用请求中包含的可验证声明并非由实际的数据拥有方颁发、调用请求中包含的可验证声明并非颁发给实际的数据使用方。因此,链下隐私计算节点在接收到调用请求后,应先执行针对上述情况的校验操作以发现伪造的问题,从而提高数据的安全性。作为一示例性实施例,在以下校验操作均通过的情况下,链下隐私计算节点可校验出调用请求中的可验证声明为目标明文数据的数据拥有方(实际的数据拥有方)向数据使用方(即提交调用请求的实际数据使用方)颁发的可验证声明,也即确定出数据拥有方向数据使用方授予了针对目标明文数据的使用权:针对调用请求中记录的数据拥有方的身份的第一真实性校验操作、针对调用请求中记录的数据使用方的身份的第二真实性校验操作、针对可验证声明的实际颁发方为数据拥有方的第三真实性校验操作,以及针对可验证声明的实际颁发对象为数据使用方的第四真实性校验操作。其中,对于颁发方和颁发对象的理解为:由颁发方向颁发对象颁发可验证声明。需要说明的是,上述第一真实性校验操作~第四真实性校验操作之间并不存在执行顺序上的限制。
可通过DIS(Decentralized Identifier Service,去中心化的身份服务)来为各个用户创建身份。DIS可为用户提供不受任何单一注册中心、身份服务商或者认证中心限制的,完全由用户自身控制的DID(Decentralized Identifier,去中心化身份标识符)。
基于通过DID来表示数据使用方和数据拥有方的身份标识,数据拥有方除了向数据使用者颁发可验证声明和提供目标密文数据以外,还提供采用与该数据拥有方的DID对应的私钥对目标明文数据进行签名得到的第一签名信息,从而可用于证明该数据拥有方的身份。比如,可直接对目标明文数据本身进行签名得到第一签名信息,或者先对目标明文数据进行哈希计算得到哈希值,再对该哈希值进行签名得到第一签名信息。同时,数据使用方生成调用请求时,为了证明该数据使用方的身份,采用与该数据使用方的DID对应的私钥对调用请求进行签名以得到相应的第二签名信息,并将该第二签名信息添加到调用请求中。综上,调用请求中至少包含目标密文数据、可验证声明、数据使用方的DID、对应于目标明文数据的第一签名信息、数据拥有方的DID和对应于调用请求的第二签名信息。
基于上述生成调用请求的过程,链下隐私计算节点可通过第一用户公钥对调用请求中对应于目标明文数据的第一签名信息进行签名验证;其中,第一用户公钥与调用请求中记录的数据拥有方(不一定为实际的数据拥有方)的第一DID相对应。由于只有实际的数据拥有方才持有目标明文数据(向其他用户提供的是对目标明文数据加密得到的目标密文数据),那么在签名验证通过的情况(说明第一签名信息由实际的数据拥有方采用自身的私钥对目标明文数据进行签名得到)下,说明调用请求中记录的数据拥有方的第一DID,为实际的数据拥有方的DID,那么可判定第一真实性校验操作通过。
类似的,链下隐私计算节点在通过第二用户公钥对调用请求中对应于该调用请求的第二签名信息进行签名验证且签名验证通过的情况下,可判定第二真实性校验操作通过;其中,第二用户公钥与调用请求中记录的数据使用方的第二DID相对应。
在此基础上,在可验证声明的实际颁发方的DID与上述第一DID相匹配的情况下,说明调用请求中的可验证声明由实际的数据拥有方颁发,因此可判定第三真实性校验操作通过。以及,在可验证声明的实际颁发对象的DID与上述第二DID相匹配的情况下,说明调用请求中的可验证声明由实际的数据使用方接收(即是颁发给实际的数据使用方 的),因此可判定第四真实性校验操作通过。
在本实施例中,可验证声明的颁发方在颁发该可验证声明时,会在该可验证声明中记录自身的DID以及颁发对象的DID;同时,采用与自身DID对应的私钥对该可验证声明进行签名,并将签名记录在该可验证声明中,以用于证明自身的身份。因此,可通过以下方式确定出可验证声明的实际颁发方的DID和可验证声明的实际颁发对象的DID:读取调用请求中可验证声明记录的颁发方的DID,并获取与读取到的DID对应的第三用户公钥,采用第三用户公钥对调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将调用请求中可验证声明记录的颁发方的DID作为实际颁发方的DID;以及,将调用请求中可验证声明记录的颁发对象的DID作为实际颁发对象的DID。
在本实施例中,可验证声明中包含数据拥有方定义的针对目标明文数据的调用规则,也即规定可验证声明的颁发对象如何使用目标明文数据。调用规则可针对目标明文数据的使用权进行细化控制;比如,链下合约中允许处理目标明文数据的合约函数、目标明文数据的使用权的有效期、允许调用所述链下合约对所述目标明文数据进行处理的次数和允许调用所述链下合约对所述目标明文数据进行处理的频率。因此,步骤404中链下隐私计算节点在根据可验证声明确定出目标明文数据的数据拥有方向数据使用方授予了使用权后,还需进一步校验调用请求指示的调用操作是否符合可验证声明定义的调用规则,也即调用条件还包括调用请求指示的调用操作符合可验证声明定义的调用规则。
在本实施例中,数据拥有方可采用链下合约的合约身份公钥对目标明文数据进行加密得到目标密文数据,从而确保目标明文数据只能由被调用的链下合约所获得,而不会被其他链下合约获得。链下隐私计算节点的链下TEE内维护有对应于合约身份公钥的合约身份私钥,那么链下隐私计算节点在收到针对链下合约的调用请求后,可在链下TEE内采用该合约身份私钥对调用请求中的目标密文数据进行解密。
类似的,链下隐私计算节点在得到调用结果(即执行链下合约得到的执行结果)后,可在链下TEE内采用被调用的链下合约的合约身份私钥对调用结果进行签名,而数据使用方的客户端在获取链下隐私计算节点通过预言机机制反馈至区块链节点的执行结果后,可采用被调用的链下合约的合约身份公钥对执行结果进行签名验证,以及在签名验证通过的情况下,判定执行结果由被调用的链下合约生成。
需要说明的是,本说明书中加密与解密,生成签名与验证签名,可采用同一组密钥对,或者分别配置一组加密密钥对和一组签名密钥对。其中,在一组密钥对中,对应于不同的加密算法,可能同时存在多个公钥和相应的私钥。下面以节点身份密钥为例进行说明,集群身份密钥和合约身份密钥与此类似。
在一种情况下,节点身份密钥为一组密钥对,包含节点身份公钥和节点身份私钥。其中,节点身份公钥可用于对数据进行加密,那么可采用节点身份私钥对该数据进行解密;节点身份私钥可用于对数据进行签名,那么可采用节点身份公钥对该数据进行签名验证。在另一种情况下,可配置两组密钥对,分别为节点加密密钥对和节点签名密钥对。其中,节点加密密钥对用于对数据进行加密与解密,节点签名密钥对用于对数据进行签名与验证签名。
由以上实施例可见,数据拥有方可对自身拥有的目标明文数据进行加密得到目标密文数据,并向数据使用方提供目标密文数据,以及向数据使用方颁发针对该目标明文数据的使用权的可验证声明,可实现对目标明文数据使用权的权限控制,即控制目标明文数据允许被哪些用户调用链下合约进行处理。通过上述针对目标明文数据的授权机制,目标明文数据的使用权由数据拥有方把控,可有效提高数据拥有方的隐私安全性。进一步的,在进行授权时引入DID来表示各个用户的身份,可以使得用户的身份真正为用户所拥有并支配,用户可对自身的身份进行自主创建,以及完全去中心化的身份管理。
为了便于理解,下面结合图6-8对数据拥有方向数据使用方颁发针对目标明文数据使用权的可验证声明,以及数据使用方通过可验证声明调用链下合约对目标明文数据进行处理的过程进行详细说明。
图6是一示例性实施例提供的创建DID的流程图。如图6所示,该方法可以包括步骤602~步骤608。
步骤602,数据使用方通过使用方客户端创建DID、对应于DID的公钥和私钥,以及相应的DID文档。
在本实施例中,与数据使用方DID对应的公钥需发布至区块链进行存证,而与数据使用方DID对应的私钥则由数据使用方保管,比如保存在使用方客户端中。
在DIS系统中,一个DID(Decentralized Identifier,去中心化身份标识符)对应一个实体(比如,数据使用方、数据拥有方等用户),而针对该DID的具体使用方式,则由与该DID对应的DID文档(DID Document)描述。DID文档用于描述如何使用相应的DID,至少包含相应DID的公钥;除此之外,还可记录加密方式、证明目的、验证方法和服务端点等信息。其中,证明目的与验证方法相结合,以提供证明事物的机制。例如,DID文档可以指定特定的验证方法,例如密码公钥或化名生物特征协议,可以用于验证为目的而创建的方法。服务端点支持与DID控制器的可信交互。DID和DID文档可直接登记在区块链或其他分布式网络上,而无需向中心化注册机构申请,通过利用区块链等分布式网络技术的不可篡改、哈希加密等特性,可实现让数字身份真正为用户所拥有并支配,而不再有任何中间人(即使是DID技术供应商)接触拥有控制用户的身份和数据。
步骤604,使用方客户端创建一笔用于存证DID和DID文档的交易。
步骤606,使用方客户端向区块链节点发起该用于存证DID和DID文档的交易。
步骤608,区块链节点在区块链上存证DID和DID文档。
需要说明的是,存证DID和DID文档的区块链,与上述利用预言机机制调用链下合约的区块链可以是同一区块链,也可以是不同的区块链。
步骤610,使用方客户端向区块链节点获取创建DID成功的回执。
在本实施例中,区块链节点在存证DID和DID文档之后,可生成用于记存证DID和DID文档成功的事件,并存储到区块链日志中。那么,使用方客户端可通过区块链的回调机制来获取该事件,从而确定出在区块链上已存证DID和DID文档,也即数据使用方创建DID成功。同时,还可生成相应的提示消息以供数据使用方查看,以告知数据使用方链上创建DID成功。
图7是一示例性实施例提供的数据授权过程的流程图。如图7所示,该过程可以包括步骤702~步骤722。
步骤702,数据使用方通过使用方客户端创建针对目标明文数据的授权请求(包含使用方DID、使用方信息和签名)。
在本实施例中,在创建授权请求时,在授权请求中记录使用方信息以供数据拥有方审核该数据使用方是否具备目标明文数据使用权的资格,也即由数据拥有方根据使用方信息来决定是否向数据使用方授权目标明文数据使用权。同时,使用方客户端采用与使用方DID对应的私钥对授权请求进行签名,并将得到的签名记录在授权请求中,以用于表明数据使用方的身份。
步骤704,使用方客户端向数据拥有方的拥有方客户端发送授权请求。
步骤706,拥有方客户端读取授权请求中包含的数据使用方DID。
步骤708,拥有方客户端向区块链节点发起针对使用方DID的查询交易。
步骤710,区块链节点查询与使用方DID对应的DID文档。
步骤712,拥有方客户端获取查询到的DID文档。
步骤714,拥有方客户端采用DID文档中的公钥对授权请求中的签名进行签名验 证。
在本实施例中,由上述图6创建DID的过程可知,使用方DID的DID文档中记录有与使用方DID对应的公钥,那么可利用该公钥来验证授权请求中的使用方DID是否为数据使用方实际的DID,也即验证数据使用方是否为授权请求中使用方DID的合法拥有者。
在本实施例中,除上述通过在授权请求中添加签名的方式以外,还可由拥有方客户端向使用方客户端发起针对DID的认证挑战,以完成对使用DID的验证。具体而言,使用方客户端创建的DID授权请求中无需添加签名,而是由拥有方客户端在获取到与使用方DID对应的DID文档中记录的公钥后,向使用方客户端发起DID认证挑战(DID auth challenge)消息,该消息中包含一段随机的字符串,用于要求使用方客户端采用使用方DID的私钥来该字符串进行签名。使用方客户端在收到DID认证挑战消息后,采用使用方DID的私钥对字符串进行签名,并将字符串和签名发送给拥有方客户端。那么,拥有方客户端可采用DID文档中的公钥对签名进行签名验证,进而在签名验证通过的情况下,确认数据使用方为授权请求中记录的使用方DID的合法拥有者。
步骤716,在签名验证通过的情况下拥有方客户端对授权请求中的使用方信息进行审核,以确定出是否向数据使用方授予针对目标明文数据的使用权。
在本实施例中,除上述线上审核的方式以外,还可由数据使用方线下向数据拥有方提供使用方信息以供数据拥有方进行审核。而具体的审核方式,可根据实际情况灵活设定;当然,本说明书并不对此进行限制。
步骤718,在审核通过的情况下,拥有方客户端创建使用方针对目标明文数据的使用权的可验证声明。
在本实施例中,DID是一个实体的标识,而该实体拥有哪些权限、能力、行为和资产等具体信息,则通过可验证声明来表达。需要注意的是,一个DID可以拥有一个或多个可验证声明。举例而言,可验证声明中可包含以下字段:
issuer:声明颁发者(颁发方);
didsubject:声明接收者(颁发对象)的DID;
expire:声明过期时间;
issuance date:声明颁发时间;
claim:声明内容,可以是明文,也可以是密文,哈希等;
proof:有效性证明。
假设数据拥有方预先也采用上述图6的方式创建了自身的DID。那么,数据拥有方可在issuer中记录自身的DID,在didsubject中记录通过审核的数据使用方的DID,在expire中记录目标明文数据的使用权的有效期,在issuance date中记录颁发该可验证声明的时刻,在claim中记录链下合约中允许处理目标明文数据的合约函数、允许调用链下合约对目标明文数据进行处理的次数(也即使用目标明文数据的次数)和允许调用链下合约对目标明文数据进行处理的频率(也即使用目标明文数据的频率)。而为了证明该可验证声明是由数据拥有方颁发的,数据拥有方需要采用自身的私钥对该可验证声明进行签名,并将签名记录在proof中。当然,上述针对可验证声明中包含的字段以及调用规则的描述,仅仅为一举例,在实际应用中可根据实际情况灵活调整。
步骤720,拥有方客户端向使用方客户端返回可验证声明和数据拥有方的签名体。
在本实施例中,数据拥有方的签名体中至少包含第一签名信息,第一签名信息由拥有方客户端采用与自身DID对应的私钥对目标明文数据进行签名得到。
步骤722,使用方客户端保存可验证声明和签名体。
图8是一示例性实施例提供的另一种调用合约的方法的流程图。如图8所示,该调用过程可以包括步骤802~步骤830。
步骤802,使用方客户端创建调用请求。
在本实施例中,使用方客户端可获取数据拥有方采用链下合约的合约身份公钥对目标明文数据进行加密得到的目标密文数据,进而在需要调用链下合约对目标明文数据进行处理时,创建调用请求,该调用请求中包含目标密文数据、从数据拥有方获取到的可验证声明、数据使用方DID、数据使用方的签名和数据拥有方的签名体。其中,对于数据使用方的签名,可由使用方客户端采用与数据使用方的DID对应的私钥对调用请求进行签名得到。当然,调用请求还可包含与调用操作相关的信息,比如链下合约的合约ID、被调用函数的函数名等。合约ID譬如可以为链下合约的字节码的哈希值,使得链下隐私计算节点(可能部署有多个链下合约)可以据此找到相应的已部署的链下合约的字节码。链下合约可能包含多个函数,因而函数名可以指明数据使用方希望调用的函数;如果链下合约仅包含一个函数,或者数据使用方希望调用链下合约中的所有函数,那么调用请求中也可以省去函数名的信息。
当然,目标密文数据作为入参数据,可能为区块链数据,那么调用请求中可不必包含目标密文数据本身,而是包含入参数据的描述信息(比如为入参数据在区块链上的索引或存储地址等)。使用方客户端可以通过链上渠道向链下隐私计算节点发送调用请求,比如使用方客户端可以向区块链网络提交链下合约调用交易,该链下合约调用交易中包含调用请求,并且该链下合约调用交易用于调用获取区块链上存证的入参数据的链上合约。当然,链下合约调用交易本身也可以是加密传输的,这可以参考前文所述的数据加密传输的内容,此处不再赘述。那么,区块链节点收到加密后的链下合约调用交易后,在自身的链上TEE中进行解密,然后通过链上TEE内部署的虚拟机执行被调用的链上合约,从而根据调用请求中记录的描述信息获取被作为入参数据的区块链数据(即目标密文数据)。然后,区块链节点可通过预言机机制将该区块链数据与调用请求一并发送至链下隐私计算节点。比如,区块链节点可将该区块链数据写入调用请求中,或者将该区块链数据与调用请求打包发送至链下隐私计算节点,或者读取调用请求中包含的可验证声明、签名体、DID等数据,并根据这些数据与该区块链数据重新生成一调用请求,将重新生成的调用请求发送至链下隐私计算节点。
步骤804,使用方客户端向链下隐私计算节点提交调用请求。
步骤806,链下隐私计算节点在链下TEE内解密目标密文数据。
步骤808,链下隐私计算节点向区块链节点发起针对数据使用方DID和数据拥有方DID的查询交易。
在本实施例中,在一种情况下,调用请求中可直接记录数据拥有方DID和数据使用方DID。其中,数据拥有方的签名体中可包含数据拥有方DID。在该情况下,将数据拥有方DID作为调用请求中记录的数据拥有方的第一DID,将该数据使用方DID作为调用请求中记录的数据使用方的第二DID。在另一种情况下,调用请求中可无需直接记录数据拥有方DID和数据使用方DID,而是将调用请求中可验证声明中记录的颁发方作为上述第一DID,以及将调用请求中可验证声明中记录的颁发对象作为上述第二DID。
在本实施例中,查询交易中包含数据使用方DID和数据拥有方DID,从而从区块链(用于存证DID和DID文档的区块链)上查询相应的DID文档。当然,链下隐私计算节点向区块链查询数据使用方的DID文档,与查询数据拥有方的DID文档之间可相互独立,不存在优先级。比如,链下隐私计算节点还可以先向区块链查询数据使用方的DID文档,再查询数据拥有方的DID文档;或者,先向区块链查询数据拥有方的DID文档,再查询数据使用方的DID文档。
步骤810,区块链节点查询数据使用方的DID文档和数据拥有方的DID文档。
步骤812,链下隐私计算节点获取区块链节点查询到的DID文档。
步骤814,链下隐私计算节点验证数据拥有方的签名。
步骤816,链下隐私计算节点验证数据使用方的签名。
在本实施例中,调用请求中记录有数据拥有方DID、数据使用方DID和可验证声 明,这些信息均由数据使用方提供,用于声明可验证声明为目标明文数据的数据拥有方向该数据使用方颁发的可验证声明,而调用请求中的上述信息存在伪造的可能。具体而言,伪造的情况包含以下至少之一:调用请求中记录的数据拥有方DID并非实际的数据拥有方DID(实际的数据拥有方DID为目标明文数据实际拥有方的DID)、调用请求中记录的数据使用方DID并非实际的数据使用方DID(比如,发起调用请求的数据使用方填写了其他用户的DID来假冒该用户)、调用请求中包含的可验证声明并非由实际的数据拥有方颁发、调用请求中包含的可验证声明并非颁发给实际的数据使用方。
因此,链下隐私计算节点可通过数据拥有方的DID文档中记录的公钥(即第一用户公钥)对签名体中记录的签名(即第一签名信息)进行签名验证。由于只有实际的数据拥有方才持有目标明文数据(向其他用户提供的是目标密文数据),才能够对目标明文数据进行签名,其他用户无法对目标明文数据进行签名,那么在签名验证通过的情况(说明签名体中的签名由实际的数据拥有方采用自身DID对应的私钥对目标明文数据进行签名得到)下,说明调用请求中记录的数据拥有方DID(即第一DID)为实际的数据拥有方DID。以数字签名的方式为例,数据拥有方在提供签名体时,对目标明文数据进行哈希计算得到第一哈希值,再采用与自身DID对应的私钥对第一哈希值进行签名得到第一签名信息,并将第一签名信息添加到签名体中。链下隐私计算节点通过步骤806解密目标密文数据得到了目标明文数据,对该目标明文数据进行哈希计算得到第二哈希值,基于第二哈希值和数据拥有方的DID文档中记录的公钥对第一签名信息进行签名验证,从而在签名验证通过的情况下,判定调用请求中记录的数据拥有方DID为实际的数据拥有方DID,进而排除伪造数据拥有方DID的可能。
需要说明的是,数据拥有方可能存在多对用于签名的非对称密钥,那么数据拥有方在提供签名体时,可在签名体中添加公钥ID,该公钥ID对应的公钥,与对目标明文数据签名所采用的私钥为一对非对称密钥对。
类似的,调用请求中记录的第二签名信息,由数据使用方采用与数据使用方DID对应的私钥对调用请求进行签名得到。因此,链下隐私计算节点可通过数据使用方的DID文档中记录的公钥(即第二用户公钥)对第二签名信息进行签名验证,并在签名验证通过的情况下,判定调用请求中记录的数据使用方的第二DID为实际的数据使用方DID。
步骤818,链下隐私计算节点校验可验证声明的实际颁发方是否为数据拥有方。
步骤820,链下隐私计算节点校验可验证声明的实际颁发对象是否为数据使用方。
承接于上述步骤814-816的验证,还需进一步验证调用请求中的可验证声明是否为数据拥有方向数据使用方颁发的可验证声明。比如,在调用请求中记录的数据拥有方DID和数据使用方DID通过验证的情况下,若可验证声明的实际颁发方的DID与数据拥有方DID相匹配,则说明调用请求中的可验证声明由实际的数据拥有方颁发。以及,若可验证声明的实际颁发对象的DID与数据使用方DID相匹配,则说明调用请求中的可验证声明由实际的数据使用方接收(即是颁发给实际的数据使用方的)。需要说明的是,步骤814-820之间不存在时间先后顺序上的限制,本实施例中的顺序仅为举例说明。
由上述图7颁发可验证声明的过程可知,可验证声明的颁发方在颁发该可验证声明时,会在该可验证声明中记录自身的DID以及颁发对象的DID,同时采用与自身DID对应的私钥对该可验证声明进行签名,并将签名记录在该可验证声明的proof中以用于证明自身的身份。
以验证了调用请求中记录的数据拥有方DID和数据使用方DID且验证均通过为例进行说明。若可验证声明中记录的颁发方DID与数据拥有方DID不同,或者可验证声明中记录的颁发对象DID与数据使用方DID不同,则说明可验证声明不正确,判定禁止使用目标明文数据。否则,进一步读取可验证声明的issuer记录的颁发方DID,并获取与读取到的颁发方DID对应的第三用户公钥(即数据拥有方的DID文档中记录的公 钥),采用第三用户公钥对proof中记录的签名进行签名验证,并在签名验证通过的情况下确认可验证声明验证通过,也即确认可验证声明记录的颁发方DID为实际颁发方的DID(也为实际的数据拥有方DID);以及,可验证声明记录的颁发对象DID为实际颁发对象的DID(也为实际的数据使用方DID)。
步骤822,链下隐私计算节点校验调用操作是否符合可验证声明中定义的调用规则。
在本实施例中,在确认出调用请求中的可验证声明为目标明文数据的数据拥有方(实际的数据拥有方)向数据使用方(即提交调用请求的实际数据使用方)颁发的可验证声明后,链下隐私计算节点可以认可该可验证声明中定义的调用规则,即该可验证声明中定义的调用规则可信。那么,可进一步根据调用规则对数据使用方针对目标明文数据的使用权进行控制。
可校验调用请求指示的调用操作是否符合可验证声明中定义的调用规则。若符合,在转入步骤824;否则,判定数据使用方禁止执行链下合约对目标明文数据进行处理。比如,当根据可验证声明中的expire判断出数据使用方针对目标明文数据的使用权到期时,禁止执行链下合约对目标明文数据进行处理。又如,当数据使用方所需调用的合约函数不符合调用规则中定义的允许处理目标明文数据的合约函数时,禁止执行链下合约对目标明文数据进行处理。当然,调用规则的具体内容可根据实际需求灵活设定,本说明书并不对此进行限制。
步骤824,链下隐私计算节点在TEE内执行链下合约。
步骤826,链下隐私计算节点在TEE内采用链下合约的合约身份私钥对执行结果签名。
步骤828,链下隐私计算节点向使用方客户端反馈执行结果。
步骤830,使用方客户端采用链下合约的合约身份公钥验证执行结果。
由以上实施例可见,数据拥有方可对自身拥有的目标明文数据进行加密得到目标密文数据,并向数据使用方提供目标密文数据,以及向数据使用方颁发针对该目标明文数据的使用权的可验证声明,可实现对目标明文数据使用权的权限控制,即控制目标明文数据允许被哪些用户调用链下合约进行处理。通过上述针对目标明文数据的授权机制,目标明文数据的使用权由数据拥有方把控,可有效提高数据拥有方的隐私安全性。进一步的,在进行授权时引入DID来表示各个用户的身份,可以使得用户的身份真正为用户所拥有并支配,用户可对自身的身份进行自主创建,以及完全去中心化的身份管理。
对应于上述数据使用方侧的实施例,本说明书还提出了链下隐私计算节点侧的实施例,在数据使用方侧实施例中所涉及的描述同样可以适用于链下隐私计算节点侧的实施例,下文中不再对此进行赘述。
相应地,图9是一示例性实施例提供的一种链下隐私计算节点侧的调用合约的方法的流程图。如图9所示,该方法可以包括步骤902~步骤904。
步骤902,链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明。
如前所述,所述链下隐私计算节点接收所述区块链节点通过所述预言机机制转发的所述调用请求,所述调用请求由所述数据使用方提交至所述区块链节点;或者,
在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的所述调用请求,所述调用请求由所述数据使用方提交至所述区块链节点,并由所述区块链节点通过所述预言机机制转发至所述控制节点。
步骤904所述链下隐私计算节点在调用条件被满足的情况下在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数 据使用方授予了所述使用权。
如前所述,所述链下隐私计算节点在以下校验操作均通过的情况下确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
如前所述,所述链下隐私计算节点在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;所述链下隐私计算节点在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;所述链下隐私计算节点在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;所述链下隐私计算节点在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
如前所述,所述链下隐私计算节点可读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
如前所述,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
如前所述,所述调用规则包括以下至少之一:所述链下合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述链下合约对所述目标明文数据进行处理的次数和允许调用所述链下合约对所述目标明文数据进行处理的频率。
如前所述,所述目标密文数据由所述数据拥有方采用所述链下合约的合约身份公钥对所述目标明文数据进行加密得到,所述链下可信执行环境内维护有对应于所述合约身份公钥的合约身份私钥,所述目标密文数据由所述链下隐私计算节点在所述链下可信执行环境内采用所述合约身份私钥进行解密。
如前所述,所述链下隐私计算节点在所述链下可信执行环境内采用所述链下合约的合约身份私钥对执行所述链下合约得到的执行结果进行签名;所述链下隐私计算节点通过所述预言机机制将所述执行结果反馈至区块链节点以由所述数据使用方获取,所述数据使用方在采用所述链下合约的合约身份公钥对所述执行结果进行签名验证且签名验证通过的情况下,判定所述执行结果由所述链下合约生成。
如前所述,在接收所述调用请求之前,链下隐私计算节点向数据使用方提供针对所述链下可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点针对所述链下可信执行环境产生的自荐信息进行验证后生成;所述链下隐私计算节点向所述数据使用方提供部署于所述链下隐私计算节点处的所述链下合约的待验证合约信息,所述待验证合约信息被所述链下隐私计算节点在所述链下可信执行环境内采用所述链下隐私计算节点的身份私钥进行签名,所述身份私钥由所述链下隐私计算节点在所述链下可信执行环境内维护;所述待验证合约信息由所述数据使用方在根据所 述远程证明报告确定所述链下可信执行环境可信的情况下,采用所述链下隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述链下合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在通过区块链节点的预言机机制对所述链下合约发起调用时,所述链下合约由所述链下隐私计算节点在所述链下可信执行环境中执行。
如前所述,所述链下隐私计算节点接收所述数据使用方向所述链下隐私计算节点发起的挑战,向所述数据使用方返回所述远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,在所述链下隐私计算集群的控制节点接收到所述数据使用方发起的挑战后,向所述控制节点发送所述远程证明报告,所述远程证明报告由所述控制节点返回至所述数据使用方。
如前所述,所述远程证明报告携带的所述自荐信息内包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于所述数据使用方在根据所述认证服务器的公钥对所述远程证明报告进行签名验证并签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对所述链下可信执行环境的第一标准哈希值进行比较,且比较结果一致被作为所述数据使用方确认所述链下可信执行环境可信的前提条件。
如前所述,所述链下隐私计算节点向所述数据使用方提供第一身份信息,所述第一身份信息包含所述链下隐私计算节点的身份公钥和所述链下隐私计算节点的其他身份信息,所述第一身份信息被所述数据使用方进行哈希计算以得到第二待校验哈希值;所述链下隐私计算节点向所述数据使用方提供第二标准哈希值,所述第二标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二标准哈希值用于与所述第二待校验哈希值进行比较,且所述数据使用方在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
如前所述,所述链下隐私计算节点向所述数据使用方提供自身的第二身份信息,所述第二身份信息包含所述链下隐私计算节点的身份公钥、所述链下隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述链下可信执行环境的预设信息的哈希值;所述链下隐私计算节点向所述数据使用方提供第三标准哈希值,所述第三标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二身份信息在所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,被所述数据使用方进行哈希计算以得到第三待校验哈希值;其中,确认所述链下可信执行环境可信的前提条件包含在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,所述第四待校验哈希值与所述数据使用方预先获得的针对所述链下可信执行环境的第四标准哈希值一致;所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
如前所述,所述链下可信执行环境内维护有对应于所述身份公钥的身份私钥;所述链下隐私计算节点在所述链下可信执行环境内采用所述身份私钥对所述调用请求进行解密,所述调用请求由所述数据使用方采用所述链下隐私计算节点的身份公钥进行加密。
如前所述,所述链下隐私计算节点的身份私钥为所述链下隐私计算节点的节点身份密钥中的节点身份私钥,所述链下隐私计算节点的身份公钥为所述节点身份密钥中的节点身份公钥;其中,在区块链节点与所述链下隐私计算节点进行交互以部署或调用链下合约的过程中,所述节点身份密钥用于对交互数据进行加密解密和/或签名签名验证;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点的身份公钥为所述链下隐私计算集群的集群身份密钥中的集群身份公钥,所述链下隐 私计算节点的身份私钥为所述集群身份密钥中的集群身份私钥;其中,在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中,所述集群身份密钥用于对交互数据进行加密解密和/或签名签名验证。
在本说明书的技术方案中,还可由数据使用方通过使用方客户端直接与隐私计算节点进行交互以完成在隐私计算节点上部署智能合约、向智能合约发起挑战、验证智能合约和调用智能合约等操作,而无需通过区块链的预言机机制来完成上述操作,同时调用部署于隐私计算节点的智能合约得到的计算结果也无需反馈至区块链。在该情况下,由于不涉及链上和链下的区分,下文将“链下隐私计算节点”称为“隐私计算节点”,将“链下可信执行环境”称为“可信执行环境”,将“目标链下合约”称为“目标智能合约”。但是,技术方案的原理与上述实施例类似,所涉及的实施细节同样可参考上述实施例,因此下文不再进行详细描述。
图10是一示例性实施例提供的另一种数据使用方侧的调用合约的方法的流程图。如图10所示,该方法可以包括步骤1002~步骤1004。
步骤1002,数据使用方生成针对智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明。
步骤1004,所述数据使用方向部署有所述智能合约的隐私计算节点提交所述调用请求,所述调用请求用于指示所述隐私计算节点在调用条件被满足的情况下,在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
如前所述,在以下校验操作均通过的情况下,所述隐私计算节点确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
如前所述,在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
如前所述,通过以下方式确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
如前所述,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
如前所述,所述调用规则包括以下至少之一:所述智能合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述智能合约对所述目标明文数据进行处理的次数和允许调用所述智能合约对所述目标明文数据进行处理的频率。
如前所述,在提交所述调用请求之前,所述数据使用方获取针对所述可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点针对所述可信执行环境产生的自荐信息进行验证后生成;所述数据使用方在根据所述远程证明报告确定所述可信执行环境可信的情况下,获取部署于所述隐私计算节点处的所述智能合约的待验证合约信息,所述待验证合约信息被所述隐私计算节点在所述可信执行环境内采用所述隐私计算节点的身份私钥进行签名,所述身份私钥由所述隐私计算节点在所述可信执行环境内维护;所述数据使用方采用所述隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述智能合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在对所述智能合约发起调用时,所述智能合约由所述隐私计算节点在所述可信执行环境中执行。
如前所述,所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值;将预先获得的针对所述可信执行环境的第一标准哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述可信执行环境可信的前提条件。
如前所述,所述数据使用方获取所述隐私计算节点提供的第一身份信息,并对获取到的第一身份信息进行哈希计算以得到第二待校验哈希值,所述第一身份信息包含所述隐私计算节点的身份公钥和所述隐私计算节点的其他身份信息;所述数据使用方获取所述隐私计算节点提供的第二标准哈希值,所述第二标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述数据使用方将所述第二待校验哈希值与所述第二标准哈希值进行比较,并在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
如前所述,所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,获取所述隐私计算节点提供的第二身份信息,并对获取到的第二身份信息进行哈希计算以得到第三待校验哈希值,所述第二身份信息包含所述隐私计算节点的身份公钥、所述隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述可信执行环境的预设信息的哈希值;获取所述隐私计算节点提供的第三标准哈希值,并将所述第三待校验哈希值与第三标准哈希值进行比较,所述第三标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,将预先获得的针对所述可信执行环境的第四标准哈希值与所述第四待检验哈希值进行比较,并将比较结果一致作为确认所述可信执行环境可信的前提条件;其中,所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
相应的,图11是一示例性实施例提供的一种隐私计算节点侧的调用合约的方法的流程图。如图11所示,该方法可以包括步骤1102~步骤1104。
步骤1102,隐私计算节点接收数据使用方提交的针对所述隐私计算节点部署的智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明。
步骤1104,所述隐私计算节点在调用条件被满足的情况下在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件 包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
如前所述,所述隐私计算节点在以下校验操作均通过的情况下确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
如前所述,所述隐私计算节点在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;所述隐私计算节点在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;所述隐私计算节点在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;所述隐私计算节点在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
如前所述,所述隐私计算节点确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符,包括:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
如前所述,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
如前所述,所述调用规则包括以下至少之一:所述智能合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述智能合约对所述目标明文数据进行处理的次数和允许调用所述智能合约对所述目标明文数据进行处理的频率。
如前所述,在接收所述调用请求之前,隐私计算节点向数据使用方提供针对所述可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点针对所述可信执行环境产生的自荐信息进行验证后生成;所述隐私计算节点向所述数据使用方提供部署于所述隐私计算节点处的所述智能合约的待验证合约信息,所述待验证合约信息被所述隐私计算节点在所述可信执行环境内采用所述隐私计算节点的身份私钥进行签名,所述身份私钥由所述隐私计算节点在所述可信执行环境内维护;所述待验证合约信息由所述数据使用方在根据所述远程证明报告确定所述可信执行环境可信的情况下,采用所述隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述智能合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在对所述智能合约发起调用时,所述智能合约由所述隐私计算节点在所述可信执行环境中执行。
如前所述,所述远程证明报告携带的所述自荐信息内包含第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值,所述第一待检验哈希值 用于所述数据使用方在根据所述认证服务器的公钥对所述远程证明报告进行签名验证并签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对所述可信执行环境的第一标准哈希值进行比较,且比较结果一致被作为所述数据使用方确认所述可信执行环境可信的前提条件。
如前所述,所述隐私计算节点向所述数据使用方提供第一身份信息,所述第一身份信息包含所述隐私计算节点的身份公钥和所述隐私计算节点的其他身份信息,所述第一身份信息被所述数据使用方进行哈希计算以得到第二待校验哈希值;所述隐私计算节点向所述数据使用方提供第二标准哈希值,所述第二标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二标准哈希值用于与所述第二待校验哈希值进行比较,且所述数据使用方在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
如前所述,所述隐私计算节点向所述数据使用方提供自身的第二身份信息,所述第二身份信息包含所述隐私计算节点的身份公钥、所述隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述可信执行环境的预设信息的哈希值;所述隐私计算节点向所述数据使用方提供第三标准哈希值,所述第三标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二身份信息在所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,被所述数据使用方进行哈希计算以得到第三待校验哈希值;其中,确认所述可信执行环境可信的前提条件包含在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,所述第四待校验哈希值与所述数据使用方预先获得的针对所述可信执行环境的第四标准哈希值一致;所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
与上述方法实施例相对应,本说明书还提供了调用合约的装置的实施例。
本说明书的调用合约的装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,请参考图12,图12是一示例性实施例提供的一种设备的示意结构图。如图12所示,在硬件层面,该设备包括处理器1202、内部总线1204、网络接口1206、内存1208以及非易失性存储器1210,当然还可能包括其他业务所需要的硬件。处理器1202从非易失性存储器1210中读取对应的计算机程序到内存1208中然后运行,在逻辑层面上形成调用合约的装置。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图13,在一种软件实施方式中,数据使用方侧的调用合约的装置可以包括:生成单元1301,使数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;提交单元1302,使所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
可选的,所述提交单元1302具体用于:使所述数据使用方向区块链节点提交所述调用请求,由所述区块链节点通过所述预言机机制向所述链下隐私计算节点转发所述调用请求;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述数据使 用方向区块链节点提交所述调用请求,由所述区块链节点通过所述预言机机制向所述链下隐私计算集群的控制节点转发所述调用请求,所述调用请求由所述控制节点转发至所述链下隐私计算节点。
可选的,在以下校验操作均通过的情况下,所述链下隐私计算节点确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
可选的,在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
可选的,通过以下方式确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
可选的,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
可选的,所述调用规则包括以下至少之一:所述链下合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述链下合约对所述目标明文数据进行处理的次数和允许调用所述链下合约对所述目标明文数据进行处理的频率。
可选的,所述目标密文数据由所述数据拥有方采用所述链下合约的合约身份公钥对所述目标明文数据进行加密得到,所述链下可信执行环境内维护有对应于所述合约身份公钥的合约身份私钥,所述目标密文数据由所述链下隐私计算节点在所述链下可信执行环境内采用所述合约身份私钥进行解密。
可选的,所述提交单元1302具体用于:使所述数据使用方获取所述链下隐私计算节点通过所述预言机机制反馈至区块链节点的执行结果,所述执行结果由所述链下隐私计算节点执行所述链下合约得到,并在所述链下可信执行环境内被采用所述链下合约的合约身份私钥进行签名;所述数据使用方在采用所述链下合约的合约身份公钥对所述执行结果进行签名验证且签名验证通过的情况下,判定所述执行结果由所述链下合约生成。
可选的,在提交所述调用请求之前,所述装置还包括:报告获取单元1303,使所述数据使用方获取针对所述链下可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点针对所述链下可信执行环境产生的自荐信息进行验证后生成;信息获取单元1304,使所述数据使用方在根据所述远程证明报告确定所述链下可信执行环境可信的情况下,获取部署于所述链下隐私计算节点处的所述链下合约的 待验证合约信息,所述待验证合约信息被所述链下隐私计算节点在所述链下可信执行环境内采用所述链下隐私计算节点的身份私钥进行签名,所述身份私钥由所述链下隐私计算节点在所述链下可信执行环境内维护;验证单元1305,使所述数据使用方采用所述链下隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述链下合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在通过所述预言机机制对所述链下合约发起调用时,所述链下合约由所述链下隐私计算节点在所述链下可信执行环境中执行。
可选的,所述报告获取单元1303具体用于:使所述数据使用方向所述链下隐私计算节点发起挑战,并接收所述链下隐私计算节点返回的远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述数据使用方向所述链下隐私计算集群的控制节点发起挑战,并接收所述控制节点返回的远程证明报告。
可选的,所述信息获取单元1304具体用于:使所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值;将预先获得的针对所述链下可信执行环境的第一标准哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述链下可信执行环境可信的前提条件。
可选的,所述验证单元1305具体用于:使所述数据使用方获取所述链下隐私计算节点提供的第一身份信息,并对获取到的第一身份信息进行哈希计算以得到第二待校验哈希值,所述第一身份信息包含所述链下隐私计算节点的身份公钥和所述链下隐私计算节点的其他身份信息;所述数据使用方获取所述链下隐私计算节点提供的第二标准哈希值,所述第二标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述数据使用方将所述第二待校验哈希值与所述第二标准哈希值进行比较,并在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
可选的,所述信息获取单元1304具体用于:使所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,获取所述链下隐私计算节点提供的第二身份信息,并对获取到的第二身份信息进行哈希计算以得到第三待校验哈希值,所述第二身份信息包含所述链下隐私计算节点的身份公钥、所述链下隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述链下可信执行环境的预设信息的哈希值;获取所述链下隐私计算节点提供的第三标准哈希值,并将所述第三待校验哈希值与第三标准哈希值进行比较,所述第三标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,将预先获得的针对所述链下可信执行环境的第四标准哈希值与所述第四待检验哈希值进行比较,并将比较结果一致作为确认所述链下可信执行环境可信的前提条件;其中,所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
可选的,所述调用请求由所述数据使用方采用所述链下隐私计算节点的身份公钥进行加密,所述链下可信执行环境内维护有对应于所述身份公钥的身份私钥,所述调用请求由所述链下隐私计算节点在所述链下可信执行环境内采用所述身份私钥进行解密。
可选的,所述链下隐私计算节点的身份私钥为所述链下隐私计算节点的节点身份密钥中的节点身份私钥,所述链下隐私计算节点的身份公钥为所述节点身份密钥中的节点身份公钥;其中,在区块链节点与所述链下隐私计算节点进行交互以部署或调用链下合约的过程中,所述节点身份密钥用于对交互数据进行加密解密和/或签名签名验证;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点 的身份公钥为所述链下隐私计算集群的集群身份密钥中的集群身份公钥,所述链下隐私计算节点的身份私钥为所述集群身份密钥中的集群身份私钥;其中,在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中,所述集群身份密钥用于对交互数据进行加密解密和/或签名签名验证。
请参考图14,在另一种软件实施方式中,链下隐私计算节点侧的调用合约的装置可以包括:接收单元1401,使链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;执行单元1402,使所述链下隐私计算节点在调用条件被满足的情况下在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
可选的,所述链下隐私计算节点接收所述区块链节点通过所述预言机机制转发的所述调用请求,所述调用请求由所述数据使用方提交至所述区块链节点;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的所述调用请求,所述调用请求由所述数据使用方提交至所述区块链节点,并由所述区块链节点通过所述预言机机制转发至所述控制节点。
可选的,所述链下隐私计算节点在以下校验操作均通过的情况下确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
可选的,所述链下隐私计算节点在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;所述链下隐私计算节点在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;所述链下隐私计算节点在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;所述链下隐私计算节点在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
可选的,所述执行单元1402具体用于:使所述链下隐私计算节点读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
可选的,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
可选的,所述调用规则包括以下至少之一:所述链下合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述链下合约对所述目标明文数据进行处理的次数和允许调用所述链下合约对所述目标明文数据进行处 理的频率。
可选的,所述目标密文数据由所述数据拥有方采用所述链下合约的合约身份公钥对所述目标明文数据进行加密得到,所述链下可信执行环境内维护有对应于所述合约身份公钥的合约身份私钥,所述目标密文数据由所述链下隐私计算节点在所述链下可信执行环境内采用所述合约身份私钥进行解密。
可选的,所述执行单元1402具体用于:所述链下隐私计算节点在所述链下可信执行环境内采用所述链下合约的合约身份私钥对执行所述链下合约得到的执行结果进行签名;所述链下隐私计算节点通过所述预言机机制将所述执行结果反馈至区块链节点以由所述数据使用方获取,所述数据使用方在采用所述链下合约的合约身份公钥对所述执行结果进行签名验证且签名验证通过的情况下,判定所述执行结果由所述链下合约生成。
可选的,在接收所述调用请求之前,所述装置还包括:报告提供单元1403,使链下隐私计算节点向数据使用方提供针对所述链下可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点针对所述链下可信执行环境产生的自荐信息进行验证后生成;信息提供单元1404,使所述链下隐私计算节点向所述数据使用方提供部署于所述链下隐私计算节点处的所述链下合约的待验证合约信息,所述待验证合约信息被所述链下隐私计算节点在所述链下可信执行环境内采用所述链下隐私计算节点的身份私钥进行签名,所述身份私钥由所述链下隐私计算节点在所述链下可信执行环境内维护;所述待验证合约信息由所述数据使用方在根据所述远程证明报告确定所述链下可信执行环境可信的情况下,采用所述链下隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述链下合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在通过区块链节点的预言机机制对所述链下合约发起调用时,所述链下合约由所述链下隐私计算节点在所述链下可信执行环境中执行。
可选的,所述报告提供单元1403具体用于:使所述链下隐私计算节点接收所述数据使用方向所述链下隐私计算节点发起的挑战,向所述数据使用方返回所述远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,在所述链下隐私计算集群的控制节点接收到所述数据使用方发起的挑战后,向所述控制节点发送所述远程证明报告,所述远程证明报告由所述控制节点返回至所述数据使用方。
可选的,所述远程证明报告携带的所述自荐信息内包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于所述数据使用方在根据所述认证服务器的公钥对所述远程证明报告进行签名验证并签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对所述链下可信执行环境的第一标准哈希值进行比较,且比较结果一致被作为所述数据使用方确认所述链下可信执行环境可信的前提条件。
可选的,所述信息提供单元1404具体用于:使所述链下隐私计算节点向所述数据使用方提供第一身份信息,所述第一身份信息包含所述链下隐私计算节点的身份公钥和所述链下隐私计算节点的其他身份信息,所述第一身份信息被所述数据使用方进行哈希计算以得到第二待校验哈希值;向所述数据使用方提供第二标准哈希值,所述第二标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二标准哈希值用于与所述第二待校验哈希值进行比较,且所述数据使用方在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
可选的,所述信息提供单元1404具体用于:使所述链下隐私计算节点向所述数据使用方提供自身的第二身份信息,所述第二身份信息包含所述链下隐私计算节点的身份公钥、所述链下隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述链下可信执行环境的预设信息的哈希值;向所述数据使用方提供第三标准哈 希值,所述第三标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二身份信息在所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,被所述数据使用方进行哈希计算以得到第三待校验哈希值;其中,确认所述链下可信执行环境可信的前提条件包含在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,所述第四待校验哈希值与所述数据使用方预先获得的针对所述链下可信执行环境的第四标准哈希值一致;所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
可选的,所述链下可信执行环境内维护有对应于所述身份公钥的身份私钥;所述接收单元1401具体用于:
所述链下隐私计算节点在所述链下可信执行环境内采用所述身份私钥对所述调用请求进行解密,所述调用请求由所述数据使用方采用所述链下隐私计算节点的身份公钥进行加密。
可选的,所述链下隐私计算节点的身份私钥为所述链下隐私计算节点的节点身份密钥中的节点身份私钥,所述链下隐私计算节点的身份公钥为所述节点身份密钥中的节点身份公钥;其中,在区块链节点与所述链下隐私计算节点进行交互以部署或调用链下合约的过程中,所述节点身份密钥用于对交互数据进行加密解密和/或签名签名验证;或者,
在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点的身份公钥为所述链下隐私计算集群的集群身份密钥中的集群身份公钥,所述链下隐私计算节点的身份私钥为所述集群身份密钥中的集群身份私钥;其中,在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中,所述集群身份密钥用于对交互数据进行加密解密和/或签名签名验证。
请参考图15,在另一种软件实施方式中,数据使用方侧的调用合约的装置可以包括:生成单元1501,使数据使用方生成针对智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;提交单元1502,使所述数据使用方向部署有所述智能合约的隐私计算节点提交所述调用请求,所述调用请求用于指示所述隐私计算节点在调用条件被满足的情况下,在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
可选的,在以下校验操作均通过的情况下,所述隐私计算节点确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
可选的,在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述 第四真实性校验操作通过。
可选的,通过以下方式确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
可选的,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
可选的,所述调用规则包括以下至少之一:所述智能合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述智能合约对所述目标明文数据进行处理的次数和允许调用所述智能合约对所述目标明文数据进行处理的频率。
可选的,在提交所述调用请求之前,所述装置还包括:报告获取单元1503,使所述数据使用方获取针对所述可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点针对所述可信执行环境产生的自荐信息进行验证后生成;信息获取单元1504,使所述数据使用方在根据所述远程证明报告确定所述可信执行环境可信的情况下,获取部署于所述隐私计算节点处的所述智能合约的待验证合约信息,所述待验证合约信息被所述隐私计算节点在所述可信执行环境内采用所述隐私计算节点的身份私钥进行签名,所述身份私钥由所述隐私计算节点在所述可信执行环境内维护;验证单元1505,使所述数据使用方采用所述隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述智能合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在对所述智能合约发起调用时,所述智能合约由所述隐私计算节点在所述可信执行环境中执行。
可选的,报告获取单元1503具体用于:根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值;将预先获得的针对所述可信执行环境的第一标准哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述可信执行环境可信的前提条件。
可选的,信息获取单元1504具体用于:所述数据使用方获取所述隐私计算节点提供的第一身份信息,并对获取到的第一身份信息进行哈希计算以得到第二待校验哈希值,所述第一身份信息包含所述隐私计算节点的身份公钥和所述隐私计算节点的其他身份信息;所述数据使用方获取所述隐私计算节点提供的第二标准哈希值,所述第二标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述数据使用方将所述第二待校验哈希值与所述第二标准哈希值进行比较,并在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
可选的,信息获取单元1504具体用于:根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,获取所述隐私计算节点提供的第二身份信息,并对获取到的第二身份信息进行哈希计算以得到第三待校验哈希值,所述第二身份信息包含所述隐私计算节点的身份公钥、所述隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述可信执行环境的预设信息的哈希值;获取所述隐私计算节点提供的第三标准哈希值,并将所述第三待校验哈希值与第三标准哈希值进行比较,所述第三标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;在所述第三待校验哈希值与所述第三标准哈希值一致的情况下, 将预先获得的针对所述可信执行环境的第四标准哈希值与所述第四待检验哈希值进行比较,并将比较结果一致作为确认所述可信执行环境可信的前提条件;其中,所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
请参考图16,在另一种软件实施方式中,隐私计算节点侧的调用合约的装置可以包括:接收单元1601,使隐私计算节点接收数据使用方提交的针对所述隐私计算节点部署的智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;执行单元1602,使所述隐私计算节点在调用条件被满足的情况下在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
可选的,所述隐私计算节点在以下校验操作均通过的情况下确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
可选的,所述隐私计算节点在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;所述隐私计算节点在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;所述隐私计算节点在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;所述隐私计算节点在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
可选的,所述隐私计算节点确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符,包括:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
可选的,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
可选的,所述调用规则包括以下至少之一:所述智能合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述智能合约对所述目标明文数据进行处理的次数和允许调用所述智能合约对所述目标明文数据进行处理的频率。
可选的,在接收所述调用请求之前,所述装置还包括:报告提供单元1603,使隐私计算节点向数据使用方提供针对所述可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点针对所述可信执行环境产生的自荐信息进行验证后生成;信息提供单元1604,使所述隐私计算节点向所述数据使用方提供部署于所述隐私计算节点处的所述智能合约的待验证合约信息,所述待验证合约信息被所述隐私计算节点在所述可信执行环境内采用所述隐私计算节点的身份私钥进行签名,所述身份私钥由所述隐私计算节点在所述可信执行环境内维护;所述待验证合约信息由所述数据使用 方在根据所述远程证明报告确定所述可信执行环境可信的情况下,采用所述隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述智能合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在对所述智能合约发起调用时,所述智能合约由所述隐私计算节点在所述可信执行环境中执行。
可选的,所述远程证明报告携带的所述自荐信息内包含第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于所述数据使用方在根据所述认证服务器的公钥对所述远程证明报告进行签名验证并签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对所述可信执行环境的第一标准哈希值进行比较,且比较结果一致被作为所述数据使用方确认所述可信执行环境可信的前提条件。
可选的,信息提供单元1604具体用于:所述隐私计算节点向所述数据使用方提供第一身份信息,所述第一身份信息包含所述隐私计算节点的身份公钥和所述隐私计算节点的其他身份信息,所述第一身份信息被所述数据使用方进行哈希计算以得到第二待校验哈希值;所述隐私计算节点向所述数据使用方提供第二标准哈希值,所述第二标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二标准哈希值用于与所述第二待校验哈希值进行比较,且所述数据使用方在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
可选的,信息提供单元1604具体用于:所述隐私计算节点向所述数据使用方提供自身的第二身份信息,所述第二身份信息包含所述隐私计算节点的身份公钥、所述隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述可信执行环境的预设信息的哈希值;所述隐私计算节点向所述数据使用方提供第三标准哈希值,所述第三标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二身份信息在所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,被所述数据使用方进行哈希计算以得到第三待校验哈希值;其中,确认所述可信执行环境可信的前提条件包含在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,所述第四待校验哈希值与所述数据使用方预先获得的针对所述可信执行环境的第四标准哈希值一致;所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本说明书的实施例可提供为方法、系统、或计算机程序产品。因此,本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器 执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。
Claims (58)
- 一种调用合约的方法,包括:数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 根据权利要求1所述的方法,所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,包括:所述数据使用方向区块链节点提交所述调用请求,由所述区块链节点通过所述预言机机制向所述链下隐私计算节点转发所述调用请求;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述数据使用方向区块链节点提交所述调用请求,由所述区块链节点通过所述预言机机制向所述链下隐私计算集群的控制节点转发所述调用请求,所述调用请求由所述控制节点转发至所述链下隐私计算节点。
- 根据权利要求1所述的方法,在以下校验操作均通过的情况下,所述链下隐私计算节点确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
- 根据权利要求3所述的方法,在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
- 根据权利要求4所述的方法,通过以下方式确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
- 根据权利要求1所述的方法,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
- 根据权利要求6所述的方法,所述调用规则包括以下至少之一:所述链下合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述链下合约对所述目标明文数据进行处理的次数和允许调用所述链下合约对所述目标明文数据进行处理的频率。
- 根据权利要求1所述的方法,所述目标密文数据由所述数据拥有方采用所述链下合约的合约身份公钥对所述目标明文数据进行加密得到,所述链下可信执行环境内维 护有对应于所述合约身份公钥的合约身份私钥,所述目标密文数据由所述链下隐私计算节点在所述链下可信执行环境内采用所述合约身份私钥进行解密。
- 根据权利要求1所述的方法,还包括:所述数据使用方获取所述链下隐私计算节点通过所述预言机机制反馈至区块链节点的执行结果,所述执行结果由所述链下隐私计算节点执行所述链下合约得到,并在所述链下可信执行环境内被采用所述链下合约的合约身份私钥进行签名;所述数据使用方在采用所述链下合约的合约身份公钥对所述执行结果进行签名验证且签名验证通过的情况下,判定所述执行结果由所述链下合约生成。
- 根据权利要求1所述的方法,在提交所述调用请求之前,所述方法还包括:所述数据使用方获取针对所述链下可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点针对所述链下可信执行环境产生的自荐信息进行验证后生成;所述数据使用方在根据所述远程证明报告确定所述链下可信执行环境可信的情况下,获取部署于所述链下隐私计算节点处的所述链下合约的待验证合约信息,所述待验证合约信息被所述链下隐私计算节点在所述链下可信执行环境内采用所述链下隐私计算节点的身份私钥进行签名,所述身份私钥由所述链下隐私计算节点在所述链下可信执行环境内维护;所述数据使用方采用所述链下隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述链下合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在通过所述预言机机制对所述链下合约发起调用时,所述链下合约由所述链下隐私计算节点在所述链下可信执行环境中执行。
- 根据权利要求10所述的方法,所述数据使用方获取针对所述链下可信执行环境的远程证明报告,包括:所述数据使用方向所述链下隐私计算节点发起挑战,并接收所述链下隐私计算节点返回的远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述数据使用方向所述链下隐私计算集群的控制节点发起挑战,并接收所述控制节点返回的远程证明报告。
- 根据权利要求10所述的方法,所述数据使用方根据所述远程证明报告对所述链下可信执行环境进行验证,包括:根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值;将预先获得的针对所述链下可信执行环境的第一标准哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述链下可信执行环境可信的前提条件。
- 根据权利要求10所述的方法,还包括:所述数据使用方获取所述链下隐私计算节点提供的第一身份信息,并对获取到的第一身份信息进行哈希计算以得到第二待校验哈希值,所述第一身份信息包含所述链下隐私计算节点的身份公钥和所述链下隐私计算节点的其他身份信息;所述数据使用方获取所述链下隐私计算节点提供的第二标准哈希值,所述第二标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述数据使用方将所述第二待校验哈希值与所述第二标准哈希值进行比较,并在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
- 根据权利要求10所述的方法,所述数据使用方根据所述远程证明报告对所述链下可信执行环境进行验证,包括:根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,获取所述链下隐私计算节点提供的第二身份信息,并对获取到的第二身份信息进行哈希计算以得到第三待校验哈希值,所述第二身份信息包含所述链下隐私计算节点的身份公钥、所述链下隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述链下可信执行 环境的预设信息的哈希值;获取所述链下隐私计算节点提供的第三标准哈希值,并将所述第三待校验哈希值与第三标准哈希值进行比较,所述第三标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,将预先获得的针对所述链下可信执行环境的第四标准哈希值与所述第四待检验哈希值进行比较,并将比较结果一致作为确认所述链下可信执行环境可信的前提条件;其中,所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
- 根据权利要求1所述的方法,所述调用请求由所述数据使用方采用所述链下隐私计算节点的身份公钥进行加密,所述链下可信执行环境内维护有对应于所述身份公钥的身份私钥,所述调用请求由所述链下隐私计算节点在所述链下可信执行环境内采用所述身份私钥进行解密。
- 根据权利要求13-15中任一所述的方法,所述链下隐私计算节点的身份私钥为所述链下隐私计算节点的节点身份密钥中的节点身份私钥,所述链下隐私计算节点的身份公钥为所述节点身份密钥中的节点身份公钥;其中,在区块链节点与所述链下隐私计算节点进行交互以部署或调用链下合约的过程中,所述节点身份密钥用于对交互数据进行加密解密和/或签名签名验证;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点的身份公钥为所述链下隐私计算集群的集群身份密钥中的集群身份公钥,所述链下隐私计算节点的身份私钥为所述集群身份密钥中的集群身份私钥;其中,在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中,所述集群身份密钥用于对交互数据进行加密解密和/或签名签名验证。
- 一种调用合约的方法,包括:链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述链下隐私计算节点在调用条件被满足的情况下在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 根据权利要求17所述的方法,所述链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,包括:所述链下隐私计算节点接收所述区块链节点通过所述预言机机制转发的所述调用请求,所述调用请求由所述数据使用方提交至所述区块链节点;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的所述调用请求,所述调用请求由所述数据使用方提交至所述区块链节点,并由所述区块链节点通过所述预言机机制转发至所述控制节点。
- 根据权利要求17所述的方法,所述链下隐私计算节点在以下校验操作均通过的情况下确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
- 根据权利要求19所述的方法,所述链下隐私计算节点在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;所述链下隐私计算节点在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身 份标识符相对应;所述链下隐私计算节点在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;所述链下隐私计算节点在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
- 根据权利要求20所述的方法,所述链下隐私计算节点确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符,包括:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
- 根据权利要求17所述的方法,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
- 根据权利要求22所述的方法,所述调用规则包括以下至少之一:所述链下合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述链下合约对所述目标明文数据进行处理的次数和允许调用所述链下合约对所述目标明文数据进行处理的频率。
- 根据权利要求18所述的方法,所述目标密文数据由所述数据拥有方采用所述链下合约的合约身份公钥对所述目标明文数据进行加密得到,所述链下可信执行环境内维护有对应于所述合约身份公钥的合约身份私钥,所述目标密文数据由所述链下隐私计算节点在所述链下可信执行环境内采用所述合约身份私钥进行解密。
- 根据权利要求18所述的方法,还包括:所述链下隐私计算节点在所述链下可信执行环境内采用所述链下合约的合约身份私钥对执行所述链下合约得到的执行结果进行签名;所述链下隐私计算节点通过所述预言机机制将所述执行结果反馈至区块链节点以由所述数据使用方获取,所述数据使用方在采用所述链下合约的合约身份公钥对所述执行结果进行签名验证且签名验证通过的情况下,判定所述执行结果由所述链下合约生成。
- 根据权利要求18所述的方法,在接收所述调用请求之前,所述方法还包括:链下隐私计算节点向数据使用方提供针对所述链下可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点针对所述链下可信执行环境产生的自荐信息进行验证后生成;所述链下隐私计算节点向所述数据使用方提供部署于所述链下隐私计算节点处的所述链下合约的待验证合约信息,所述待验证合约信息被所述链下隐私计算节点在所述链下可信执行环境内采用所述链下隐私计算节点的身份私钥进行签名,所述身份私钥由所述链下隐私计算节点在所述链下可信执行环境内维护;所述待验证合约信息由所述数据使用方在根据所述远程证明报告确定所述链下可信执行环境可信的情况下,采用所述链下隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述链下合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在通过区块链节点的预言机机制对所述链下合约发起调用时,所述链下合约由所述链下隐私计算节点在所述链下可信执行环境中执行。
- 根据权利要求26所述的方法,所述链下隐私计算节点向数据使用方提供针对所述链下可信执行环境的远程证明报告,包括:接收所述数据使用方向所述链下隐私计算节点发起的挑战,向所述数据使用方返回所述远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,在所述链下隐私计算集群的控制节点接收到所述数据使用方发起的挑战后,向所述控制节点发送所述远程证明报告,所述远程证明报告由所述控制节点返回至所述数据使用方。
- 根据权利要求26所述的方法,所述远程证明报告携带的所述自荐信息内包含 第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于所述数据使用方在根据所述认证服务器的公钥对所述远程证明报告进行签名验证并签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对所述链下可信执行环境的第一标准哈希值进行比较,且比较结果一致被作为所述数据使用方确认所述链下可信执行环境可信的前提条件。
- 根据权利要求26所述的方法,还包括:所述链下隐私计算节点向所述数据使用方提供第一身份信息,所述第一身份信息包含所述链下隐私计算节点的身份公钥和所述链下隐私计算节点的其他身份信息,所述第一身份信息被所述数据使用方进行哈希计算以得到第二待校验哈希值;所述链下隐私计算节点向所述数据使用方提供第二标准哈希值,所述第二标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二标准哈希值用于与所述第二待校验哈希值进行比较,且所述数据使用方在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
- 根据权利要求26所述的方法,还包括:所述链下隐私计算节点向所述数据使用方提供自身的第二身份信息,所述第二身份信息包含所述链下隐私计算节点的身份公钥、所述链下隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述链下可信执行环境的预设信息的哈希值;所述链下隐私计算节点向所述数据使用方提供第三标准哈希值,所述第三标准哈希值由所述链下隐私计算节点在所述链下可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二身份信息在所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,被所述数据使用方进行哈希计算以得到第三待校验哈希值;其中,确认所述链下可信执行环境可信的前提条件包含在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,所述第四待校验哈希值与所述数据使用方预先获得的针对所述链下可信执行环境的第四标准哈希值一致;所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
- 根据权利要求17所述的方法,所述链下可信执行环境内维护有对应于所述身份公钥的身份私钥;所述方法还包括:所述链下隐私计算节点在所述链下可信执行环境内采用所述身份私钥对所述调用请求进行解密,所述调用请求由所述数据使用方采用所述链下隐私计算节点的身份公钥进行加密。
- 根据权利要求29-31中任一所述的方法,所述链下隐私计算节点的身份私钥为所述链下隐私计算节点的节点身份密钥中的节点身份私钥,所述链下隐私计算节点的身份公钥为所述节点身份密钥中的节点身份公钥;其中,在区块链节点与所述链下隐私计算节点进行交互以部署或调用链下合约的过程中,所述节点身份密钥用于对交互数据进行加密解密和/或签名签名验证;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点的身份公钥为所述链下隐私计算集群的集群身份密钥中的集群身份公钥,所述链下隐私计算节点的身份私钥为所述集群身份密钥中的集群身份私钥;其中,在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中,所述集群身份密钥用于对交互数据进行加密解密和/或签名签名验证。
- 一种调用合约的方法,包括:数据使用方生成针对智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述数据使用方向部署有所述智能合约的隐私计算节点提交所述调用请求,所述调用请求用于指示所述隐私计算节点在调用条件被满足的情况下,在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 根据权利要求33所述的方法,在以下校验操作均通过的情况下,所述隐私计算节点确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
- 根据权利要求34所述的方法,在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
- 根据权利要求35所述的方法,通过以下方式确定出所述实际颁发方的去中心化身份标识符和所述实际颁发对象的去中心化身份标识符:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
- 根据权利要求33所述的方法,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
- 根据权利要求37所述的方法,所述调用规则包括以下至少之一:所述智能合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述智能合约对所述目标明文数据进行处理的次数和允许调用所述智能合约对所述目标明文数据进行处理的频率。
- 根据权利要求33所述的方法,在提交所述调用请求之前,所述方法还包括:所述数据使用方获取针对所述可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点针对所述可信执行环境产生的自荐信息进行验证后生成;所述数据使用方在根据所述远程证明报告确定所述可信执行环境可信的情况下,获取部署于所述隐私计算节点处的所述智能合约的待验证合约信息,所述待验证合约信息被所述隐私计算节点在所述可信执行环境内采用所述隐私计算节点的身份私钥进行签名,所述身份私钥由所述隐私计算节点在所述可信执行环境内维护;所述数据使用方采用所述隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述智能合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在对所述智能合约发起调用时,所述智能合约由所述隐私计算节点在所述可信执行环境中执行。
- 根据权利要求39所述的方法,所述数据使用方根据所述远程证明报告对所述可信执行环境进行验证,包括:根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值;将预先获得的针对所述可信执行环境的第一标准哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述可信执行环境可信的前提条件。
- 根据权利要求39所述的方法,还包括:所述数据使用方获取所述隐私计算节点提供的第一身份信息,并对获取到的第一身份信息进行哈希计算以得到第二待校验哈希值,所述第一身份信息包含所述隐私计算节点的身份公钥和所述隐私计算节点的其他身份信息;所述数据使用方获取所述隐私计算节点提供的第二标准哈希值,所述第二标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述数据使用方将所述第二待校验哈希值与所述第二标准哈希值进行比较,并在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
- 根据权利要求39所述的方法,所述数据使用方根据所述远程证明报告对所述可信执行环境进行验证,包括:根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,获取所述隐私计算节点提供的第二身份信息,并对获取到的第二身份信息进行哈希计算以得到第三待校验哈希值,所述第二身份信息包含所述隐私计算节点的身份公钥、所述隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述可信执行环境的预设信息的哈希值;获取所述隐私计算节点提供的第三标准哈希值,并将所述第三待校验哈希值与第三标准哈希值进行比较,所述第三标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,将预先获得的针对所述可信执行环境的第四标准哈希值与所述第四待检验哈希值进行比较,并将比较结果一致作为确认所述可信执行环境可信的前提条件;其中,所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
- 一种调用合约的方法,包括:隐私计算节点接收数据使用方提交的针对所述隐私计算节点部署的智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;所述隐私计算节点在调用条件被满足的情况下在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 根据权利要求43所述的方法,所述隐私计算节点在以下校验操作均通过的情况下确定出所述数据拥有方向所述数据使用方授予了所述使用权:针对所述调用请求中记录的所述数据拥有方的身份的第一真实性校验操作、针对所述调用请求中记录的所述数据使用方的身份的第二真实性校验操作、针对所述可验证声明的实际颁发方为所述数据拥有方的第三真实性校验操作,以及针对所述可验证声明的实际颁发对象为所述数据使用方的第四真实性校验操作。
- 根据权利要求44所述的方法,所述隐私计算节点在通过第一用户公钥对所述调用请求中对应于所述目标明文数据的第一签名信息进行签名验证且签名验证通过的情况下,判定所述第一真实性校验操作通过,所述第一用户公钥与所述调用请求中记录的所述数据拥有方的第一去中心化身份标识符相对应;所述隐私计算节点在通过第二用户公钥对所述调用请求中对应于所述调用请求的第二签名信息进行签名验证且签名验证通过的情况下,判定所述第二真实性校验操作通过,所述第二用户公钥与所述调用请求中记录的所述数据使用方的第二去中心化身份标识符相对应;所述隐私计算节点在所述可验证声明的实际颁发方的去中心化身份标识符与所述第一去中心化身份标识符相匹配的情况下,判定所述第三真实性校验操作通过;所述隐私计算节点在所述可验证声明的实际颁发对象的去中心化身份标识符与所述第二去中心化身份标识符相匹配的情况下,判定所述第四真实性校验操作通过。
- 根据权利要求45所述的方法,所述隐私计算节点确定出所述实际颁发方的去 中心化身份标识符和所述实际颁发对象的去中心化身份标识符,包括:读取所述调用请求中可验证声明记录的颁发方的去中心化身份标识符,并获取与读取到的去中心化身份标识符对应的第三用户公钥;采用所述第三用户公钥对所述调用请求中可验证声明记录的签名进行签名验证,并在签名验证通过的情况下将所述调用请求中可验证声明记录的颁发方的去中心化身份标识符作为所述实际颁发方的去中心化身份标识符;以及,将所述调用请求中可验证声明记录的颁发对象的去中心化身份标识符作为所述实际颁发对象的去中心化身份标识符。
- 根据权利要求43所述的方法,所述调用条件还包括所述调用请求指示的调用操作符合所述可验证声明定义的调用规则。
- 根据权利要求47所述的方法,所述调用规则包括以下至少之一:所述智能合约中允许处理所述目标明文数据的合约函数、所述目标明文数据的使用权的有效期、允许调用所述智能合约对所述目标明文数据进行处理的次数和允许调用所述智能合约对所述目标明文数据进行处理的频率。
- 根据权利要求43所述的方法,在接收所述调用请求之前,所述方法还包括:隐私计算节点向数据使用方提供针对所述可信执行环境的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点针对所述可信执行环境产生的自荐信息进行验证后生成;所述隐私计算节点向所述数据使用方提供部署于所述隐私计算节点处的所述智能合约的待验证合约信息,所述待验证合约信息被所述隐私计算节点在所述可信执行环境内采用所述隐私计算节点的身份私钥进行签名,所述身份私钥由所述隐私计算节点在所述可信执行环境内维护;所述待验证合约信息由所述数据使用方在根据所述远程证明报告确定所述可信执行环境可信的情况下,采用所述隐私计算节点的身份公钥对所述待验证合约信息进行签名验证,以及根据所述智能合约的合约信息对所述待验证合约信息进行合约信息验证,并在签名验证和合约信息验证通过的情况下,确定所述数据使用方在对所述智能合约发起调用时,所述智能合约由所述隐私计算节点在所述可信执行环境中执行。
- 根据权利要求49所述的方法,所述远程证明报告携带的所述自荐信息内包含第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于所述数据使用方在根据所述认证服务器的公钥对所述远程证明报告进行签名验证并签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,与预先获得的针对所述可信执行环境的第一标准哈希值进行比较,且比较结果一致被作为所述数据使用方确认所述可信执行环境可信的前提条件。
- 根据权利要求49所述的方法,还包括:所述隐私计算节点向所述数据使用方提供第一身份信息,所述第一身份信息包含所述隐私计算节点的身份公钥和所述隐私计算节点的其他身份信息,所述第一身份信息被所述数据使用方进行哈希计算以得到第二待校验哈希值;所述隐私计算节点向所述数据使用方提供第二标准哈希值,所述第二标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二标准哈希值用于与所述第二待校验哈希值进行比较,且所述数据使用方在比较结果一致的情况下获取所述隐私计算节点的第一身份信息中包含的所述身份公钥。
- 根据权利要求49所述的方法,还包括:所述隐私计算节点向所述数据使用方提供自身的第二身份信息,所述第二身份信息包含所述隐私计算节点的身份公钥、所述隐私计算节点的其他身份信息和第四待校验哈希值,所述第四待校验哈希值为所述可信执行环境的预设信息的哈希值;所述隐私计算节点向所述数据使用方提供第三标准哈希值,所述第三标准哈希值由所述隐私计算节点在所述可信执行环境内生成自身的身份信息后对生成的身份信息进行哈希计算得到;所述第二身份信息在所述数据使用方根据所述认证服务器的公钥对所述远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下,被所述数据使用方进行哈希计算以得到第三待校验哈希值;其中,确认 所述可信执行环境可信的前提条件包含在所述第三待校验哈希值与所述第三标准哈希值一致的情况下,所述第四待校验哈希值与所述数据使用方预先获得的针对所述可信执行环境的第四标准哈希值一致;所述第二身份信息包含的所述身份公钥用于对所述待验证合约信息进行签名验证。
- 一种调用合约的装置,包括:生成单元,使数据使用方生成针对链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;提交单元,使所述数据使用方通过区块链的预言机机制向部署有所述链下合约的链下隐私计算节点提交所述调用请求,所述调用请求用于指示所述链下隐私计算节点在调用条件被满足的情况下,在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 一种调用合约的装置,包括:接收单元,使链下隐私计算节点接收数据使用方通过区块链的预言机机制提交的针对所述链下隐私计算节点部署的链下合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;执行单元,使所述链下隐私计算节点在调用条件被满足的情况下在所述链下隐私计算节点创建的链下可信执行环境内执行所述链下合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 一种调用合约的装置,包括:生成单元,使数据使用方生成针对智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;提交单元,使所述数据使用方向部署有所述智能合约的隐私计算节点提交所述调用请求,所述调用请求用于指示所述隐私计算节点在调用条件被满足的情况下,在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 一种调用合约的装置,包括:接收单元,使隐私计算节点接收数据使用方提交的针对所述隐私计算节点部署的智能合约的调用请求,所述调用请求中包含通过对目标明文数据进行加密得到的目标密文数据和针对所述目标明文数据的使用权的可验证声明;执行单元,使所述隐私计算节点在调用条件被满足的情况下在所述隐私计算节点创建的可信执行环境内执行所述智能合约以对所述目标明文数据进行处理,所述调用条件包括根据所述可验证声明确定出所述目标明文数据的数据拥有方向所述数据使用方授予了所述使用权。
- 一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如权利要求1-52中任一项所述的方法。
- 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1-52中任一项所述方法的步骤。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010191197.7A CN111090876B (zh) | 2020-03-18 | 2020-03-18 | 调用合约的方法及装置 |
| CN202010191197.7 | 2020-03-18 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2021184963A1 true WO2021184963A1 (zh) | 2021-09-23 |
Family
ID=70400553
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/073846 Ceased WO2021184963A1 (zh) | 2020-03-18 | 2021-01-26 | 调用合约的方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (2) | CN111090876B (zh) |
| WO (1) | WO2021184963A1 (zh) |
Cited By (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113761496A (zh) * | 2021-10-21 | 2021-12-07 | 支付宝(杭州)信息技术有限公司 | 一种基于区块链的身份校验方法及装置和电子设备 |
| CN113806699A (zh) * | 2021-09-30 | 2021-12-17 | 中国人民解放军国防科技大学 | 一种云际计算环境中跨区块链身份验证方法及系统 |
| CN114301928A (zh) * | 2021-11-29 | 2022-04-08 | 之江实验室 | 一种基于sgx的链上链下混合共识方法及系统 |
| CN114357492A (zh) * | 2022-01-10 | 2022-04-15 | 天津大学 | 一种基于区块链的医疗数据隐私融合方法及装置 |
| CN114389810A (zh) * | 2022-02-25 | 2022-04-22 | 蚂蚁区块链科技(上海)有限公司 | 证明生成方法及装置、电子设备、存储介质 |
| CN114422147A (zh) * | 2022-01-26 | 2022-04-29 | 盟浪可持续数字科技(深圳)有限责任公司 | 基于区块链的多方安全计算方法 |
| CN114900534A (zh) * | 2022-03-29 | 2022-08-12 | 中南大学 | 一种基于区块链技术的大数据监管方法 |
| CN115550060A (zh) * | 2022-11-22 | 2022-12-30 | 中国信息通信研究院 | 基于区块链的可信证书验证方法、装置、设备和介质 |
| CN117473553A (zh) * | 2023-11-07 | 2024-01-30 | 云海链控股股份有限公司 | 一种隐私合规检测方法、装置、设备及可读存储介质 |
| CN117527267A (zh) * | 2024-01-08 | 2024-02-06 | 南湖实验室 | 一种基于机密计算对远程数据操控的方法及其系统 |
| CN117668823A (zh) * | 2023-11-10 | 2024-03-08 | 杭州阿里云飞天信息技术有限公司 | 基于可信执行环境的数据处理方法以及装置 |
| CN117725572A (zh) * | 2024-02-07 | 2024-03-19 | 支付宝(杭州)信息技术有限公司 | 一种sdk完整性的校验方法、装置、介质及设备 |
| CN117834303A (zh) * | 2024-03-05 | 2024-04-05 | 南开大学 | 一种面向去中心化存储的数据审计方法 |
| CN117834145A (zh) * | 2023-11-21 | 2024-04-05 | 中科迅联智慧网络科技(北京)有限公司 | 一种文件校验方法、装置、设备及介质 |
| CN118869177A (zh) * | 2024-06-24 | 2024-10-29 | 北京邮电大学 | 基于区块链的数字身份管理方法、系统、电子设备及计算机可读存储介质 |
| CN119227120A (zh) * | 2024-12-05 | 2024-12-31 | 中电科大数据研究院有限公司 | 一种基于可信空间的可信数据交换方法、装置及存储介质 |
| CN119249401A (zh) * | 2024-10-16 | 2025-01-03 | 江苏格凌维网络科技有限公司 | 基于区块链的物联网数据处理方法及系统 |
| CN119670040A (zh) * | 2024-11-29 | 2025-03-21 | 北京深盾科技股份有限公司 | 视听内容采集设备、验证端及系统 |
| CN119814766A (zh) * | 2024-12-24 | 2025-04-11 | 中移互联网有限公司 | 文件传输的方法、装置、设备、存储介质及程序产品 |
| EP4576658A1 (fr) * | 2023-12-21 | 2025-06-25 | Commissariat à l'Energie Atomique et aux Energies Alternatives | Procédé d'attestation à distance décentralisé |
| CN120541863A (zh) * | 2025-05-29 | 2025-08-26 | 内蒙古自治区教育考试院 | 基于同态加密与区块链的隐私保护方法及系统 |
| CN121030817A (zh) * | 2025-08-15 | 2025-11-28 | 国家电网有限公司华东分部 | 一种基于区块链与隐私计算的电网数据处理方法及系统 |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111090876B (zh) * | 2020-03-18 | 2020-07-17 | 支付宝(杭州)信息技术有限公司 | 调用合约的方法及装置 |
| CN111625815B (zh) * | 2020-05-26 | 2023-09-26 | 牛津(海南)区块链研究院有限公司 | 一种基于可信执行环境的数据交易方法及装置 |
| CN112612849B (zh) | 2020-07-24 | 2024-06-18 | 支付宝(杭州)信息技术有限公司 | 一种数据处理方法、装置、设备及介质 |
| CN111680305B (zh) * | 2020-07-31 | 2023-04-18 | 支付宝(杭州)信息技术有限公司 | 一种基于区块链的数据处理方法、装置及设备 |
| CN112016105B (zh) * | 2020-08-17 | 2022-04-08 | 东北大学秦皇岛分校 | 基于分布式预言机和同态加密的链上链下数据共享方法 |
| CN111770200B (zh) * | 2020-08-31 | 2020-12-08 | 支付宝(杭州)信息技术有限公司 | 一种信息共享方法和系统 |
| CN111767578B (zh) * | 2020-08-31 | 2021-06-04 | 支付宝(杭州)信息技术有限公司 | 一种数据检验方法、装置及设备 |
| CN111818186B (zh) * | 2020-08-31 | 2022-02-25 | 支付宝(杭州)信息技术有限公司 | 一种信息共享方法和系统 |
| CN111814198B (zh) * | 2020-09-11 | 2021-03-23 | 支付宝(杭州)信息技术有限公司 | 一种基于区块链的用户隐私数据提供方法及装置 |
| CN113010870B (zh) * | 2020-10-10 | 2024-07-05 | 支付宝(杭州)信息技术有限公司 | 基于数字凭证的业务处理方法、装置及设备 |
| CN113221089B (zh) * | 2021-03-15 | 2023-11-07 | 东北大学 | 基于可验证声明的隐私保护属性认证系统及方法 |
| CN113312664B (zh) * | 2021-06-01 | 2022-06-28 | 支付宝(杭州)信息技术有限公司 | 用户数据授权方法及用户数据授权系统 |
| CN113364763B (zh) * | 2021-06-02 | 2022-08-23 | 网易(杭州)网络有限公司 | 可验证声明生成方法、装置、电子设备及存储介质 |
| CN113285954B (zh) * | 2021-06-02 | 2022-12-06 | 网易(杭州)网络有限公司 | 可验证声明验证方法、系统、电子设备及存储介质 |
| CN113301163B (zh) * | 2021-06-02 | 2022-12-16 | 网易(杭州)网络有限公司 | 业务处理方法、系统、电子设备及存储介质 |
| CN113282946B (zh) * | 2021-07-20 | 2021-11-16 | 南湖实验室 | 基于高可信环境下数据访问过程的信息安全方法及系统 |
| CN113472544B (zh) * | 2021-08-31 | 2021-12-14 | 北京微芯感知科技有限公司 | 一种数字身份验证方法、装置、计算机设备和存储介质 |
| CN113779637B (zh) * | 2021-11-10 | 2022-02-22 | 腾讯科技(深圳)有限公司 | 一种属性数据处理方法、装置、设备以及介质 |
| CN114240657A (zh) * | 2021-12-15 | 2022-03-25 | 杭州趣链科技有限公司 | 数据处理方法、区块链、终端设备及存储介质 |
| US12160417B2 (en) * | 2021-12-23 | 2024-12-03 | Dell Products, L.P. | Layered workspace endorsement and verification |
| CN114301675B (zh) * | 2021-12-28 | 2024-10-01 | 杭州趣链科技有限公司 | 隐私数据交易方法、系统、计算机设备和存储介质 |
| CN114331442B (zh) * | 2022-03-07 | 2022-05-06 | 北京溪塔科技有限公司 | 一种区块链中智能合约的调用方法及装置 |
| CN114896639B (zh) * | 2022-04-29 | 2026-02-24 | 蚂蚁区块链科技(上海)有限公司 | 一种数据处理方法、装置、电子设备和存储介质 |
| CN115664668B (zh) * | 2022-09-28 | 2026-01-09 | 蚂蚁区块链科技(上海)有限公司 | 隐私数据处理方法及装置 |
| CN115297119B (zh) * | 2022-10-09 | 2023-02-03 | 江西信惠链科技有限公司 | 基于区块链和验证计算的联合征信方法及系统 |
| CN115549906B (zh) * | 2022-11-24 | 2023-04-11 | 富算科技(上海)有限公司 | 基于区块链的隐私计算方法、系统、设备和介质 |
| CN115913513B (zh) * | 2023-01-07 | 2023-05-12 | 北京邮电大学 | 支持隐私保护的分布式可信数据交易方法、系统及装置 |
| CN117997654B (zh) * | 2024-04-03 | 2024-06-07 | 湖南天河国云科技有限公司 | 边缘计算架构中的数据处理方法、装置和计算机设备 |
| WO2026004483A1 (ja) * | 2024-06-24 | 2026-01-02 | 株式会社デンソー | 車両側装置、ユーザ端末、及びデータ保証方法 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109886687A (zh) * | 2019-02-28 | 2019-06-14 | 矩阵元技术(深圳)有限公司 | 一种基于区块链实现安全多方计算的结果验证方法及系统 |
| CN110096551A (zh) * | 2019-04-23 | 2019-08-06 | 浙江泰链科技有限公司 | 基于区块链的信用数据存储方法、装置、设备及介质 |
| CN110457875A (zh) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | 基于区块链的数据授权方法及装置 |
| CN110520884A (zh) * | 2018-12-13 | 2019-11-29 | 阿里巴巴集团控股有限公司 | 基于可信执行环境的链外智能合约服务 |
| CN111090876A (zh) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | 调用合约的方法及装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10554634B2 (en) * | 2017-08-18 | 2020-02-04 | Intel Corporation | Techniques for shared private data objects in a trusted execution environment |
| CN109670335A (zh) * | 2018-12-20 | 2019-04-23 | 众安信息技术服务有限公司 | 用于在区块链与链外数据之间进行交互的方法及装置 |
| CN110472974A (zh) * | 2019-07-16 | 2019-11-19 | 阿里巴巴集团控股有限公司 | 基于区块链智能合约的资产转移方法、装置及系统 |
| CN110458677A (zh) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | 基于区块链的票据核销方法及装置、电子设备、存储介质 |
| CN110473096A (zh) * | 2019-07-31 | 2019-11-19 | 阿里巴巴集团控股有限公司 | 基于智能合约的数据授权方法及装置 |
| CN110888630B (zh) * | 2019-11-08 | 2023-05-26 | 杭州趣链科技有限公司 | 一种基于区块链的分布式可编程业务研发系统 |
| CN111523110B (zh) * | 2019-11-08 | 2023-05-02 | 支付宝(杭州)信息技术有限公司 | 基于链代码的权限查询配置方法及装置 |
-
2020
- 2020-03-18 CN CN202010191197.7A patent/CN111090876B/zh active Active
- 2020-03-18 CN CN202010879207.6A patent/CN111898153B/zh active Active
-
2021
- 2021-01-26 WO PCT/CN2021/073846 patent/WO2021184963A1/zh not_active Ceased
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110520884A (zh) * | 2018-12-13 | 2019-11-29 | 阿里巴巴集团控股有限公司 | 基于可信执行环境的链外智能合约服务 |
| CN109886687A (zh) * | 2019-02-28 | 2019-06-14 | 矩阵元技术(深圳)有限公司 | 一种基于区块链实现安全多方计算的结果验证方法及系统 |
| CN110096551A (zh) * | 2019-04-23 | 2019-08-06 | 浙江泰链科技有限公司 | 基于区块链的信用数据存储方法、装置、设备及介质 |
| CN110457875A (zh) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | 基于区块链的数据授权方法及装置 |
| CN111090876A (zh) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | 调用合约的方法及装置 |
Cited By (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113806699A (zh) * | 2021-09-30 | 2021-12-17 | 中国人民解放军国防科技大学 | 一种云际计算环境中跨区块链身份验证方法及系统 |
| CN113806699B (zh) * | 2021-09-30 | 2023-12-01 | 中国人民解放军国防科技大学 | 一种云际计算环境中跨区块链身份验证方法及系统 |
| CN113761496A (zh) * | 2021-10-21 | 2021-12-07 | 支付宝(杭州)信息技术有限公司 | 一种基于区块链的身份校验方法及装置和电子设备 |
| CN113761496B (zh) * | 2021-10-21 | 2024-04-09 | 支付宝(杭州)信息技术有限公司 | 一种基于区块链的身份校验方法及装置和电子设备 |
| CN114301928A (zh) * | 2021-11-29 | 2022-04-08 | 之江实验室 | 一种基于sgx的链上链下混合共识方法及系统 |
| CN114357492A (zh) * | 2022-01-10 | 2022-04-15 | 天津大学 | 一种基于区块链的医疗数据隐私融合方法及装置 |
| CN114422147A (zh) * | 2022-01-26 | 2022-04-29 | 盟浪可持续数字科技(深圳)有限责任公司 | 基于区块链的多方安全计算方法 |
| CN114422147B (zh) * | 2022-01-26 | 2022-09-23 | 盟浪可持续数字科技(深圳)有限责任公司 | 基于区块链的多方安全计算方法 |
| CN114389810A (zh) * | 2022-02-25 | 2022-04-22 | 蚂蚁区块链科技(上海)有限公司 | 证明生成方法及装置、电子设备、存储介质 |
| CN114900534A (zh) * | 2022-03-29 | 2022-08-12 | 中南大学 | 一种基于区块链技术的大数据监管方法 |
| CN114900534B (zh) * | 2022-03-29 | 2023-04-07 | 中南大学 | 一种基于区块链技术的大数据监管方法 |
| CN115550060A (zh) * | 2022-11-22 | 2022-12-30 | 中国信息通信研究院 | 基于区块链的可信证书验证方法、装置、设备和介质 |
| CN117473553A (zh) * | 2023-11-07 | 2024-01-30 | 云海链控股股份有限公司 | 一种隐私合规检测方法、装置、设备及可读存储介质 |
| CN117668823A (zh) * | 2023-11-10 | 2024-03-08 | 杭州阿里云飞天信息技术有限公司 | 基于可信执行环境的数据处理方法以及装置 |
| CN117834145A (zh) * | 2023-11-21 | 2024-04-05 | 中科迅联智慧网络科技(北京)有限公司 | 一种文件校验方法、装置、设备及介质 |
| FR3157593A1 (fr) * | 2023-12-21 | 2025-06-27 | Commissariat à l'Energie Atomique et aux Energies Alternatives | Procédé d’attestation à distance décentralisé |
| EP4576658A1 (fr) * | 2023-12-21 | 2025-06-25 | Commissariat à l'Energie Atomique et aux Energies Alternatives | Procédé d'attestation à distance décentralisé |
| CN117527267A (zh) * | 2024-01-08 | 2024-02-06 | 南湖实验室 | 一种基于机密计算对远程数据操控的方法及其系统 |
| CN117527267B (zh) * | 2024-01-08 | 2024-04-19 | 南湖实验室 | 一种基于机密计算对远程数据操控的方法及其系统 |
| CN117725572A (zh) * | 2024-02-07 | 2024-03-19 | 支付宝(杭州)信息技术有限公司 | 一种sdk完整性的校验方法、装置、介质及设备 |
| CN117834303B (zh) * | 2024-03-05 | 2024-05-28 | 南开大学 | 一种面向去中心化存储的数据审计方法 |
| CN117834303A (zh) * | 2024-03-05 | 2024-04-05 | 南开大学 | 一种面向去中心化存储的数据审计方法 |
| CN118869177A (zh) * | 2024-06-24 | 2024-10-29 | 北京邮电大学 | 基于区块链的数字身份管理方法、系统、电子设备及计算机可读存储介质 |
| CN119249401A (zh) * | 2024-10-16 | 2025-01-03 | 江苏格凌维网络科技有限公司 | 基于区块链的物联网数据处理方法及系统 |
| CN119670040A (zh) * | 2024-11-29 | 2025-03-21 | 北京深盾科技股份有限公司 | 视听内容采集设备、验证端及系统 |
| CN119227120A (zh) * | 2024-12-05 | 2024-12-31 | 中电科大数据研究院有限公司 | 一种基于可信空间的可信数据交换方法、装置及存储介质 |
| CN119814766A (zh) * | 2024-12-24 | 2025-04-11 | 中移互联网有限公司 | 文件传输的方法、装置、设备、存储介质及程序产品 |
| CN120541863A (zh) * | 2025-05-29 | 2025-08-26 | 内蒙古自治区教育考试院 | 基于同态加密与区块链的隐私保护方法及系统 |
| CN121030817A (zh) * | 2025-08-15 | 2025-11-28 | 国家电网有限公司华东分部 | 一种基于区块链与隐私计算的电网数据处理方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111898153B (zh) | 2024-05-03 |
| CN111090876B (zh) | 2020-07-17 |
| CN111090876A (zh) | 2020-05-01 |
| CN111898153A (zh) | 2020-11-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111090876B (zh) | 调用合约的方法及装置 | |
| CN111092727B (zh) | 共享集群密钥的方法及装置 | |
| CN111092726B (zh) | 生成共享合约密钥的方法及装置 | |
| CN111090888B (zh) | 验证合约的方法及装置 | |
| CN110580413B (zh) | 基于链下授权的隐私数据查询方法及装置 | |
| CN111523110B (zh) | 基于链代码的权限查询配置方法及装置 | |
| WO2021184970A1 (zh) | 调用合约的方法及装置 | |
| WO2021184973A1 (zh) | 访问外部数据的方法及装置 | |
| WO2021184961A1 (zh) | 部署合约的方法及装置 | |
| WO2021088546A1 (zh) | 基于区块链账户的隐私数据查询方法及装置 | |
| CN111475829A (zh) | 基于区块链账户的隐私数据查询方法及装置 | |
| WO2021088548A1 (zh) | 基于智能合约的隐私数据查询方法及装置 | |
| WO2021088535A1 (zh) | 基于智能合约的隐私数据查询方法及装置 | |
| CN110580245A (zh) | 隐私数据的共享方法及装置 | |
| WO2020233631A1 (zh) | 基于交易类型的收据存储方法和节点 | |
| WO2021088543A1 (zh) | 基于智能合约的权限查询配置方法及装置 | |
| HK40039813B (zh) | 调用合约的方法及装置 | |
| HK40029290A (zh) | 调用合约的方法及装置 | |
| HK40029290B (zh) | 调用合约的方法及装置 | |
| HK40039813A (zh) | 调用合约的方法及装置 | |
| HK40035754A (zh) | 基於链代码的权限查询配置方法及装置 | |
| HK40019385B (zh) | 基於链代码的权限查询配置方法及装置 | |
| HK40019385A (zh) | 基於链代码的权限查询配置方法及装置 | |
| HK40043789B (zh) | 生成共享合约密钥的方法及装置 | |
| HK40034491A (zh) | 基於链下授权的隐私数据查询方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21772160 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 21772160 Country of ref document: EP Kind code of ref document: A1 |