CN111475850B

CN111475850B - Intelligent contract-based privacy data query method and device

Info

Publication number: CN111475850B
Application number: CN202010456590.4A
Authority: CN
Inventors: 刘琦; 闫莺; 宋旭阳
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-11-08
Filing date: 2019-11-08
Publication date: 2024-03-26
Anticipated expiration: 2039-11-08
Also published as: CN110580417B; CN111475850A; CN110580417A; WO2021088535A1

Abstract

One or more embodiments of the present disclosure provide a method and apparatus for querying private data based on an intelligent contract; the method is applied to the blockchain node and can comprise the following steps: when a query transaction for target privacy data initiated by a query party is received, reading a transaction identifier of a historical transaction related to the target privacy data and a contract address of a business contract called by the historical transaction, which are contained in the query transaction; acquiring the business contract according to the contract address, and executing a right control code defined in the business contract to determine the query right of the querying party for the target privacy data; and when the determined query permission is permission for query, acquiring the target privacy data, and reading the acquired target privacy data into a trusted execution environment for decryption so as to be acquired by the querying party.

Description

Intelligent contract-based privacy data query method and device

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and apparatus for querying private data based on an intelligent contract.

Background

Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Network nodes in the transport network utilize the chained data structures to validate and store data and employ distributed node consensus algorithms to generate and update data.

The biggest two challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade off performance for privacy, or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems have high complexity such as homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledgeproof), have poor generality, and may also bring about serious performance loss.

Trusted execution environments (Trusted Execution Environment, TEE) are another way to address privacy concerns. The TEE can function as a black box in hardware, and code and data operating system layers executed in the TEE cannot be peeped, and only a predefined interface in the code can operate the code. In terms of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptographic operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety and privacy of the blockchain can be improved to a great extent on the premise of less performance loss by combining with the TEE. The current industry is concerned with TEE solutions, where almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module ) on software and Intel SGX (Software Guard Extensions, software protection extension), ARM trust zone (trust zone) and AMD PSP (Platform Security Processor ) on hardware.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and apparatus for querying private data based on smart contracts.

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

according to a first aspect of one or more embodiments of the present disclosure, a method for querying private data based on an intelligent contract is provided, which is applied to a blockchain node; the method comprises the following steps:

when a query transaction for target privacy data initiated by a query party is received, reading a transaction identifier of a historical transaction related to the target privacy data and a contract address of a business contract called by the historical transaction, which are contained in the query transaction;

acquiring the business contract according to the contract address, and executing a right control code defined in the business contract to determine the query right of the querying party for the target privacy data;

and when the determined query permission is permission for query, acquiring the target privacy data, and reading the acquired target privacy data into a trusted execution environment for decryption so as to be acquired by the querying party.

According to a second aspect of one or more embodiments of the present specification, a privacy data query device based on an intelligent contract is provided, which is applied to a blockchain node; the device comprises:

A transaction reading unit, when receiving a query transaction for target privacy data initiated by a query party, reading a transaction identifier of a historical transaction related to the target privacy data and a contract address of a business contract called by the historical transaction, which are contained in the query transaction;

the permission query unit acquires the business contract according to the contract address and executes permission control codes defined in the business contract to determine the query permission of the query party for the target privacy data;

and the data acquisition unit acquires the target privacy data and reads the acquired target privacy data into a trusted execution environment for decryption when the determined query permission is the permission of query, so as to acquire the target privacy data by the query party.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the smart contract-based private data query method as described in any of the embodiments above by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, there is provided a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as in any of the embodiments described above.

Drawings

FIG. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a call to a smart contract provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of a call service contract provided by an exemplary embodiment.

Fig. 4 is a flowchart of a method for querying private data based on smart contracts, in accordance with an exemplary embodiment.

Fig. 5 is a flow chart of another method for intelligent contract-based private data query provided in an exemplary embodiment.

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

Fig. 7 is a block diagram of a smart contract-based private data query device, as provided by an exemplary embodiment.

Detailed Description

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

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. Participants joining the public chain may read data records on the chain, participate in transactions, compete for billing rights for new blocks, and so forth. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or federation, it is possible to provide the functionality of a smart contract. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, support users create and invoke some complex logic in the ethernet network, which is the biggest challenge for ethernet to distinguish from the bitcoin blockchain technology. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, bob sends a transaction containing information to create a smart contract to the ethernet network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. "0x6f8ae93 …" in fig. 1 represents the address of this contract, the data field of the transaction may hold byte code, and the to field of the transaction is empty. After agreement is reached between nodes through the consensus mechanism, this contract is successfully created and can be invoked in a subsequent process. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain, and the contract account is stored with a specific address. The behavior of the smart contract is controlled by the contract code. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage).

Still taking the ethernet as an example, as shown in fig. 2, bob sends a transaction for invoking a smart contract to the ethernet network, the EVM of a node may execute the transaction and generate the corresponding contract instance. In fig. 2, the from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the "0x6f8ae93 …" in the to field represents the address of the called smart contract, the value field is the value of the ethernet in the ethernet, and the data field of the transaction holds the method and parameters for calling the smart contract. The intelligent contract is independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

After executing the Bob-initiated transaction, the nodes in the blockchain network generate corresponding receipt (receipt) data for recording receipt information related to the transaction. In this way, information about the result of execution of the transaction can be obtained by querying the receipt of the transaction. Taking ethernet as an example, receipt data from a node executing a transaction may include the following:

Result field, which represents the execution Result of the transaction;

a Gas used field representing the Gas value consumed by the transaction;

the Log field represents a Log generated by the transaction, and the Log may further include a From field, a To field, a Topic field, a Log data field, and the like, wherein the From field represents an account address of an initiator of the call, the To field represents an account address of a called object (such as an intelligent contract), the Topic field represents a subject of the Log, and the Log data field represents Log data;

output field, which indicates the Output of the transaction.

In general, receipt data generated after the transaction is executed is stored in a clear text form, so that anyone can see the contents of the receipt fields contained in the receipt data, and no privacy protection setting or capability is provided. In some blockchain-TEE combined solutions, however, the entire contents of the receipt data are stored as data requiring privacy protection on the blockchain for privacy protection. The blockchain is a data set which is stored in a database of nodes and is organized by specific logic. The physical carrier of the database, as will be described later, may be a storage medium, such as a persistent storage medium. In fact, only a portion of the receipt data may be sensitive, while other content may not be sensitive, only privacy protection may be required for the sensitive content, other content may be disclosed, and even in some cases retrieval of a portion of the content may be required to drive the implementation of the relevant operation, for which privacy protection would affect the implementation of the retrieval operation.

The process of protecting the privacy of the user may be as shown in fig. 3:

in step 302, user A creates a transaction that invokes a business contract and sends the created transaction to the blockchain node.

User a may invoke a smart contract (i.e., a business contract) deployed on the blockchain by creating a transaction (including the account address of the invoked smart contract) such that the blockchain link point executes the business contract to complete the corresponding business. For privacy protection, user a may encrypt the created transaction using a digital envelope encryption that combines a symmetric encryption algorithm and an asymmetric encryption algorithm. Specifically, the transaction content is encrypted by a symmetric encryption algorithm (i.e., the transaction content is encrypted by a symmetric key used by itself), and then the symmetric key is encrypted by a public key of an asymmetric encryption algorithm.

In step 304, the block link points execute the business contracts.

After receiving the encrypted transaction, the blockchain node reads the transaction into the TEE, decrypts the transaction by adopting the private key of the asymmetric encryption algorithm to obtain a symmetric key, decrypts the transaction by adopting the symmetric key obtained by decryption to obtain transaction content, and further executes the service code of the service contract in the TEE.

At step 306, the block link point stores privacy data associated with the transaction.

In one aspect, the blockchain node, upon receiving the transaction (after consensus), issues the transaction (encrypted in the form of a digital envelope) onto the blockchain for certification. On the other hand, after executing the transaction, the blockchain node also encrypts and stores the related data obtained by executing the transaction (issues the related data to the blockchain for certification or stores the related data locally); wherein the transaction receipt corresponding to the transaction may be encrypted using a symmetric key used by user a, and the contract status data resulting from execution of the business contract in response to the transaction may be encrypted using a specific symmetric key internal to the TEE. The data such as account attribute information of the user a, account attribute information of the service contract, and contract code of the service contract may be encrypted by using a specific symmetric key in the TEE. The data encrypted by the block chain link points belongs to the privacy data of the user A on the block chain.

In the privacy preserving scenario, the user may need to share the privacy data related to the service implemented by the user using the blockchain to some specific users to view, that is, the specific users may view the privacy data related to the historical transaction initiated by the user. Then, the query rights may be set for the user's privacy data for viewing by other users that are allowed to query. The following describes a scheme for querying private data in this specification in connection with fig. 4-5.

Referring to fig. 4, fig. 4 is a flowchart of a method for querying private data based on an intelligent contract according to an exemplary embodiment. As shown in fig. 4, the method applied to the blockchain node may include the steps of:

step 402, when a query transaction for target privacy data initiated by a query party is received, reading a transaction identifier of a historical transaction related to the target privacy data and a contract address of a business contract called by the historical transaction, which are contained in the query transaction.

In the present embodiment, when developing a business contract, it is necessary to define in the business contract, in addition to the business code, a rights control code of privacy data related to a transaction calling the business contract for determining whether or not a querying party for the privacy data is allowed to query. By defining the permission control codes in the business contracts, the association relation between the privacy data and the permission control codes for controlling the query permission of the privacy data can be established, so that each business contract can control the privacy data related to the transaction of calling the business contract.

The development and deployment of the business contracts may be accomplished by the roles of blockchain users, blockchain members, blockchain administrators, etc. Taking the alliance chain as an example, a blockchain member (or a blockchain user or an administrator) with accounting authority sets the authority control rule, and the authority control rule is defined in a business contract (business codes are also defined) in the form of an authority control code. After the development of the service contract is completed, the blockchain member can issue the service contract to the alliance chain through any node device in the alliance chain, and after the service contract is completed consensus by a part of designated member node devices in the alliance chain (for example, a plurality of authoritative node devices with accounting rights designated in the alliance chain), the service contract is recorded in a distributed database (namely, a distributed ledger) of the alliance chain. Based on the manner in which the business contracts are deployed, the deployment party of the business contracts (i.e., the general user or the general member with billing rights) can control whether other people are allowed to query privacy data related to transactions sent to the business contracts (i.e., transactions invoking the business contracts).

Among other things, the consensus algorithm supported in the blockchain may include:

a first type of consensus algorithm, namely a consensus algorithm that node equipment needs to contend for the accounting rights of the accounting period of each round; for example, consensus algorithms such as Proof of Work (POW), proof of stock (POS), proof of commission (Delegated Proof of Stake, DPOS);

a second type of consensus algorithm, namely a consensus algorithm which pre-elects accounting nodes (without competing for accounting rights) for each round of accounting period; for example, a consensus algorithm such as the use of Bayesian fault tolerance (Practical Byzantine Fault Tolerance, PBFT) is used.

In blockchain networks employing a first type of consensus algorithm, node devices competing for accounting rights may perform a transaction after receiving the transaction. One of the node devices competing for the accounting rights may win out of the process of competing for the accounting rights in this round, becoming an accounting node. The accounting node may package the received transaction with other transactions to generate the latest chunk and send the generated latest chunk or chunks of the latest chunk to other node devices for consensus.

In blockchain networks employing a second type of consensus algorithm, node devices with accounting rights are already well-established prior to this round of accounting. Thus, after receiving a transaction, the node device may send the transaction to the billing node if it is not itself the billing node for the current round. For the billing node of the present round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or the block head of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain as shown above, the accounting node of the round may package the received transaction to generate the latest chunk and send the generated latest chunk or chunks of the latest chunk to other node devices for consensus verification. If the other node equipment receives the latest block or the block head of the latest block, and is verified to have no problem, the latest block can be added to the end of the original blockchain, so that the accounting process of the blockchain is completed. Other nodes may also execute transactions contained in the block during the verification of the new block or block header from the accounting node.

Based on the above-described manner of deploying business contracts for controlling inquiry rights, each business contract controls only inquiry rights of private data related to a transaction that invokes itself. Therefore, when a user (as a querying party) initiates a query transaction for target privacy data related to a historical transaction (initiated by any other user), the blockchain node needs to determine a service contract for controlling the query authority of the target privacy data, and then the service contract can be invoked to realize authority control.

The manner of invoking the service contract for the block link point to implement the authority control may be that a distribution contract is deployed on the block chain in advance to identify whether the transaction received by the block link point is a query transaction, and when the received transaction is the query transaction, the corresponding service contract is further invoked to execute the authority control code (which may be understood as distributing the query transaction to the corresponding service contract). In particular, a distribution code may be defined in a distribution contract for invoking a business contract to execute rights control code defined in the business contract. Thus, a query transaction created by a querying party is a transaction for invoking a distribution contract; at the same time, the inquiry transaction can record the contract address of the business contract called by the historical transaction. Then, when any transaction received by the blockchain node is used to invoke a distribution contract, the any transaction may be used as a query transaction, and the distribution contract may be invoked to execute the distribution code defined in the distribution contract, to further invoke a corresponding business contract (i.e., the business contract invoked by the historical transaction) to execute the entitlement control code according to the contract address included in the query transaction. Taking the ethernet as an example, the content of the to field in the query transaction created by the query party is the contract address of the distributed contract, and the content of the to field in the historical transaction, namely the contract address of the business contract called by the historical transaction, is recorded in the query transaction.

Based on the distribution contract functioning as a "distribution query transaction," the distribution contract may be designed as a system-level intelligent contract. Thus, development and deployment of the distribution contract may be accomplished by an administrator of the blockchain. Also taking the federation chain as an example, the distribution logic (the contract address of the business contract called according to the history transaction recorded in the inquiry transaction is called) is developed by an administrator having management authority, and the distribution logic is defined in the distribution contract in the form of a distribution code. Upon completion of development of the distribution contract, the administrator may issue the distribution contract onto a federation chain for deployment (similar to the process of deploying the smart contract described above).

Wherein in one instance, the distribution contract may be deployed through an origin block of the blockchain, i.e., the distribution contract is deployed at the time of building the blockchain, and the contract code of the distribution contract is recorded in the origin block. In another case, the distribution contract may be deployed in a subsequent process of building a blockchain; for example, an administrator may want to add rights inquiry functionality during subsequent use. Then the administrator may initiate a transaction to create a distribution contract to deploy the distribution contract onto the blockchain. Wherein the to field of the transaction is an empty string, and the binary code of the initialization contract is specified in the data field, and the execution result of the code is taken as the contract code when the contract is called later.

In the technical scheme of the specification, besides the method for calling the service contract by deploying the distribution contract to realize the authority control, the distribution logic can be solidified into the chain code in the form of the distribution code and issued along with the chain code, so that subsequent redeployment by an administrator is not needed, and the contract code is solidified in the chain code, so that the contract code is controllable, and the safety is effectively improved. In other words, the distribution of the query transaction to the corresponding business contracts is accomplished by the block link points themselves, without the need to do so by invoking the intelligent contracts.

It should be noted that, the type of the request initiated by the user accessing the blockchain on the blockchain may specifically refer to a transaction (transaction) adopted in a conventional blockchain. Of course, the type of request initiated by the user accessing the blockchain on the blockchain may be, in particular, other types of instructions, messages, etc. having a standard data structure besides transactions, and one or more embodiments of the present disclosure are not particularly limited. In the following embodiments, a request initiated by a user accessing a blockchain on the blockchain will be described as an example of a transaction.

And step 404, acquiring the business contract according to the contract address, and executing the authority control code defined in the business contract to determine the inquiring authority of the inquirer for the target privacy data.

In this embodiment, the authority control rule defined in the form of the authority control code in the service contract may be flexibly set according to the actual requirement; of course, the specification of one or more embodiments is not limited by the specific content of the entitlement control rules. In one case, the identity information of the inquirer can be used as the basis for authority control. Accordingly, the querying party should include the identity information of the querying party in the query transaction when creating the query transaction. For example, the identity information of the querying party is the querying party's account ID (i.e., account address), which may be recorded in the from field of the query transaction. Further, the permission control rule may be set to allow the inquirer to inquire the corresponding privacy data when the identity information of the inquirer meets a specific condition. For example, when a querying party belongs to a pre-designated set of querying users, the querying authority of the querying party may be determined to be allowed for querying, or when the credit score of the querying party exceeds a preset credit threshold, the querying authority of the querying party may be determined to be allowed for querying, and so on. Thus, in determining the querying rights of the querying party, the rights control code defined in the business contract may be executed to determine the querying rights of the querying party to the target privacy data based on the identity information of the querying party.

In another case, the identity information of the querying party and the identity information of the initiator of the historical transaction can be taken as the basis of authority control, and correspondingly, the querying party also contains the identity information of the initiator of the historical transaction when creating the query transaction. Then, the rights control rule may be set to allow the inquirer to inquire the corresponding privacy data when the identity information of the inquirer and the identity information of the initiator meet a specific condition. For example, the inquiry group and the inquired group are recorded in the authority control rule, and the members belonging to the inquiry group are allowed to view the privacy data of the inquired group members; or, the authority control rule directly records the corresponding relation of other users which can be checked by each user; or when the inquirer and the initiator belong to the same team, the inquirer's inquiry authority can be determined to be permission inquiry and the like. Thus, in determining the querying rights of the querying party, the rights control code defined in the business contract may be executed to determine the querying rights of the querying party to the target privacy data based on the identity information of the querying party and the identity information of the initiating party.

In yet another case, the identity information of the initiator of the historical transaction may be used as the basis for authority control, and accordingly, when the inquiring party creates the inquiry transaction, the inquiry transaction should include the identity information of the initiator of the historical transaction. Then, the rights control rule may be set to allow the inquirer to inquire about the corresponding privacy data when the identity information of the originator meets a specific condition. For example, the querying authority of the querying party may be determined to be allowed for querying when the initiating party belongs to a predesignated set of queriable users, or may be determined to be allowed for querying when the credit score of the initiating party exceeds a preset credit threshold, and so on. Thus, in determining the querying rights of the querying party, the rights control code defined in the business contract may be executed to determine the querying rights of the querying party to the target private data based on the identity information of the initiating party.

When the basis of the rights control includes the identity information of the initiator of the historical transaction, since the identity information of the initiator included in the inquiry transaction is only the identity information declared by the inquirer, the identity information is not necessarily the actual identity information of the initiator of the historical transaction, i.e. there is a risk that the inquirer falsifies the identity information of the initiator. Therefore, after determining that the querying authority of the querying party is allowed to query, the blockchain node may acquire the historical transaction according to the transaction identifier (i.e., the transaction ID, typically the hash value of the transaction) of the historical transaction included in the query transaction, so as to determine the identity information of the initiator of the historical transaction (i.e., the actual identity information of the initiator) according to the acquired historical transaction. When the determined identity information is inconsistent with the identity information of the initiator contained in the inquiry transaction, the operation of acquiring the target privacy data is forbidden, so that the condition that the inquirer steals the user privacy data by forging the identity information of the initiator can be effectively eliminated.

Similarly, the inquiry transaction is created by the inquirer, the contract address of the business contract called by the history transaction contained in the inquiry transaction is stated by the inquirer, and then the contract address is not necessarily the contract address of the business contract actually called by the history transaction, that is, there is a risk that the inquirer falsifies the contract address. Therefore, after determining that the querying authority of the querying party is allowed to query, the blockchain node may acquire the historical transaction according to the transaction identifier (i.e. the transaction ID, typically the hash value of the transaction) of the historical transaction included in the query transaction, so as to determine the contract address of the service contract actually invoked by the historical transaction according to the acquired historical transaction. When the determined contract address is inconsistent with the contract address of the business contract called by the historical transaction contained in the inquiry transaction, the operation of acquiring the target privacy data is forbidden, so that the condition that the inquirer steals the user privacy data by forging the contract address can be effectively eliminated.

Taking the ethernet as an example, the hash value of the historical transaction (as a transaction identifier), the contract address of the business contract called by the historical transaction (i.e. the to field content of the historical transaction), the identity information of the initiator of the historical transaction (i.e. the from field content of the historical transaction) and other data can be recorded in the data (also written as input) field of the query transaction, after determining that the query authority of the query party is allowed to be queried, the blockchain node can acquire the historical transaction (stored on the blockchain) from the blockchain according to the hash value of the historical transaction, and read out the content recorded in the from field of the historical transaction and the to field content of the historical transaction, and if the read-out from field content is the same as the from field content stated in the query transaction, the operation of acquiring the target privacy data can be further executed; otherwise, the operation of acquiring the target privacy data is prohibited. Similarly, if the read to field content is the same as the to field content declared in the inquiry transaction, the operation of acquiring the target privacy data can be further executed; otherwise, the operation of acquiring the target privacy data is prohibited.

And step 406, when the determined query authority is allowed to query, acquiring the target privacy data, and reading the acquired target privacy data into a trusted execution environment for decryption so as to be acquired by the querying party.

In the present embodiment, the privacy data is stored encrypted for the protection of the user privacy data described above. Thus, when it is determined that the querying authority of the querying party is allowed to query, the target privacy data may be acquired and read into the trusted execution environment for decryption (e.g., the target privacy data is acquired according to the transaction identifier) to be acquired by the querying party. The decryption scheme used is different (because the encryption scheme is different) depending on the type of data included in the target private data.

When the target privacy data includes historical transactions and/or transaction receipts for the historical transactions, as can be seen from the embodiment of FIG. 3 described above, both the historical transactions and the transaction receipts for the historical transactions are encrypted with a symmetric key used by the initiator of the historical transactions. Thus, after obtaining the historical transaction and/or the transaction receipt of the historical transaction, the symmetric key used by the initiator (user a in the embodiment shown in fig. 3) may be obtained first, and then the historical transaction and/or the transaction receipt of the historical transaction may be decrypted within the TEE by the symmetric key. For the acquisition of the symmetric key used by the initiator, the symmetric key used for encrypting the historical transaction (the symmetric key is encrypted by the public key used by the initiator, that is, the mode of encrypting by using a digital envelope in the embodiment shown in fig. 3 described above) may be acquired first, and the symmetric key is decrypted in the TEE by the private key corresponding to the public key used by the initiator to obtain the decrypted symmetric key.

The symmetric key used by the initiator can be generated by the initiator through a symmetric encryption algorithm, or obtained by negotiation between the initiator and the blockchain node, or transmitted by a key management server. For the symmetric encryption algorithm, for example, DES algorithm, 3DES algorithm, TDEA algorithm, blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. may be mentioned. The public key used by the initiator is sent to the initiator by the key management server through remote attestation, the TEE of the blockchain node is established by the SGX architecture, and the private key corresponding to the public key is sent to an enclosure (also referred to as enclave) of the blockchain node by the key management server through remote attestation. While the asymmetric encryption algorithm used to generate the public and private keys may be, for example, RSA, elgamal, knapsack algorithm, rabin, D-H, ECC (elliptic curve cryptography algorithm), etc.

When the target privacy data includes at least one of account attribute information of an initiator of the historical transaction, account attribute information of the service contract, contract code of the service contract, and contract status data of the service contract, as known from the embodiment shown in fig. 3, the privacy data is encrypted by using a specific symmetric key inside the TEE. Thus, after the private data is obtained, the private data may be decrypted within the TEE by the blockchain node's specific symmetric key. For a specific symmetric key in the TEE, the SGX architecture of the blockchain node is sent by the key management server after passing the remote certification, or is obtained by negotiating between the blockchain node and other blockchain nodes.

In this embodiment, similar to the above-described manner of encrypting the historical transaction to protect privacy, the querying party may also encrypt the created query transaction using its own symmetric key and encrypt the symmetric key using its own public key when initiating the query transaction. Therefore, after receiving the inquiry transaction, the blockchain node decrypts the symmetric key of the encrypted inquiry transaction in the TEE through the private key corresponding to the public key used by the inquirer, and decrypts the inquiry transaction through the symmetric key obtained through decryption so as to obtain the transaction content contained in the inquiry transaction. After the target privacy data is obtained and decrypted, the blockchain node can encrypt the decrypted target privacy data through the symmetric key of the inquirer, so that the inquirer can decrypt and check the target privacy data through the symmetric key used by the inquirer, and the target privacy data is prevented from being revealed.

The sources of the symmetric key, the public key and the private key used for privacy protection for the querying party are similar to those described above, and are not described here again. Of course, the asymmetric keys (public and private keys) used in this process may be those used for privacy protection for the initiator as described above.

In this embodiment, when it is determined that the query authority of the querying party is prohibited from querying, the step of verifying the identity information of the initiating party or verifying the contract address of the business contract by acquiring the history transaction is not required to be performed. Under the condition that the query authority of the query party is query prohibition, the checking step is unnecessary operation, so that occupation of processing resources of the block chain link point can be reduced, and the performance of the block chain node is improved. Meanwhile, when it is determined that the querying authority of the querying party is query prohibition, a contract receipt indicating that the querying party prohibits querying the target privacy data may be generated to be viewed by the querying party.

For ease of understanding, the process of the querying party viewing the target privacy data is illustrated below in connection with FIG. 5.

As shown in fig. 5, when the user a initiates a transaction for invoking a business contract, the user a may share the privacy data related to the transaction (as a history transaction in the scenario) with the user B, or the user B may have a need to view the privacy data. Then, the process of querying the target privacy data by the user B as the querying party may include the following steps:

at step 502, user B creates a query transaction through the client used.

In this embodiment, the to field of the query transaction records the contract address of the distribution contract, and the hash value of the history transaction (i.e., the transaction ID), the content of the from field (the address of the initiator of the history transaction), and the content of the to field (the contract address of the business contract called by the history transaction) may also be recorded in the data field (or other field) of the query transaction. The hash value of the historical transaction, the address of the initiator and the contract address of the business contract can be obtained by an offline sharing mode between the user B and the user A or can be obtained by any other mode.

At step 504, user B queries the transaction via the client using digital envelope encryption.

In step 506, user B initiates a query transaction with the block link point via the client.

At step 508, the blockchain node decrypts the query transaction within the TEE.

TEE is a trusted execution environment based on a secure extension of CPU hardware and completely isolated from the outside. TEE was originally proposed by Global Platform for resolving secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications in parallel to the operating system. The ARM Trust Zone technology has at the earliest realized the true commercial TEE technology. Along with the high-speed development of the internet, the requirements for security are higher and higher, and the requirements for the TEE are more provided for mobile equipment, cloud equipment and data centers. The TEE concept has also been developed and expanded at a high rate. The TEE now has been a more generalized TEE than the originally proposed concept. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEEs and enriched the concepts and characteristics of TEEs, which have been widely accepted in the industry. The TEE now lifted is often more directed to such hardware assisted TEE technology. Unlike the mobile terminal, the cloud access needs remote access, and the terminal user is invisible to the hardware platform, so that the first step of using the TEE is to confirm the true credibility of the TEE. Therefore, the existing TEE technology introduces a remote attestation mechanism, and a hardware manufacturer (mainly a CPU manufacturer) endorses and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, the security requirement which cannot be met by only secure resource isolation is met, and further data privacy protection is also proposed. Commercial TEEs, including Intel SGX, AMD SEV, also provide memory encryption techniques that limit trusted hardware to the CPU, and the data on the bus and memory are ciphertext to prevent malicious users from snooping. TEE technology, such as intel's software protection extension (SGX), isolates code execution, remote attestation, security configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.

Taking Intel SGX technology as an example, SGX provides an enclosure, i.e., an encrypted trusted execution area in memory, that is protected from theft by the CPU. Taking the block link point as an example, a CPU supporting SGX is adopted, and with a newly added processor instruction, a part of region EPC (Enclave Page Cache, enclosure page cache or enclave page cache) can be allocated in the memory, and the data in the region EPC is encrypted by an encryption engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Thus, in SGX, a user may not trust the operating system, VMM (Virtual Machine Monitor ), or even BIOS (Basic Input Output System, basic input output System), but only trust the CPU to ensure that private data does not leak.

In practical applications, the keys of the asymmetric encryption algorithm may be generated by a key management server. By way of remote attestation, the key management server sends the private key to the blockchain node, which may specifically be in the enclosure of the incoming blockchain node. The blockchain node may include a plurality of enclosures, and the private key may be passed into a security enclosure of the enclosures; for example, the safety enclosure may be a QE (Quoting Enclave) enclosure instead of a AE (Application Enclave) enclosure. For asymmetric encrypted public keys, the key management server may send to the user's client. Then the client may encrypt the created transaction using a symmetric encryption algorithm, i.e., encrypt the transaction content using the symmetric key of the symmetric encryption algorithm, and encrypt the symmetric key employed in the symmetric encryption algorithm using an asymmetric encryption algorithm. In general, a public key of an asymmetric encryption algorithm is used to encrypt a symmetric key used in the symmetric encryption algorithm. The encryption mode is called digital envelope encryption, and after the block chain link point receives the encrypted transaction, the private key of the asymmetric encryption algorithm can be adopted to decrypt the encrypted transaction to obtain the symmetric key of the symmetric encryption algorithm, and then the symmetric key of the symmetric encryption algorithm is used to decrypt the transaction content.

At step 510, the blockchain node determines that the received transaction is a query transaction that invokes a distribution contract.

In this embodiment, the blockchain node reads the to field content of any transaction after receiving the transaction. When the to field content is the contract address of the distribution contract, indicating that the transaction is for invoking the distribution contract, then the transaction may be determined to be a query transaction.

At step 512, the block link point invokes the distribution contract.

In step 514, the distribution contract determines the business contract invoked by the historical transaction based on the to field of the historical transaction recorded in the query transaction.

In step 516, the distribution contract invokes the business contract.

In step 518, the business contract determines the query authority of user B based on the from field of the query transaction and the from field of the historical transaction.

In this embodiment, the identity information of the querying party and the initiator of the historical transaction are taken as the basis of authority control. For example, the rights control rule (defined in the form of a rights control code in a business contract) records a query group and a queried group, and members belonging to the query group allow viewing of private data of the queried group members; or, the corresponding relation of other users which can be checked by each user is directly recorded in the authority control rule. Wherein, the account address is used as the identity information of the user. Then, the blockchain node executes the authority control code defined in the business contract to determine the query authority of the user B based on the account address of the querying party (from field content of the query transaction) and the account address of the initiator of the history transaction (from field content of the history transaction).

In step 520, the service contract returns the query authority of user B to the blockchain node.

In step 522, after determining that the query authority of the user B is allowed to be queried, the block link point verifies the from field and the to field of the historical transaction.

In this embodiment, the address of the initiator and the contract address of the business contract recorded in the inquiry transaction are filled in by the user B, so that the address of the initiator is understood as the address of the initiator of the history transaction declared by the user B, and the contract address is understood as the contract address of the business contract called by the history transaction declared by the user B. However, the address of the actual initiator of the historical transaction is not necessarily the address of the initiator declared by the user B, and the contract address of the service contract actually invoked by the historical transaction is not necessarily the contract address declared by the user B, i.e. there is a possibility of falsification by the user B. For example, user B may deploy a business contract on the blockchain by deploying the business contract described above, the entitlement control code defined in the business contract allowing user B to view user a's private data; then, the user B may fill in the contract address of the business contract called by the history transaction initiated by the user a as the contract address of the above business contract deployed by the user B in the inquiry transaction. Therefore, under the condition that the query authority of the user B is determined to be the permission query, the blockchain node can further check the address and the contract address of the initiator of the historical transaction declared by the user B, so that the security of the private data is ensured.

For example, after determining that the query authority of the user B is allowed to be queried, the blockchain node may acquire a historical transaction (stored in the blockchain) from the blockchain according to a hash value of the historical transaction, and read out a content of a from field record of the historical transaction and a to field content of the historical transaction, and if the read-out from field content is the same as a from field content declared in the query transaction, may further execute an operation of acquiring the target privacy data; otherwise, the operation of acquiring the target privacy data is prohibited. Similarly, if the read to field content is the same as the to field content declared in the inquiry transaction, the operation of acquiring the target privacy data can be further executed; otherwise, the operation of acquiring the target privacy data is prohibited.

It should be noted that, when it is determined that the query authority of the querying party is query prohibition, the above verification step is an unnecessary operation, so that the step of performing the above verification is not needed, thereby reducing occupation of processing resources on the block link point, and further improving performance of the block chain node.

Further, after determining that the query authority of the user B is query prohibition by using the service contract, a contract receipt about the target privacy data of the query prohibition of the user B may be generated for the user B to view. Or, the blockchain node returns a receipt of the prohibited query to the user B to inform the user B that the query authority is the prohibited query.

In step 524, the blockchain node obtains the target privacy data.

In step 526, the block link reads the target privacy data into the TEE for decryption.

In this embodiment, as can be seen from the embodiment shown in fig. 3, the private data is stored in an encrypted manner for the purpose of privacy protection. Meanwhile, the encryption mode adopted is different according to the different data types contained in the private data. Thus, after the target privacy data is acquired (e.g., the target privacy data is acquired according to the hash value of the historical transaction), the acquired target privacy data is read into the trusted execution environment for decryption to be acquired by the querying party.

When the target privacy data includes historical transactions and/or transaction receipts for the historical transactions, as can be seen from the embodiment of FIG. 3 described above, both the historical transactions and the transaction receipts for the historical transactions are encrypted with a symmetric key used by the initiator of the historical transactions. Thus, after obtaining the historical transaction and/or the transaction receipt of the historical transaction, the symmetric key used by user a may be obtained first, and then the historical transaction and/or the transaction receipt of the historical transaction may be decrypted within the TEE by the symmetric key. For the acquisition of the symmetric key used by the initiator, the symmetric key used for encrypting the historical transaction (the symmetric key is encrypted by the public key used by the user a) may be acquired first, and the symmetric key is decrypted in the TEE by the private key corresponding to the public key used by the user a to obtain the decrypted symmetric key.

When the target privacy data includes at least one of account attribute information of user a, account attribute information of the business contract, contract code of the business contract, contract state data of the business contract, the privacy data may be decrypted within the TEE by a specific symmetric key of the blockchain node.

For example, the specific symmetric key may be a seal (Simple Encrypted Arithmetic Library) key, which may be sent by the key management server to the blockchain node after passing the remote attestation, or may be negotiated between the blockchain nodes, and the blockchain node uses the seal key to encrypt and decrypt the private data. Of course, the key management server sends the key to the blockchain node after remote certification, or the symmetric key obtained by negotiation between the blockchain nodes may be not the seal key, but a root key (root key), and the seal key may be a derivative key of the root key. For example, the root key may irreversibly derive several versions of the derivative key in turn, and the low version key is irreversibly derived from the high version key between any two adjacent keys, thereby forming a chained key derivative structure. For example, if 256 versions of keys with version numbers of 0-255 are needed to be derived, hash calculation can be performed on the root key and version factor 0xFF (decimal value is 255, namely the version number of the key to be generated; of course, other values can be adopted), so as to obtain a key-255 with version number of 255; carrying out hash calculation on the key-255 and the version factor 0xFE to obtain a key-254 with a version number of 254; … … by hashing the key-1 with version factor 0x00, a key-0 with version number 0 is obtained. Due to the characteristics of the hash algorithm, the calculation between the high-version key and the low-version key is irreversible, for example, the key-0 can be calculated by the key-1 and the version factor 0x00, but the key-1 cannot be reversely deduced by the key-0 and the version factor 0x 00.

Then, a certain version of the derivative key may be specified as the seal key described above to encrypt the private data. Further, the seal key may be updated in version, and based on the above characteristics, the update should be performed from the low version key to the high version key, so that even after the low version key is leaked, the high version key cannot be reversely deduced, and sufficient data security is ensured.

In step 528, the block link point encrypts the target private data using the symmetric key of user B.

In step 530, user B views the target privacy data.

In an embodiment, after encrypting the target private data, the blockchain node may generate an event containing the target private data and store the event in the blockchain log, and then the user B may use the client to obtain the event through a callback mechanism of the blockchain, so as to view the target private data. After the target privacy data is obtained, the user B decrypts the target privacy data by adopting the symmetric key used by the user B through the client, so that the privacy data of the plaintext content can be obtained.

In another embodiment, after encrypting the target privacy data, the blockchain node may directly return the encrypted target privacy data to the client used by the user B. Similarly, the user B decrypts the target privacy data by the client side through the symmetric key used by the user B, and the privacy data of the plaintext content can be obtained.

Therefore, through the query scheme of the private data in the specification, the user A can realize the sharing of the private data between the user A and the user B without sharing the symmetric key used by the user A to the user B, so that the safety and the convenience are improved.

Corresponding to the method embodiment, the present specification also provides an embodiment of a private data query device based on the smart contract.

The embodiment of the private data query device of the present specification can be applied to an electronic device. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a nonvolatile memory into a memory by a processor of an electronic device where the device is located for operation.

In terms of hardware, please refer to fig. 6, fig. 6 is a schematic block diagram of an apparatus according to an exemplary embodiment. At the hardware level, as shown in fig. 6, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile storage 610, although other hardware required for other services is possible. The processor 602 reads a corresponding computer program from the nonvolatile memory 610 into the memory 608 and then runs to form a smart contract-based privacy data query means at a logic level. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

Referring to fig. 7, in a software implementation, the query device applied to a blockchain node may include:

a transaction reading unit 701, when receiving a query transaction for target privacy data initiated by a querying party, reading a transaction identifier of a historical transaction related to the target privacy data and a contract address of a business contract called by the historical transaction, which are included in the query transaction;

a rights inquiry unit 702 that acquires the service contract according to the contract address and executes a rights control code defined in the service contract to determine a rights of inquiry of the inquirer for the target privacy data;

and a data acquisition unit 703, when the determined query authority is permission for query, acquiring the target privacy data, and reading the acquired target privacy data into a trusted execution environment for decryption, so as to be acquired by the querying party.

Optionally, the method further comprises:

a transaction identification unit 704 configured to, when any received transaction is used to call a distribution contract, take the any transaction as the inquiry transaction;

and a contract calling unit 705 that executes the distribution code defined in the distribution contract to call the service contract to execute the authority control code according to the contract address.

Optionally, the target privacy data includes at least one of:

the historical transaction, a transaction receipt corresponding to the historical transaction, account attribute information of an initiator of the historical transaction, account attribute information of the business contract, a contract code of the business contract, and contract status data of the business contract.

Optionally, the target privacy data includes the historical transaction and/or the transaction receipt; the data acquisition unit 703 is specifically configured to:

acquiring a symmetric key used by the initiator;

decrypting the target private data within the trusted execution environment with the symmetric key.

Optionally, the data acquisition unit 703 is further configured to:

obtaining a symmetric key for encrypting the historical transaction, the symmetric key being encrypted by a public key used by the initiator;

and decrypting the symmetric key in the trusted execution environment through a private key corresponding to the public key used by the initiator to obtain a decrypted symmetric key.

Optionally, the public key used by the initiator is sent to the initiator by a key management server through remote attestation, the trusted execution environment of the blockchain node is established by an SGX architecture, and the private key corresponding to the public key is sent to the enclosure of the blockchain node by the key management server through remote attestation.

Optionally, the target privacy data includes at least one of account attribute information of an initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, and contract state data of the business contract; the data acquisition unit 703 is specifically configured to:

decrypting the target private data within the trusted execution environment with a specific symmetric key of the blockchain node.

Optionally, the trusted execution environment of the blockchain node is established by an SGX architecture, and the specific symmetric key is sent by a key management server after the SGX architecture of the blockchain node passes the remote certification, or is obtained by negotiating between the blockchain node and other blockchain nodes.

Alternatively to this, the method may comprise,

the permission query unit 702 is specifically configured to: executing authority control codes defined in the business contracts to determine the inquiring authority of the inquiring party for the target privacy data according to the identity information of the inquiring party;

or the inquiry transaction also comprises the identity information of the initiator of the historical transaction; the permission query unit is specifically configured to: executing authority control codes defined in the business contracts to determine the inquiring authority of the inquiring party for the target privacy data according to the identity information of the inquiring party and the identity information of the initiator; or executing the authority control code defined in the business contract to determine the inquiring authority of the inquirer for the target privacy data according to the identity information of the initiator.

Optionally, after determining that the query authority is permission to query, the apparatus further includes:

a first obtaining unit 706, configured to obtain the historical transaction according to the transaction identifier;

a first verification unit 707 that determines identity information of an initiator of the historical transaction according to the obtained historical transaction;

the first prohibiting unit 708 prohibits the operation of acquiring the target privacy data from being performed when the determined identity information is inconsistent with the identity information of the history transaction included in the inquiry transaction.

a second obtaining unit 709 that obtains the historical transaction according to the transaction identifier;

a second checking unit 710 for determining, according to the obtained historical transaction, a contract address of a service contract actually invoked by the historical transaction;

the second prohibiting unit 711 prohibits the execution of the operation of acquiring the target privacy data when the determined contract address does not coincide with the contract address of the business contract called by the history transaction included in the inquiry transaction.

Optionally, a symmetric key that encrypts the query transaction is encrypted by a public key used by the querying party;

After receiving the query transaction, the apparatus further comprises: a transaction decryption unit 712, configured to decrypt, in the trusted execution environment, a symmetric key that encrypts the query transaction by using a private key corresponding to the public key used by the querying party, and decrypt the query transaction by using the symmetric key obtained by decryption, so as to obtain transaction content included in the query transaction;

after decrypting the target private data, the apparatus further comprises: the data encryption unit 713 encrypts the decrypted target private data by the symmetric key of the inquirer.

Optionally, the method further comprises:

and a privacy processing unit 714 for generating a contract receipt for indicating that the inquirer is prohibited from inquiring the target privacy data for viewing by the inquirer when the determined inquiry authority is prohibited from inquiring.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, 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 a combination of any of these devices.

For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.

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

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

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

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

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

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

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

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

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

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

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

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A privacy data query method based on intelligent contracts is applied to block chain nodes; the method comprises the following steps:

when a query transaction for target privacy data initiated by a query party is received, a contract address of a business contract called by a historical transaction contained in the query transaction is read, wherein the historical transaction is related to the target privacy data;

when the determined query permission is permission for query, acquiring the target privacy data, and reading the acquired target privacy data into a trusted execution environment maintained by the blockchain node for decryption so as to be acquired by the querying party;

The method further comprises the steps of:

after determining that the inquiring authority of the inquiring party for the target privacy data is allowable to inquire, reading the transaction identifier of the historical transaction contained in the inquiring transaction;

acquiring corresponding historical transaction according to the transaction identifier, and determining a contract address of a service contract actually called by the acquired historical transaction;

and when the determined contract address is inconsistent with the contract address contained in the inquiry transaction, prohibiting the operation of acquiring the target privacy data.

2. The method of claim 1, further comprising:

when any received transaction is used for calling the distribution contract, the any transaction is used as a query transaction.

3. The method of claim 2, the acquiring the service contract according to the contract address, and executing the authority control code defined in the service contract, comprising:

and calling the distribution contract to execute the distribution code defined in the distribution contract so as to call the business contract to execute the authority control code defined in the business contract according to the contract address.

4. A method according to claim 3, the distribution code defined in the distribution contract being recorded in an created chunk of a blockchain.

5. The method of claim 1, wherein a business code defined in the business contract is executed in the event that a blocklink point is responsive to the historical transaction.

6. The method of claim 1, the target privacy data comprising at least one of:

the historical transaction, a transaction receipt corresponding to the historical transaction, account attribute information of an initiator of the historical transaction, account attribute information of a business contract invoked by the historical transaction, a contract code of the business contract invoked by the historical transaction, and contract status data of the business contract invoked by the historical transaction.

7. The method of claim 6, the target privacy data comprising the historical transaction and/or the transaction receipt; reading the obtained target privacy data into a trusted execution environment maintained by the blockchain node for decryption, wherein the method comprises the following steps:

acquiring a symmetric key used by an initiator of the historical transaction;

8. The method of claim 7, the obtaining a symmetric key used by an initiator of the historical transaction comprising:

Obtaining a symmetric key for encrypting the historical transaction, the symmetric key being encrypted by a public key used by an initiator of the historical transaction;

and decrypting the symmetric key in the trusted execution environment through a private key corresponding to the public key used by the initiator of the historical transaction to obtain a decrypted symmetric key.

9. The method of claim 8, wherein a public key used by an initiator of the historical transaction is sent by a key management server to the initiator of the historical transaction through remote attestation, and wherein a trusted execution environment maintained by the blockchain node is established by an SGX architecture, and wherein a private key corresponding to the public key is sent by the key management server to an enclosure of the blockchain node through remote attestation.

10. The method of claim 6, the target privacy data comprising at least one of account attribute information of an initiator of the historical transaction, account attribute information of a business contract invoked by the historical transaction, a contract code of a business contract invoked by the historical transaction, and contract status data of a business contract invoked by the historical transaction; reading the obtained target privacy data into a trusted execution environment maintained by the blockchain node for decryption, wherein the method comprises the following steps:

Decrypting the target private data within the trusted execution environment with a symmetric key of the blockchain node.

11. The method of claim 10, the trusted execution environment maintained by the blockchain node is established by an SGX architecture, the symmetric key is sent by a key management server after the SGX architecture of the blockchain node passes remote attestation, or is negotiated between the blockchain node and other blockchain nodes.

12. The method according to claim 1,

the executing of the rights control code defined in the business contract to determine the querying rights of the querying party to the target privacy data includes: executing authority control codes defined in the business contracts to determine the inquiring authority of the inquiring party for the target privacy data according to the identity information of the inquiring party;

or the inquiry transaction also comprises the identity information of the initiator of the historical transaction; the executing of the rights control code defined in the business contract to determine the querying rights of the querying party to the target privacy data includes: executing authority control codes defined in the business contracts to determine the inquiring authority of the inquiring party for the target privacy data according to the identity information of the inquiring party and the identity information of the initiator of the historical transaction; or executing the authority control code defined in the business contract to determine the inquiring authority of the inquirer for the target privacy data according to the identity information of the initiator of the historical transaction.

13. The method of claim 12, further comprising:

after determining that the query authority is allowed to query, acquiring the historical transaction according to the transaction identifier;

determining identity information of an initiator of the historical transaction according to the acquired historical transaction;

and when the determined identity information is inconsistent with the identity information of the initiator of the historical transaction contained in the inquiry transaction, prohibiting the operation of acquiring the target privacy data.

14. The method of claim 1, wherein a symmetric key that encrypts the query transaction is encrypted by a public key used by the querying party;

after receiving the query transaction, the method further comprises: decrypting a symmetric key for encrypting the query transaction through a private key corresponding to a public key used by the query party in the trusted execution environment, and decrypting the query transaction through the symmetric key obtained through decryption to obtain transaction content contained in the query transaction;

after decrypting the target private data, the method further comprises: and encrypting the decrypted target privacy data by the symmetric key of the inquiring party.

15. The method of claim 1, further comprising:

And when the determined inquiry authority is inquiry prohibition, generating a contract receipt for indicating that the inquirer prohibits inquiry of the target privacy data for viewing by the inquirer.

16. The method of claim 1, wherein the query transaction includes a transaction identification of the historical transaction; the obtaining the target privacy data includes:

and acquiring the target privacy data according to the transaction identifier.

17. The privacy data query device based on the intelligent contract is applied to the blockchain node; the device comprises:

a transaction reading unit, when receiving a query transaction for target privacy data initiated by a query party, reading a contract address of a business contract called by a historical transaction contained in the query transaction, wherein the historical transaction is related to the target privacy data;

the data acquisition unit acquires the target privacy data when the determined query permission is allowable for query, and reads the acquired target privacy data into a trusted execution environment maintained by the blockchain node for decryption so as to be acquired by the querying party;

The apparatus further comprises:

the second acquisition unit is used for reading the transaction identifier of the historical transaction contained in the query transaction after determining that the query authority of the query party for the target privacy data is allowed to query;

the second verification unit acquires corresponding historical transaction according to the transaction identifier and determines a contract address of a service contract actually called by the acquired historical transaction;

and the second prohibition unit prohibits the operation of acquiring the target privacy data when the determined contract address is inconsistent with the contract address contained in the inquiry transaction.

18. The apparatus of claim 17, further comprising:

and the transaction identification unit is used for taking any received transaction as the inquiry transaction when the transaction is used for calling the distribution contract.

19. The apparatus of claim 18, the permission query unit is specifically configured to:

20. The apparatus of claim 19, the distribution code defined in the distribution contract is recorded in an occurrence block of a blockchain.

21. The apparatus of claim 17, wherein a business code defined in the business contract is executed in the event that a blocklink point is responsive to the historical transaction.

22. The apparatus of claim 17, the target privacy data comprising at least one of:

23. The apparatus of claim 22, the target privacy data comprising the historical transaction and/or the transaction receipt; the data acquisition unit is specifically configured to:

acquiring a symmetric key used by an initiator of the historical transaction;

24. The apparatus of claim 23, the data acquisition unit further to:

25. The apparatus of claim 24, a public key used by an initiator of the historical transaction is sent by a key management server to the initiator of the historical transaction through remote attestation, a trusted execution environment of the blockchain node is established by an SGX architecture, and a private key corresponding to the public key is sent by the key management server to an enclosure of the blockchain node through remote attestation.

26. The apparatus of claim 22, the target privacy data comprising at least one of account attribute information of an initiator of the historical transaction, account attribute information of a business contract invoked by the historical transaction, a contract code of a business contract invoked by the historical transaction, and contract status data of a business contract invoked by the historical transaction; the data acquisition unit is specifically configured to:

27. The apparatus of claim 26, the trusted execution environment maintained by the blockchain node is established by an SGX architecture, the symmetric key is sent by a key management server after the SGX architecture of the blockchain node passes remote attestation, or is negotiated between the blockchain node and other blockchain nodes.

28. An apparatus according to claim 17,

the permission query unit is specifically configured to: executing authority control codes defined in the business contracts to determine the inquiring authority of the inquiring party for the target privacy data according to the identity information of the inquiring party;

or the inquiry transaction also comprises the identity information of the initiator of the historical transaction; the permission query unit is specifically configured to: executing authority control codes defined in the business contracts to determine the inquiring authority of the inquiring party for the target privacy data according to the identity information of the inquiring party and the identity information of the initiator of the historical transaction; or executing the authority control code defined in the business contract to determine the inquiring authority of the inquirer for the target privacy data according to the identity information of the initiator of the historical transaction.

29. The apparatus of claim 28, further comprising:

the first acquisition unit acquires the historical transaction according to the transaction identifier after determining that the query authority is allowed to be queried;

the first verification unit is used for determining identity information of an initiator of the historical transaction according to the acquired historical transaction;

And the first prohibition unit prohibits the operation of acquiring the target privacy data when the determined identity information is inconsistent with the identity information of the initiator of the historical transaction contained in the inquiry transaction.

30. The apparatus of claim 17, wherein a symmetric key that encrypts the query transaction is encrypted by a public key used by the querying party;

after receiving the query transaction, the apparatus further comprises: a transaction decrypting unit, configured to decrypt, in the trusted execution environment, a symmetric key for encrypting the query transaction by using a private key corresponding to a public key used by the querying party, and decrypt the query transaction by using the symmetric key obtained by decryption, so as to obtain transaction content included in the query transaction;

after decrypting the target private data, the apparatus further comprises: and the data encryption unit encrypts the decrypted target privacy data through the symmetric key of the inquiring party.

31. The apparatus of claim 17, further comprising:

and the privacy processing unit is used for generating a contract receipt for indicating that the inquirer is forbidden to inquire the target privacy data so as to be checked by the inquirer when the determined inquiry authority is forbidden to inquire.

32. The apparatus of claim 17, the data acquisition unit is specifically configured to:

and acquiring the target privacy data according to the transaction identifier.

33. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any one of claims 1-16 by executing the executable instructions.

34. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-16.