WO2021088546A1 - Blockchain account-based privacy data query method and device - Google Patents

Abstract

The present invention provides a blockchain account-based privacy data query method and device. Said method is applied to a blockchain node, and comprises: upon reception of a query transaction initiated by a querier for querying target privacy data, reading a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction which are contained in the query transaction; determining a blockchain account of the initiator according to the identity information of the initiator, and determining, according to a query permission recorded in the blockchain account, a query permission of the querier for the target privacy data; and when the determined inquiry permission allows a 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 querier.

Description

Privacy data query method and device based on blockchain account Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a method and device for querying private data based on a blockchain account.

Background technique

Blockchain technology is built on a transmission network (such as a peer-to-peer network). The network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.

At present, the two biggest challenges in enterprise-level blockchain platform technology are privacy and performance. It is often difficult to solve these two challenges at the same time. Most of the solutions are to lose performance in exchange for privacy, or do not consider privacy to pursue performance. Common encryption technologies that solve privacy problems, such as Homomorphic encryption and Zero-knowledge proof, are highly complex, have poor versatility, and may also cause serious performance losses.

Trusted Execution Environment (TEE) is another way to solve privacy issues. TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped, and only the pre-defined interface in the code can operate on it. In terms of efficiency, due to the black box nature of TEE, plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption. There is no loss of efficiency in the calculation process. Therefore, the combination with TEE can achieve less performance loss. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about the TEE solution. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor).

Summary of the invention

In view of this, one or more embodiments of this specification provide a method and device for querying private data based on a blockchain account.

To achieve the foregoing objectives, one or more embodiments of the present specification provide technical solutions as follows.

According to the first aspect of one or more embodiments of this specification, a method for querying private data based on a blockchain account is proposed, which is applied to a blockchain node; the method includes: During a private data query transaction, read the transaction identifier of the historical transaction related to the target private data contained in the query transaction and the identity information of the initiator of the historical transaction; determine according to the identity information of the initiator The blockchain account of the initiator, and determine the query authority of the query party for the target private data according to the query authority recorded in the blockchain account; when the determined query authority is allowed to query, obtain The target private data and the obtained target private data are read into a trusted execution environment for decryption, so as to be obtained by the querying party.

According to the second aspect of one or more embodiments of this specification, a method for querying private data is proposed, which is applied to a blockchain node; the method includes: when receiving a query transaction for target private data sent by the querying party Read the transaction identifier of the historical transaction related to the target privacy data and the identity information of the initiator of the historical transaction contained in the query transaction; when the target privacy data is the historical transaction, according to The identity information of the initiator determines the blockchain account of the initiator, and determines the query authority of the query party for the historical transaction according to the query authority recorded in the blockchain account; when the target privacy When the data is different from other transaction-related data of the historical transaction, read the contract address of the business contract called by the historical transaction contained in the query transaction, and obtain the business contract according to the contract address, and execute The authority control code defined in the business contract is used to determine the query authority of the querying party for the target private data; when the determined query authority is allowed to query, the target private data is acquired and the acquired target The private data is read into the trusted execution environment for decryption, so as to be obtained by the inquiring party.

According to the third aspect of one or more embodiments of this specification, a device for querying private data based on a blockchain account is proposed, which is applied to a blockchain node; the device includes: a transaction reading unit, when the query is received When a party initiates a query transaction for target privacy data, read the transaction identifier of the historical transaction related to the target privacy data contained in the query transaction and the identity information of the initiator of the historical transaction; the authority query unit, Determine the blockchain account of the initiator according to the identity information of the initiator, and determine the query authority of the query party for the target private data according to the query authority recorded in the blockchain account; data acquisition unit When the determined query authority is query permission, the target private data is acquired and the acquired target private data is read into a trusted execution environment for decryption, so that the querying party can obtain it.

According to the fourth aspect of one or more embodiments of this specification, a device for querying private data is proposed, which is applied to a blockchain node; the device includes: a transaction reading unit, when receiving a target-targeted message sent by the querying party During a private data query transaction, read the transaction identifier of the historical transaction related to the target private data contained in the query transaction and the identity information of the initiator of the historical transaction; the first authority query unit, when the When the target privacy data is the historical transaction, the initiator’s blockchain account is determined according to the initiator’s identity information, and the query authority is determined to be specific to the initiator according to the query authority recorded in the blockchain account. The query authority for historical transactions; the second authority query unit, when the target privacy data is other transaction-related data that is different from the historical transaction, reads the historical transaction call service contract information contained in the query transaction Contract address, and obtain the business contract according to the contract address, and execute the authority control code defined in the business contract to determine the query authority for the target private data; the data acquisition unit, when determining When the out-of-query authority is permission to query, the target private data is obtained and the obtained target private data is read into a trusted execution environment for decryption, so as to be obtained by the inquiring party.

According to a fifth aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions In order to realize the method as described in the first aspect.

According to a sixth aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions To achieve the method described in the second aspect.

According to the seventh aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, and computer instructions are stored thereon, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

According to the eighth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided with computer instructions stored thereon, which when executed by a processor implements the steps of the method described in the second aspect.

Description of the drawings

Fig. 1 is a schematic diagram of creating a smart contract according to an exemplary embodiment.

Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of invoking a business contract provided by an exemplary embodiment.

Fig. 4 is a flowchart of a method for querying private data provided by an exemplary embodiment.

Fig. 5 is a flowchart of another method for querying private data provided by an exemplary embodiment.

Fig. 6 is a flowchart of another method for querying private data provided by an exemplary embodiment.

Fig. 7 is a flowchart of another method for querying private data provided by an exemplary embodiment.

Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 9 is a block diagram of a device for querying private data based on a blockchain account according to an exemplary embodiment.

Fig. 10 is a schematic structural diagram of another device provided by an exemplary embodiment.

Fig. 11 is a block diagram of a device for querying private data provided by an exemplary embodiment.

Detailed ways

The exemplary embodiments will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings indicate the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. Rather, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily executed 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. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.

Block chains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations. The private chain is the opposite. The write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use by specific institutions. Consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Whether it is a public chain, a private chain or a consortium chain, it is possible to provide the function of a smart contract. A smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system. Smart contracts can be defined in the form of codes.

Taking Ethereum as an example, it supports users to create and call some complex logic in the Ethereum network. This is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM. EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users who publish and call smart contracts in Ethereum run on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The smart contract deployed on the blockchain can be in the form of bytecode.

For example, as shown in Figure 1, after Bob sends a transaction containing the information to create a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. The "0x6f8ae93..." in Figure 1 represents the address of this contract, the data field of the transaction can be stored in bytecode, and the to field of the transaction is empty. After the nodes reach an agreement through the consensus mechanism, the contract is successfully created and can be called in the subsequent process. After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code will be stored in the contract account. The behavior of the smart contract is controlled by the contract code. In other words, smart contracts enable virtual accounts containing contract codes and account storage (Storage) to be generated on the blockchain.

As shown in Figure 2, still taking Ethereum as an example, after Bob sends a transaction for invoking a smart contract to the Ethereum network, the EVM of a certain node can execute the transaction and generate a corresponding contract instance. The from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93..." in the to field represents the address of the called smart contract, and the value field in Ethereum is the value of Ether , The method and parameters of calling the smart contract are stored in the data field of the transaction. The smart contract is executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, when the transaction is completed, the blockchain will be stored on the blockchain that cannot be tampered with. Lost transaction certificate.

After the nodes in the blockchain network execute the transaction initiated by Bob, they will generate corresponding receipt data to record the receipt information related to the transaction. In this way, information about the execution result of the transaction can be obtained by querying the receipt of the transaction. Taking Ethereum as an example, the receipt data obtained by a node executing a transaction can include the following content: Result field, indicating the execution result of the transaction; Gas used field, indicating the gas value consumed by the transaction; Logs field, indicating the log generated by the transaction, and the log can be It further includes the From field, To field, Topic field, Log data field, etc. The From field represents the account address of the initiator of the call, the To field represents the account address of the called object (such as a smart contract), and the Topic field represents the subject of the log. The Log data field indicates log data; the Output field indicates the output of the transaction.

Generally, the receipt data generated after the transaction is executed is stored in plain text, and anyone can see the contents of the above-mentioned receipt fields contained in the receipt data, and there is no privacy protection setting and ability. In some solutions that combine blockchain and TEE, in order to achieve privacy protection, the entire content of the receipt data is stored on the blockchain as data that requires privacy protection. The blockchain is a collection of data stored in a node's database and organized by specific logic. As described later, the physical carrier of the database may be a storage medium, such as a persistent storage medium. In fact, only part of the content of the receipt data may be sensitive, while other content is not sensitive. Only sensitive content needs to be protected for privacy, and other content can be disclosed. In some cases, it may even be necessary to perform retrieval of part of the content to drive The implementation of related operations, then the implementation of privacy protection for this part of the content will affect the implementation of retrieval operations.

Among them, the process of protecting user privacy can be shown in Figure 3.

Step 302: User A creates a transaction for invoking a business contract, and sends the created transaction to the blockchain node.

User A can invoke the smart contract (ie, business contract) deployed on the blockchain by creating a transaction (including the account address of the called smart contract), so that the blockchain node executes the business contract to complete the corresponding business. For privacy protection, user A can use digital envelope encryption to encrypt the created transaction, which combines a symmetric encryption algorithm and an asymmetric encryption algorithm. Specifically, the transaction content is encrypted using a symmetric encryption algorithm (that is, the transaction content is encrypted using the symmetric key used by itself), and then the public key of the asymmetric encryption algorithm is used to encrypt the symmetric key.

Step 304, the blockchain node executes the business contract.

After receiving the encrypted transaction, the blockchain node reads the transaction into the TEE, first uses the private key of the asymmetric encryption algorithm to decrypt the symmetric key, and then uses the decrypted symmetric key to decrypt the transaction Obtain the transaction content, and then execute the business code of the business contract within the TEE.

In step 306, the blockchain node stores private data related to the transaction.

On the one hand, after receiving the transaction, the blockchain node (after passing the consensus) will publish the transaction (encrypted in the form of a digital envelope) to the blockchain for certification. On the other hand, after the blockchain node executes the transaction, it will also encrypt and store the relevant data obtained from the execution of the transaction (publish it on the blockchain for certification, or store it locally); among them, for the transaction corresponding to the transaction The receipt can be encrypted with the symmetric key used by user A, and the contract status data obtained in response to the execution of the business contract in response to the transaction can be encrypted with a specific symmetric key inside the TEE. In addition, data such as user A's account attribute information, business contract account attribute information, and business contract contract code can also be encrypted using a specific symmetric key inside the TEE. The data encrypted by these blockchain nodes above all belong to user A's private data on the blockchain.

In the above privacy protection scenario, the user may need to share the privacy data related to the business realized by the blockchain to some specific users for viewing, that is, these specific users can view the privacy related to the historical transactions initiated by the user. data. Then, the query authority can be set for the user's private data, so that other users who are allowed to query can view it.

In Ethereum or a blockchain model derived from the Ethereum architecture, accounts can include external accounts and contract accounts. External accounts are usually owned by users (individuals or institutions) and are directly controlled by users, which are also called user accounts. Contract accounts correspond to smart contracts in the blockchain and are created by users through external accounts. The structures of all types of accounts are similar, for example, they can include the Nonce field, the Balance field, the Code field, and the Storage field. The value of the Nonce field of each account starts from 0, and the value of the Nonce field increases in sequence with the transactions initiated by the corresponding account, so that each transaction initiated by the account contains a different value for the Nonce, thereby avoiding repetition. Let's attack. The Balance field is used to store the balance. The Code field is used to store the contract code of the smart contract (in actual applications, the Code field usually only maintains the hash value of the contract code, so the Code field is usually also called the Codehash field), so the Code field of the external account is usually empty. The Storage field is used to store the value of the account at the corresponding node in the state tree.

Of course, the account structure supported by the blockchain can be further expanded to meet the needs of various application scenarios. Therefore, the meaning of the existing account fields can be extended, or new fields can be added, so as to set the query authority for the user's private data. For example, the Code field of the external account is used to record the query authority formulated by the corresponding user; or, the newly added field "permission" is used to record the query authority formulated by the corresponding user.

Therefore, based on the aforementioned improvements to the account structure, users can set their own blockchain account (external account) to query the privacy data related to transactions initiated by themselves. In other words, the query authority of private data is controlled by the user himself. The corresponding private data query scheme will be introduced below in conjunction with Figure 4. Fig. 4 is a flowchart of a method for querying private data based on a blockchain account according to an exemplary embodiment. As shown in Figure 4, the method is applied to a blockchain node and can include the following steps.

Step 402: When receiving a query transaction for target privacy data initiated by the querying party, read the transaction identifier of the historical transaction related to the target privacy data contained in the query transaction and the initiating party of the historical transaction. Identity Information.

In this embodiment, a designated smart contract for identifying query transactions can be deployed on the blockchain. As an exemplary embodiment, the principle of identifying a query transaction may be that when any transaction received by a blockchain node is used to call the designated smart contract, any transaction is regarded as a query transaction. For example, the administrator of the blockchain deploys a distribution contract on the blockchain in advance (for example, initiates a transaction to create a smart contract). The distribution contract is configured with a contract address. When the blockchain node receives the to When the field records the contract address, it can be determined that the transaction is a query transaction. Specifically, the contract address of the distribution contract is written into the preset address list. When the address recorded in the to field of the received transaction belongs to the address list, it can be determined that the received transaction belongs to the query transaction. Among them, the address list can be recorded in the system contract (used to record the address list), or it can be recorded in the chain code. Therefore, when the inquiring party needs to inquire about private data, the to field of the initiated transaction should record the contract address of the aforementioned distribution contract.

Alternatively, the transaction types supported by the blockchain can also be expanded to expand the transaction for querying private data, that is, query transaction. For example, a new type field is added to the transaction format. When "inquiry" is recorded in the type field, it means that the transaction is an inquiry transaction. Therefore, when the inquiring party needs to inquire about private data, the type field of the created transaction should be written "inquiry".

The transaction identifier of the historical transaction related to the target privacy data contained in the query transaction and the identity information of the initiator of the historical transaction can be recorded in the data field of the query transaction or any other existing or newly added fields.

Step 404: Determine the blockchain account of the initiator according to the identity information of the initiator, and determine the query authority of the query party for the target private data according to the query authority recorded in the blockchain account.

In one embodiment, the query authority may be formulated in the blockchain account in the form of a whitelist. For example, the initiator of a historical transaction may configure a whitelist in its own blockchain account, and the query permission of the user recorded in the whitelist for the private data of the initiator is allowed to query. Then, after determining the initiator’s blockchain account based on the initiator’s identity information contained in the query transaction, the whitelist configured in the blockchain account can be read. When the querying party is recorded in the whitelist, It is determined that the querying authority of the querying party for the target private data is allowed to query.

Further, the transaction types supported by the blockchain can be expanded to extend the transaction used to update the white list, that is, the update transaction. Then, when the initiator of a historical transaction needs to update the whitelist maintained in its own blockchain account, it can initiate an update transaction for the whitelist. After the blockchain node receives the update transaction, it will be updated according to the update transaction. The updated content of the included white list updates the white list. It should be noted that, for the update transaction, the digital envelope encryption method in the embodiment shown in FIG. 3 can also be used, and the decryption process is similar to it, and will not be repeated here.

In another embodiment, the query authority can be formulated in the blockchain account in the form of query conditions. For example, the initiator of a historical transaction can set query conditions for private data in its own blockchain account. Then, after the initiator’s blockchain account is determined based on the initiator’s identity information contained in the query transaction, it can be determined whether the identity information meets the query conditions recorded in the blockchain account. When the inquirer’s identity information meets the query When the conditions are used, it can be determined that the querying authority of the querying party for the target private data is allowed to query. Among them, the query conditions can be flexibly set according to actual needs. For example, it can be set such that when the inquiring party's credit score exceeds a preset credit threshold, the inquiry authority of the inquiring party is allowed to inquire. Of course, one or more embodiments of this specification do not limit this.

Step 406: When the determined query authority is allowed to query, obtain the target privacy data and read the obtained target privacy data into a trusted execution environment for decryption, so as to be obtained by the querying party.

In this embodiment, for the above-mentioned protection of user privacy data, the privacy data is encrypted and stored. Therefore, when it is determined that the query authority of the querying party is allowed to query, the target private data is obtained (for example, the target private data can be obtained according to the transaction identification) and the obtained target private data is read into the trusted execution environment for decryption. Obtained by the inquirer. Depending on the type of data contained in the target private data, the decryption method used is also different (because the encryption method is different).

When the target privacy data includes historical transactions and/or transaction receipts of historical transactions, it can be seen from the embodiment shown in Figure 3 that both historical transactions and transaction receipts of historical transactions are encrypted with the symmetric key used by the initiator of the historical transaction . Therefore, 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) can be obtained first, and then the symmetric key can be passed in the TEE. The key decrypts historical transactions and/or transaction receipts of historical transactions. For the acquisition of the symmetric key used by the initiator, the symmetric key used to encrypt historical transactions can be obtained first (the symmetric key is encrypted by the public key used by the initiator, that is, the digital envelope is used in the embodiment shown in FIG. 3). Encryption), the symmetric key is decrypted in the TEE through the private key corresponding to the public key used by the initiator to obtain the decrypted symmetric key.

Among them, the symmetric key used by the initiator can be generated by the initiator through a symmetric encryption algorithm, or obtained through negotiation between the initiator and the blockchain node, or sent by the key management server. As for the symmetric encryption algorithm, for example, it may be the DES algorithm, the 3DES algorithm, the TDEA algorithm, the Blowfish algorithm, the RC5 algorithm, the IDEA algorithm, and so on. The public key used by the initiator is sent to the initiator by the key management server through remote certification, the TEE of the blockchain node is established by the SGX architecture, and the private key corresponding to the public key is sent to the blockchain by the key management server through remote certification Enclave of nodes (enclave, also called enclave). The asymmetric encryption algorithm used to generate the public key and the private key can be, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.

When the target privacy data includes at least one of the account attribute information of the initiator of the historical transaction, the account attribute information of the business contract, the contract code of the business contract, and the contract status data of the business contract, it can be seen from the embodiment shown in FIG. 3 that these Private data is encrypted with a specific symmetric key inside the TEE. Therefore, after obtaining these private data, the private data can be decrypted by the specific symmetric key of the blockchain node in the TEE. For the specific symmetric key inside the TEE, the SGX structure of the blockchain node is sent by the key management server after remote certification, or it is negotiated between the blockchain node and other blockchain nodes.

In this embodiment, similar to the above-mentioned way of encrypting historical transactions to protect privacy, when the querying party initiates a query transaction, it can also use the symmetric key used by itself to encrypt the created query transaction, and use its own symmetric key to encrypt the created query transaction. The public key encrypts the symmetric key. Therefore, after receiving the query transaction, the blockchain node first decrypts the symmetric key of the encrypted query transaction through the private key corresponding to the public key used by the querying party in the TEE, and then queries the transaction through the symmetric key pair obtained by decryption Decryption is performed to obtain the transaction content contained in the query transaction. After obtaining the target private data and decrypting the target private data, the blockchain node can encrypt the decrypted target private data with the symmetric key of the querying party, so that the querying party can use the symmetric key pair used by itself. The target private data is decrypted and viewed, thereby avoiding the target private data from being leaked.

Among them, the sources of the symmetric key, public key, and private key used for privacy protection of the query party are similar to those described above, and will not be repeated here. Of course, the asymmetric keys (public key and private key) used in this process can be the asymmetric keys used for the privacy protection of the initiator as described above.

In this embodiment, since the identity information of the initiator included in the query transaction is only the identity information declared by the querying party, the identity information is not necessarily the actual identity information of the initiator of the historical transaction, that is, the inquiring party has forged the initiation The risk of party identity information. Therefore, after determining that the query authority of the querying party is allowed to query, the blockchain node can obtain the historical transaction according to the transaction identifier of the historical transaction contained in the query transaction (ie transaction ID, usually the hash value of the transaction). The acquired historical transaction determines the identity information of the initiator of the historical transaction (that is, the actual identity information of the initiator). When the determined identity information is inconsistent with the identity information of the initiator included in the query transaction, the operation of obtaining target privacy data is prohibited, which can effectively eliminate the situation that the querying party steals user privacy data by forging the identity information of the initiator.

In this embodiment, when it is determined that the inquiry authority of the inquiry party is forbidden to inquiry, there is no need to perform the above-mentioned step of verifying the identity information of the initiator by obtaining historical transactions. In the case where the query authority of the query party is forbidden to query, the verification step is an unnecessary operation, so the occupation of the processing resources of the blockchain node can be reduced, thereby improving the performance of the blockchain node. At the same time, when it is determined that the querying authority of the querying party is forbidding querying, a contract receipt indicating that the querying party is prohibited from querying the target private data can be generated for the querying party to view.

It can be seen from the above technical solutions that the query authority for private data (related to historical transactions) is controlled by the initiator of the historical transaction. In addition, for different types of private data, the corresponding query authority can be controlled by different users. Specifically, the query authority of the historical transaction itself is controlled by the initiator of the historical transaction (that is, the above-mentioned method is controlled by the initiator's blockchain account), and is different from the query authority of other transaction-related data of the historical transaction , It is controlled by the business contract invoked by the historical transaction, that is, controlled by the deployer of the business contract. The corresponding private data query scheme will be introduced below in conjunction with Figure 5. Fig. 5 is a flowchart of a method for querying private data provided by an exemplary embodiment. As shown in Figure 5, this method is applied to a blockchain node and can include the following steps.

Step 502: When receiving a query transaction for target privacy data sent by the querying party, read the transaction identifier of the historical transaction related to the target privacy data contained in the query transaction and the originator of the historical transaction. Identity Information.

Step 504: When the target privacy data is the historical transaction, determine the blockchain account of the initiator according to the identity information of the initiator, and determine the blockchain account of the initiator according to the query authority recorded in the blockchain account. The inquiry authority of the inquiry party for the historical transaction.

In this embodiment, other transaction-related data may include at least one of the following: transaction receipts corresponding to historical transactions, account attribute information of the initiator of historical transactions, account attribute information of business contracts, contract codes of business contracts, business contracts The contract status data. Among them, the historical transaction itself is created by the initiator, so the query authority of the historical transaction is controlled by the initiator; and other transaction-related data that is different from the historical transaction is associated with the business contract called by the historical transaction (generated by the business contract, or belongs to Business contract), so the query authority of other transaction-related data is controlled by the deployer of the business contract. Through the above-mentioned query authority setting mechanism, the query authority of private data can be flexibly controlled.

It should be noted that, for the implementation process of the foregoing step 504, reference may be made to the process of step 404 in the embodiment shown in FIG. 3, which will not be repeated here.

Step 506: When the target privacy data is other transaction-related data that is different from the historical transaction, read the contract address of the business contract called by the historical transaction contained in the query transaction, and according to the contract address Obtain the business contract, and execute the authority control code defined in the business contract to determine the query authority of the query party for the target private data.

In this embodiment, when developing the business contract, in addition to defining the business code in the business contract, it is also necessary to define the authority control code of the privacy data related to the transaction that invokes the business contract in the business contract to determine Whether the inquirer of this private data is allowed to inquire. By defining the permission control code in the business contract, the private data can be associated with the permission control code that controls the query permission of the private data, so that each business contract can control the private data related to the transaction calling itself.

The development and deployment of business contracts can be completed by roles such as blockchain users, blockchain members, and blockchain administrators. Take the consortium chain as an example. Blockchain members (or blockchain users, administrators) with accounting authority set up authority control rules, and define the authority control rules in the form of authority control codes in the business contract (also Defined the business code). After completing the development of the business contract, the blockchain member can publish the business contract to the alliance chain through any node device in the alliance chain, and the business contract is specified by the member node device in the alliance chain. (For example, several authoritative node devices with accounting authority designated in the consortium chain) After completing the consensus, they are included in the distributed database (ie, distributed ledger) of the consortium chain. Based on the above method of deploying a business contract, the deploying party of the business contract (i.e., ordinary users or ordinary members with accounting authority) can control whether others are allowed to inquire about and send transactions to the business contract (that is, the transaction that calls the business contract). ) Related privacy data.

Among them, the consensus algorithms supported in the blockchain can include: the first type of consensus algorithm, that is, the consensus algorithm that node devices need to compete for the accounting right of each round of accounting cycle; for example, Proof of Work (POW) ), Proof of Stake (POS), Delegated Proof of Stake (DPOS) and other consensus algorithms; the second type of consensus algorithm, that is, pre-election of accounting nodes for each round of accounting cycle (no need to compete Accounting rights) consensus algorithms; for example, practical Byzantine Fault Tolerance (PBFT) and other consensus algorithms.

In the blockchain network using the first type of consensus algorithm, all node devices that compete for the right to bookkeeping can execute the transaction after receiving the transaction. Among the node devices competing for the right to bookkeeping, one node device may win this round of contention for the right to bookkeeping and become the bookkeeping node. The accounting node can package the received transaction with other transactions to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus.

In the blockchain network using the second type of consensus algorithm, the node device with the right to book accounts has been agreed before this round of bookkeeping. Therefore, after the node device receives the transaction, if it is not the accounting node of this round, it can send the transaction to the accounting node. For this round of accounting nodes, the transaction can be executed during or before the process of packaging the transaction with other transactions to generate the latest block. After the accounting node generates the latest block, it can send the latest block or the block header of the latest block to other node devices for consensus.

As mentioned above, no matter which consensus algorithm shown above is adopted by the blockchain, the accounting node of this round can package the received transaction to generate the latest block, and the generated latest block or the latest block The header of the block is sent to other node devices for consensus verification. If other node devices receive the latest block or the block header of the latest block, and there is no problem after verification, the latest block can be appended to the end of the original blockchain to complete the accounting process of the blockchain. In the process of verifying the new block or block header sent by the accounting node, other nodes can also execute the transaction contained in the block.

Based on the above method of deploying business contracts for controlling query authority, each business contract only controls the query authority of private data related to the transaction that invokes itself. Therefore, when a user (as a query party) initiates a query transaction for target private data related to a historical transaction (initiated by any other user), the blockchain node needs to determine the business that controls the query authority of the target private data Contract, and then the business contract can be invoked to achieve permission control.

For blockchain nodes to call business contracts to achieve permission control, a distribution contract can be deployed on the blockchain in advance to identify whether the transaction received by the blockchain node is a query transaction, and when the received transaction is When querying a transaction, the corresponding business contract is further called to execute the authority control code (it can be understood as distributing the query transaction to the corresponding business contract). Specifically, on the basis of the distribution contract in the embodiment shown in FIG. 4, a distribution code may be further defined in the distribution contract, and the distribution code is used to invoke the business contract to execute the authority control code defined in the business contract. Therefore, when the querying party needs to query other transaction-related data other than historical transactions, the query transaction created by the querying party is a transaction used to call the distribution contract; at the same time, the query transaction can record the contract of the business contract called by the historical transaction address. Then, when any transaction received by the blockchain node is used to call the distribution contract, any transaction can be used as a query transaction, and the distribution contract can be invoked to execute the distribution code defined in the distribution contract, so that the query transaction contains The contract address further calls the corresponding business contract (that is, the business contract called by the historical transaction) to execute the authority control code. Taking Ethereum as an example, the content of the to field in the query transaction created by the querying party is the contract address of the distribution contract, and the content of the to field in the historical transaction is also recorded in the query transaction, that is, the contract address of the business contract called by the historical transaction.

Based on the role of the distribution contract as a "distribution query transaction", the distribution contract can be designed as a system-level smart contract. Therefore, the development and deployment of the distribution contract can be completed by the administrator of the blockchain. Also taking the alliance chain as an example, an administrator with management authority develops the distribution logic (calls the business contract based on the contract address of the business contract called by the historical transaction recorded in the query transaction), and distributes the logic in the form of code distribution Defined in the distribution contract. After completing the development of the distribution contract, the administrator can publish the distribution contract to the alliance chain for deployment (similar to the above-mentioned process of deploying smart contracts).

Among them, in one case, the distribution contract can be deployed through the genesis block of the blockchain, that is, the distribution contract is deployed when the blockchain is built, and the contract code of the distribution contract is recorded in the genesis block. In another case, the distribution contract can be deployed in the subsequent process of building the blockchain; for example, the administrator wants to increase the permission query function in the subsequent use process. Then, the administrator can initiate a transaction to create a distribution contract to deploy the distribution contract on the blockchain. Among them, the to field of the transaction is an empty string, and the binary code for initializing the contract is specified in the data field. When the contract is called later, the execution result of the code will be the contract code.

In the technical solution of this specification, in addition to the above-mentioned deployment of the distribution contract to call the business contract to achieve permission control, the above-mentioned distribution logic can also be solidified into the chain code in the form of distribution code, and released together with the chain code. The administrator needs to deploy later, and the contract code is solidified in the chain code, making the contract code controllable and effectively improving security. In other words, the operation of distributing the query transaction to the corresponding business contract is completed by the blockchain node itself, rather than by calling a smart contract.

It should be noted that the type of request initiated on the blockchain by a user who accesses the blockchain can specifically refer to the transaction used in the traditional blockchain. Of course, the type of request initiated on the blockchain by a user who accesses the blockchain can also be other than a transaction, other forms of instructions, messages, etc. with a standard data structure, one or more embodiments of this specification It is not particularly limited. In the following embodiments, the request initiated on the blockchain by the user accessing the blockchain is taken as an example for description.

In this embodiment, the permission control rules defined in the form of permission control codes in the business contract can be flexibly set according to actual needs; of course, one or more embodiments of this specification do not limit the specific content of the permission control rules. In one case, the identity information of the inquiring party can be used as the basis for authority control. Correspondingly, when the query party creates the query transaction, the query transaction should contain the identity information of the query party. For example, the identity information of the inquiring party is the account ID (ie account address) of the inquiring party, and the account ID may be recorded in the from field of the inquiry transaction. Further, the permission control rule can be set to allow the querying party to query corresponding private data when the identity information of the querying party meets specific conditions. For example, when the inquiring party belongs to a pre-designated set of inquiring users, the inquiry authority of the inquiring party can be determined to allow the inquiry, or when the inquiring party's credit score exceeds the preset credit threshold, the inquiry authority of the inquiring party can be determined to be allowed Query and so on. Therefore, when determining the query authority of the querying party, the authority control code defined in the business contract can be executed to determine the querying party's query authority for the target private data according to the identity information of the querying party.

In another case, the identity information of the inquiring party and the identity information of the initiator of the historical transaction can be used together as the basis for authority control. Correspondingly, when the inquiring party creates the inquiry transaction, the inquiry transaction should also include information about the historical transaction. The identity information of the initiator. Then, the permission control rule can be set to allow the querying party to query corresponding private data when the identity information of the querying party and the identity information of the initiator meet specific conditions. For example, the query group and the queried group are recorded in the permission control rules, and members belonging to the query group are allowed to view the private data of the members of the queried group; or, the permission control rules directly record the correspondence of which other users each user can view; or When the inquiry party and the initiator belong to the same team, the inquiry authority of the inquiry party can be determined to allow inquiry and so on. Therefore, when determining the query authority of the querying party, the authority control code defined in the business contract can be executed to determine the querying party's query authority for the target private data according to the identity information of the querying party and the identity information of the initiator.

In another case, the identity information of the initiator of the historical transaction can be used as the basis for authority control. Accordingly, when the querying party creates the query transaction, the query transaction should include the identity information of the initiator of the historical transaction. Then, the permission control rule can be set to allow the querying party to query corresponding private data when the identity information of the initiator meets specific conditions. For example, when the initiator belongs to a pre-designated set of users that can be queried, the query authority of the inquiring party can be determined to allow the query, or when the credit score of the initiator exceeds the preset credit threshold, the query authority of the inquiring party can be determined to be allowed Query and so on. Therefore, when determining the query authority of the querying party, the authority control code defined in the business contract can be executed to determine the querying party's query authority for the target private data according to the identity information of the initiator.

When the basis of authority control includes the identity information of the initiator of the historical transaction, the identity information of the initiator contained in the query transaction is only the identity information declared by the querying party, and the identity information is not necessarily the actual initiator of the historical transaction. The identity information of the inquiring party may forge the identity information of the initiator. Therefore, after determining that the query authority of the querying party is allowed to query, the blockchain node can obtain the historical transaction according to the transaction identifier of the historical transaction contained in the query transaction (ie transaction ID, usually the hash value of the transaction). The acquired historical transaction determines the identity information of the initiator of the historical transaction (that is, the actual identity information of the initiator). When the determined identity information is inconsistent with the identity information of the initiator included in the query transaction, the operation of obtaining target privacy data is prohibited, which can effectively eliminate the situation that the querying party steals user privacy data by forging the identity information of the initiator.

Similarly, the query transaction is created by the querying party, and the contract address of the business contract called by the historical transaction contained in the query transaction is declared by the querying party, so the contract address is not necessarily the contract address of the business contract actually called by the historical transaction , That is, there is a risk that the querying party forges the contract address. Therefore, after determining that the query authority of the querying party is allowed to query, the blockchain node can obtain the historical transaction according to the transaction identifier of the historical transaction contained in the query transaction (ie transaction ID, usually the hash value of the transaction). The acquired historical transaction determines the contract address of the business contract actually called by the 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 query transaction, the operation of obtaining the target privacy data is prohibited, which can effectively eliminate the inquirer from forging the contract address to steal the user's privacy data. Happening.

Taking Ethereum as an example, the hash value of the historical transaction (as the transaction identifier), the contract address of the business contract called by the historical transaction (that is, the content of the to field of the historical transaction), and the identity information of the initiator of the historical transaction (that is, the from Field content) and other data can be recorded in the data (also written as input) field of the query transaction. After the blockchain node determines that the query authority of the query party is allowed to query, it can be obtained from the blockchain according to the hash value of the historical transaction Historical transactions (documented on the blockchain), and read the contents of the from field of historical transactions and the contents of the to field of historical transactions. If the contents of the read from field are the same as the contents of the from field declared in the query transaction , The operation of obtaining the target private data can be further performed; otherwise, the operation of obtaining the target private data is prohibited. In the same way, if the content of the read to field is the same as the content of the to field declared in the query transaction, the operation of obtaining the target private data can be further performed; otherwise, the operation of obtaining the target private data is prohibited.

Step 508: When the determined query authority is allowed to query, acquire the target privacy data and read the acquired target privacy data into a trusted execution environment for decryption, so as to be obtained by the querying party.

In this embodiment, the encryption and decryption process of query transaction and private data is similar to the embodiment shown in FIG. 4, and will not be repeated here.

In this embodiment, when it is determined that the inquiry authority of the inquiry party is forbidden to inquiry, there is no need to perform the above-mentioned steps of verifying the identity information of the initiator or verifying the contract address of the business contract by obtaining historical transactions. In the case where the query authority of the query party is forbidden to query, the verification step is an unnecessary operation, so the occupation of the processing resources of the blockchain node can be reduced, thereby improving the performance of the blockchain node. At the same time, when it is determined that the querying authority of the querying party is forbidding querying, a contract receipt indicating that the querying party is prohibited from querying the target private data can be generated for the querying party to view.

For ease of understanding, the following describes the process of the querying party viewing the target private data with reference to Figures 6-7.

As shown in Fig. 6, following the scenario of Fig. 3 above, after user A initiates a transaction invoking the business contract, user A can share the transaction with user B, or user B has a need to view the transaction. Then, the process of user B as the inquiring party inquiring about historical transactions may include the following steps.

Step 602: User B creates a query transaction through the client terminal used.

In this embodiment, the to field of the query transaction records the contract address of the distribution contract. At the same time, the hash value (ie transaction ID) and from field of the historical transaction can also be recorded in the data field (or other fields) of the query transaction. Content (the address of the initiator of the historical transaction). Among them, the hash value of the historical transaction and the address of the initiator can be obtained by offline sharing between user B and user A, or obtained by any other means.

In step 604, the user B uses the digital envelope encryption to query the transaction through the client.

In step 606, the user B initiates a query transaction to the blockchain node through the client.

In step 608, the blockchain node decrypts the query transaction in the TEE.

TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside. TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. ARM's Trust Zone technology is the first to realize the real commercial TEE technology. With the rapid development of the Internet, security requirements are getting higher and higher. Not only mobile devices, cloud devices, and data centers have put forward more demands on TEE. The concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, the TEE referred to now is a more generalized TEE. For example, server chip manufacturers Intel and AMD have successively introduced hardware-assisted TEE and enriched the concepts and features of TEE, which has been widely recognized in the industry. The TEE mentioned now usually refers more to this kind of hardware-assisted TEE technology. Different from the mobile terminal, cloud access requires remote access, and the end user is invisible to the hardware platform. Therefore, the first step in using TEE is to confirm the authenticity of TEE. Therefore, the current TEE technology has introduced a remote certification mechanism, which is endorsed by hardware manufacturers (mainly CPU manufacturers) and through digital signature technology to ensure that users can verify the state of the TEE. At the same time, security needs that can't be met by only secure resource isolation, further data privacy protection has also been proposed. Commercial TEEs including Intel SGX and AMD SEV also provide memory encryption technology to limit the trusted hardware to the CPU, and the data on the bus and memory are ciphertexts to prevent malicious users from snooping. For example, TEE technologies such as Intel’s Software Protection Extensions (SGX) isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution. The applications running in TEE are protected by security and are almost impossible to be accessed by third parties.

Taking Intel SGX technology as an example, SGX provides a circle, that is, an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Take the SGX-supported CPU used by the blockchain node as an example. With the newly added processor instructions, a part of the area EPC (Enclave Page Cache, Enclave Page Cache, Enclave Page Cache) can be allocated in the memory through encryption in the CPU. The engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in EPC will be decrypted into plain text only after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage.

In practical applications, the key of the asymmetric encryption algorithm can be generated by the key management server. Through remote certification, the key management server sends the private key to the blockchain node, specifically, it can be passed into the circle of the blockchain node. Blockchain nodes can contain multiple enclosures, and the above private key can be passed into the security enclosures in these enclosures; for example, the security enclosure can be a QE (Quoting Enclave) enclosure instead of AE (Application Enclave) ) Encircle the circle. For asymmetrically encrypted public keys, they can be sent by the key management server to the user's client. Then, the client can use the symmetric encryption algorithm to encrypt the created transaction, that is, use the symmetric key of the symmetric encryption algorithm to encrypt the transaction content, and use the asymmetric encryption algorithm to encrypt the symmetric key used in the symmetric encryption algorithm. Generally, the public key of the asymmetric encryption algorithm is used to encrypt the symmetric key used in the symmetric encryption algorithm. The above encryption method is called digital envelope encryption. After the blockchain node receives the encrypted transaction, it can first use the private key of the asymmetric encryption algorithm to decrypt, obtain the symmetric key of the symmetric encryption algorithm, and then use the symmetric encryption algorithm Decrypt the symmetric key to get the transaction content.

In step 610, the blockchain node determines that the received transaction is a query transaction for invoking the distribution contract.

In this embodiment, after receiving any transaction, the blockchain node reads the content of the to field of the transaction. When the content of the to field is the contract address of the distribution contract, it means that the transaction is used to call the distribution contract, and then it can be determined that the transaction is a query transaction.

In step 612, the blockchain node determines the blockchain account of user A according to the from field of the historical transaction.

Step 614: The blockchain node determines the query authority of user B according to the query authority recorded in the user A's blockchain account.

In one embodiment, the query authority may be formulated in the blockchain account in the form of a whitelist. For example, the initiator of a historical transaction may configure a whitelist in its own blockchain account, and the query permission of the user recorded in the whitelist for the private data of the initiator is allowed to query. Then, after determining the initiator’s blockchain account based on the initiator’s identity information contained in the query transaction, the whitelist configured in the blockchain account can be read. When the querying party is recorded in the whitelist, It is determined that the querying authority of the querying party for the target private data is allowed to query.

For example, the whitelist configured in user A's blockchain account is shown in Table 1:

Privacy whitelist
User B
User C
User D
...

Table 1

It can be seen from Table 1 that user B is a member of the white list, so it can be determined that user B's query authority is allowed to query.

Further, the transaction types supported by the blockchain can be expanded to extend the transaction used to update the white list, that is, the update transaction. For example, a new type field is added to the transaction format. When "update" is recorded in the type field, it means that the transaction is an update transaction. Therefore, when the initiator of a historical transaction needs to update the whitelist maintained in its own blockchain account, the type field of the created transaction should be written "update", and the updated content of the whitelist can be recorded in the update transaction data field or any other existing or new fields. Then, when the initiator of a historical transaction needs to update the whitelist maintained in its own blockchain account, it can initiate an update transaction for the whitelist. After the blockchain node receives the update transaction, it will be updated according to the update transaction. The updated content of the included white list updates the white list. It should be noted that, for the update transaction, the above-mentioned digital envelope method can also be used for encryption, and the decryption process is similar to it, and will not be repeated here.

In another embodiment, the query authority can be formulated in the blockchain account in the form of query conditions. For example, the initiator of a historical transaction can set query conditions for private data in its own blockchain account. Then, after the initiator’s blockchain account is determined based on the initiator’s identity information contained in the query transaction, it can be determined whether the identity information meets the query conditions recorded in the blockchain account. When the inquirer’s identity information meets the query When the conditions are used, it can be determined that the querying authority of the querying party for the target private data is allowed to query. Among them, the query conditions can be flexibly set according to actual needs. For example, it can be set such that when the inquiring party's credit score exceeds a preset credit threshold, the inquiry authority of the inquiring party is allowed to inquire. Of course, one or more embodiments of this specification do not limit this.

Step 616: After determining that the query permission of user B is allowed to query, the blockchain node obtains the historical transaction according to the hash value of the historical transaction.

In step 618, the blockchain node reads historical transactions into the TEE for decryption.

In this embodiment, it can be seen from the embodiment shown in FIG. 3 that, for the purpose of privacy protection, private data is encrypted and stored. At the same time, depending on the type of data contained in the private data, the encryption method used is also different. Therefore, after obtaining the target private data according to the hash value of the historical transaction, the obtained target private data is read into the TEE for decryption, so as to be obtained by the querying party.

When the target privacy data includes historical transactions, it can be seen from the embodiment shown in FIG. 3 that the historical transactions are encrypted using the symmetric key used by user A. Therefore, after obtaining the historical transaction, the symmetric key used by the user A can be obtained first, and then the historical transaction is decrypted by the symmetric key in the TEE, so as to obtain the historical transaction of the plaintext content. For obtaining the symmetric key used by user A, first obtain the symmetric key used to encrypt historical transactions (the symmetric key is encrypted by the public key used by user A), and pass the public key used with user A in the TEE The corresponding private key decrypts the symmetric key to obtain the decrypted symmetric key.

Step 620, the blockchain node verifies the from field of the historical transaction included in the query transaction.

In this embodiment, the address of the initiator recorded in the query transaction is filled in by the user B, so the address of the initiator should be understood as the address of the initiator of the historical transaction declared by the user B. However, the address of the actual initiator of the historical transaction may not necessarily be the address of the initiator declared by user B, that is, user B may forge it. Therefore, when it is determined that the query permission of user B is allowed to query, the blockchain node can further verify the address of the initiator of the historical transaction declared by user B, thereby ensuring the security of private data.

For example, after the blockchain node determines that user B's query permission is allowed to query, it can obtain historical transactions from the blockchain according to the hash value of the historical transaction (the certificate is stored on the blockchain), and read The content recorded in the from field of historical transactions. If the read from field content is the same as the from field declared in the query transaction, the verification is passed; otherwise, the verification fails. It should be noted that when it is determined that the query authority of the query party is forbidden to query, the above verification step is an unnecessary operation, so there is no need to perform the above verification step, thereby reducing the occupation of the processing resources of the blockchain node. In turn, the performance of blockchain nodes is improved.

Further, after the business contract is used to determine that user B's query authority is forbidden to query, a contract receipt regarding user B's prohibition of querying target private data can be generated for user B to view. Or, the blockchain node returns to user B a query-forbidden receipt to inform user B that the query permission is forbidden to query.

In step 622, the blockchain node uses the user B's symmetric key to encrypt the acquired historical transaction.

In step 624, user B views historical transactions.

In one embodiment, after the blockchain node encrypts the historical transaction, it can generate an event containing the historical transaction and store it in the blockchain log. Then, user B can use the client to use the callback mechanism of the blockchain to Obtain the event to view historical transactions. After obtaining the historical transaction, user B uses the symmetric key used by the client to decrypt the historical transaction to obtain the historical transaction in plain text.

In another embodiment, after the blockchain node encrypts the historical transaction, it can directly return the encrypted historical transaction to the client terminal used by the user B. In the same way, user B uses the symmetric key used by the client to decrypt the historical transaction to obtain the historical transaction of the plaintext content.

It should be noted that the query authority for other transaction-related data is controlled by the initiator of the historical transaction (that is, controlled by the initiator’s blockchain account). For the specific implementation process, please refer to the above steps 602-624. The principles are similar here. No longer.

As shown in Figure 7, following the scenario shown in Figure 3 above, after user A initiates a transaction invoking the business contract, user A can share other transaction-related data that is different from the transaction to user B, or user B can view the other transaction The need for relevant data. Then, the process of user B as the inquiring party inquiring the target private data may include the following steps.

In step 702, the user B creates a query transaction through the client terminal used.

In this embodiment, the to field of the query transaction records the contract address of the distribution contract. At the same time, the hash value (ie transaction ID) and the from field of the historical transaction can also be recorded in the data field (or other fields) of the query transaction. The content (the address of the initiator of the historical transaction) and the content of the to field (the contract address of the business contract called by the historical transaction). Among them, the hash value of the historical transaction, the address of the initiator, and the contract address of the business contract can be obtained by offline sharing between user B and user A, or obtained by any other means.

In step 704, the user B uses the digital envelope encryption to query the transaction through the client.

Step 706: User B initiates a query transaction to the blockchain node through the client.

In step 708, the blockchain node decrypts the query transaction in the TEE.

In this embodiment, the encryption and decryption processes of steps 704-708 are similar to steps 604-608 in the embodiment shown in FIG. 6, and will not be repeated here.

Step 710: The blockchain node determines that the received transaction is a query transaction for invoking the distribution contract.

In this embodiment, after receiving any transaction, the blockchain node reads the content of the to field of the transaction. When the content of the to field is the contract address of the distribution contract, it means that the transaction is used to call the distribution contract, and then it can be determined that the transaction is a query transaction.

Step 712, the blockchain node invokes the distribution contract.

Step 714: The distribution contract determines the business contract invoked by the historical transaction according to the to field of the historical transaction recorded in the query transaction.

Step 716: Distribute the contract and call the business contract.

In step 718, the business contract determines the query authority of the user B according to the from field of the query transaction and the from field of the historical transaction.

In this embodiment, the identity information of the inquiring party and the initiator of the historical transaction are jointly used as the basis for permission control as an example. For example, the permission control rules (defined in the business contract in the form of permission control codes) record the query group and the queried group, and members belonging to the query group are allowed to view the private data of the queried group members; or, directly record in the permission control rules Each user can view the corresponding relationship of which other users. Among them, the account address is used as the user's identity information. Then, the blockchain node executes the authority control code defined in the business contract to determine according to the account address of the querying party (the content of the from field of the query transaction) and the account address of the initiator of the historical transaction (the content of the from field of the historical transaction) User B's query authority.

Step 720: The business contract returns user B's query authority to the blockchain node.

Step 722: After determining that the query permission of user B is allowed to query, the blockchain node verifies the from field and 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 query transaction are filled in by user B. Therefore, the address of the initiator should be understood as the address of the initiator of the historical transaction declared by user B. The contract The address should be understood as the contract address of the business contract called by the historical transaction declared by user B. However, the address of the actual initiator of the historical transaction is not necessarily the address of the initiator declared by user B, and the contract address of the business contract actually called by the historical transaction is not necessarily the address of the contract declared by user B, that is, user B forged Possible. For example, user B can deploy a business contract on the blockchain by deploying a business contract as described above. The permission control code defined in the business contract allows user B to view user A’s private data; then, user B can change The contract address of the business contract invoked by the historical transaction initiated by the user A is filled in as the contract address of the aforementioned business contract deployed by the user B. Therefore, when it is determined that the query permission of user B is allowed to query, the blockchain node can further verify the address of the initiator of the historical transaction declared by user B and the contract address, thereby ensuring the security of private data.

For example, after the blockchain node determines that user B's query permission is allowed to query, it can obtain historical transactions from the blockchain according to the hash value of the historical transaction (the certificate is stored on the blockchain), and read The content recorded in the from field of historical transactions and the to field of historical transactions. If the content of the read from field is the same as the content of the from field declared in the query transaction, the operation of obtaining the target privacy data can be further performed; otherwise, execution is prohibited. The operation of obtaining target private data. In the same way, if the content of the read to field is the same as the content of the to field declared in the query transaction, the operation of obtaining the target private data can be further performed; otherwise, the operation of obtaining the target private data is prohibited.

It should be noted that when it is determined that the query authority of the query party is forbidden to query, the above verification step is an unnecessary operation, so there is no need to perform the above verification step, thereby reducing the occupation of the processing resources of the blockchain node. In turn, the performance of blockchain nodes is improved.

Further, after the business contract is used to determine that the query permission of user B is forbidden to query, a contract receipt regarding the prohibition of user B from querying the target private data can be generated for user B to view. Or, the blockchain node returns to user B a query-forbidden receipt to inform user B that the query permission is forbidden to query.

In step 724, the blockchain node obtains other transaction-related data.

In step 726, the blockchain node reads other transaction-related data into the TEE for decryption.

In this embodiment, it can be seen from the embodiment shown in FIG. 3 that, for the purpose of privacy protection, private data is encrypted and stored. At the same time, depending on the type of data contained in the private data, the encryption method used is also different. Therefore, after obtaining the target private data (for example, other transaction-related data can be obtained according to the hash value of the historical transaction), the obtained target private data is read into the trusted execution environment for decryption, so as to be obtained by the querying party.

When the target privacy data includes the transaction receipt of the historical transaction, it can be seen from the embodiment shown in FIG. 3 that the transaction receipt of the historical transaction is encrypted by the symmetric key used by the initiator of the historical transaction. Therefore, after obtaining the transaction receipt of the historical transaction, the symmetric key used by the user A can be obtained first, and then the transaction receipt of the historical transaction can be decrypted by the symmetric key in the TEE. For the acquisition of the symmetric key used by the initiator, the symmetric key used to encrypt historical transactions (the symmetric key is encrypted by the public key used by user A) can be obtained first, and the public key used with user A can be used in the TEE The corresponding private key decrypts the symmetric key to obtain the decrypted symmetric key.

When the target privacy data includes at least one of user A's account attribute information, business contract account attribute information, business contract contract code, business contract contract status data, the specific symmetric key of the blockchain node can be passed in the TEE Decrypt these private data.

For example, the specific symmetric key can be a seal (Simple Encrypted Arithmetic Library) key, which can be sent to the blockchain node by the key management server after being remotely attested, or it can be between each blockchain node After negotiation, the blockchain node uses the seal key to encrypt and decrypt private data. Of course, after remote certification, the key management server sends the symmetric key to the blockchain node, or the symmetric key negotiated between the various blockchain nodes may not be the above-mentioned seal key, but the root key (root key). ), and the above-mentioned seal key may be a derived key of the root key. For example, the root key can irreversibly derive several versions of derived keys in turn, and any two adjacent keys can irreversibly derive a low version key from a higher version key, thereby forming a chained key Derivative structure. For example, if you need to derive 256 versions of keys with version numbers ranging from 0 to 255, you can use the root key and the version factor of 0xFF (the decimal value is 255, that is, the version number of the key that needs to be generated; of course, You can also use other values) for hash calculation to obtain the key key-255 with the version number 255; by hashing the key key-255 and the version factor 0xFE, the key key- with the version number 254 is obtained. 254; ... By hashing the key key-1 and the version factor 0x00, the key key-0 with the version number of 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 key-0 can be calculated from the key key-1 and the version factor 0x00, but the key cannot be passed through the key. -0 and version factor 0x00 deduces the key key-1.

Then, a certain version of the derived key can be designated as the above-mentioned seal key to encrypt private data. Further, the seal key can also be version updated, and based on the above-mentioned features, it should be updated from the lower version key to the higher version key, so that even if the lower version key is leaked, the higher version key cannot be reversed. Version key to ensure sufficient data security.

In step 728, the blockchain node uses user B's symmetric key to encrypt other transaction-related data.

In step 730, user B views other transaction related data.

In one embodiment, after the blockchain node encrypts other transaction-related data, it can generate an event containing the other transaction-related data and store it in the blockchain log. Then, user B can use the client to pass the blockchain The callback mechanism to obtain the event, so as to view other transaction-related data. After obtaining other transaction-related data, user B uses the symmetric key used by the client to decrypt other transaction-related data to obtain other transaction-related data in plain text.

In another embodiment, after the blockchain node encrypts other transaction-related data, it can directly return the encrypted other transaction-related data to the client terminal used by user B. In the same way, user B uses the symmetric key used by the client to decrypt other transaction-related data to obtain other transaction-related data in plaintext content.

Of course, the query authority of historical transactions can also be controlled by the business contract invoked by the historical transaction, that is, controlled by the deployer of the business contract. For the specific implementation process of this control method, please refer to the above steps 702-730. The principles are similar here. No longer.

It can be seen that through the private data query scheme of this manual, user A does not need to share the symmetric key used by himself with user B, and can realize the sharing of private data between user A and user B, thereby improving security and convenience.

Corresponding to the above method embodiment, this specification also provides an embodiment of a privacy data query device based on a blockchain account.

The embodiments of the private data query device in this specification can be applied to electronic equipment. The device embodiments can be implemented by software, or can be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.

From a hardware perspective, please refer to FIG. 8, which is a schematic structural diagram of a device provided by an exemplary embodiment. As shown in FIG. 8, at the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810. Of course, it may also include hardware required for other services. The processor 802 reads the corresponding computer program from the non-volatile memory 810 to the memory 808 and then runs it to form a privacy data query device based on a blockchain account on a logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Please refer to FIG. 9, in the software implementation, the query device is applied to a blockchain node, and may include the following units.

The transaction reading unit 901, when receiving a query transaction for target privacy data initiated by the querying party, reads the transaction identifier of the historical transaction related to the target privacy data and the historical transaction information contained in the query transaction The identity information of the initiator.

The authority query unit 902 determines the blockchain account of the initiator according to the identity information of the initiator, and determines the query of the target privacy data by the query party according to the query authority recorded in the blockchain account Permissions.

The data acquisition unit 903, when the determined query authority is allowed to query, acquires the target privacy data and reads the acquired target privacy data into a trusted execution environment for decryption, so as to be acquired by the querying party.

Optionally, it further includes: a transaction identification unit 904, when any one of the received transactions is used for invoking a designated smart contract, the any one of the transactions is regarded as the query transaction.

Optionally, the target privacy data includes at least one of the following: the historical transaction, the transaction receipt corresponding to the historical transaction, the account attribute information of the initiator of the historical transaction, and the business contract invoked by the historical transaction The account attribute information of the business contract, the contract code of the business contract, and the contract status data of the business contract.

Optionally, the target privacy data includes the historical transaction and/or the transaction receipt; the data obtaining unit 903 is specifically configured to: obtain the symmetric key used by the initiator; in the trusted execution environment The symmetric key is used to decrypt the historical transaction and/or the transaction receipt.

Optionally, the data obtaining unit 903 is further configured to: obtain a symmetric key used to encrypt the historical transaction, the symmetric key being encrypted by the public key used by the initiator; in the trusted execution environment The private key corresponding to the public key used by the initiator is used to decrypt the symmetric key to obtain the decrypted symmetric key.

Optionally, the public key used by the initiator is sent to the initiator by the key management server through remote certification, and the trusted execution environment of the blockchain node is established by the SGX architecture, and corresponds to the public key The private key is sent to the circle of blockchain nodes by the key management server through remote certification.

Optionally, the target privacy data includes at least one of account attribute information of the initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, and contract status data of the business contract One; the data acquisition unit 903 is specifically configured to: decrypt the target private data through the specific symmetric key of the blockchain node in the trusted execution environment.

Optionally, the trusted execution environment of the blockchain node is established by the SGX architecture, and the specific symmetric key is sent by the key management server after the SGX architecture of the blockchain node is remotely certified, or is It is obtained through negotiation between the blockchain node and other blockchain nodes.

Optionally, the symmetric key used to encrypt the query transaction is encrypted by the public key used by the query party.

After receiving the query transaction, the device further includes: a transaction decryption unit 905, which encrypts the symmetry of the query transaction through a private key corresponding to the public key used by the query party in the trusted execution environment Key decryption: decrypt the query transaction using the symmetric key obtained by decryption to obtain the transaction content contained in the query transaction; after decrypting the target private data, the device further includes: a data encryption unit 906, The decrypted target private data is encrypted by the symmetric key of the inquiring party.

Optionally, after determining that the query permission is allowed to query, the device further includes: a transaction obtaining unit 907, which obtains the historical transaction according to the transaction identifier; and an identity determining unit 908, which determines the historical transaction according to the obtained historical transaction The identity information of the initiator of the historical transaction; the identity verification unit 909, when the determined identity information is inconsistent with the identity information of the initiator included in the query transaction, the operation of obtaining the target private data is prohibited.

Optionally, it further includes: a privacy processing unit 910, when the determined query authority is query prohibition, generate a contract receipt indicating that the query party prohibits querying the target private data for viewing by the query party.

Optionally, a whitelist is configured in the blockchain account of the initiator, and the query permission of the user recorded in the whitelist for the private data of the initiator is permitted query; the permission query unit 902 specifically uses Yu: When the querying party is recorded in the whitelist, it is determined that the querying authority of the querying party for the target private data is allowed to query.

Optionally, it further includes: a transaction receiving unit 911, which receives an update transaction for the whitelist initiated by the initiator; an update unit 912, which performs an update on the whitelist according to the update content of the whitelist included in the update transaction. The whitelist is updated.

Optionally, a query condition for the privacy data of the initiator is recorded in the blockchain account of the initiator; the authority query unit 902 is specifically configured to: when the identity information of the query party meets the query When the condition is used, it is determined that the query authority of the query party for the target private data is allowed to query.

Correspondingly, this specification also provides an embodiment of a device for querying private data.

The embodiments of the private data query device in this specification can be applied to electronic equipment. The device embodiments can be implemented by software, or can be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.

From a hardware perspective, please refer to FIG. 10, which is a schematic structural diagram of a device provided by an exemplary embodiment. As shown in FIG. 10, at the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, and of course, it may also include hardware required for other services. The processor 1002 reads the corresponding computer program from the non-volatile memory 1010 to the memory 1008 and then runs it, forming a private data query device on a logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Please refer to FIG. 11, in the software implementation, the privacy data query device is applied to the blockchain node, which may include:

The transaction reading unit 1101, when receiving a query transaction for target privacy data sent by the querying party, reads the transaction identifier of the historical transaction related to the target privacy data and the historical transaction information contained in the query transaction The identity information of the initiator;

The first authority query unit 1102, when the target privacy data is the historical transaction, determines the initiator’s blockchain account according to the identity information of the initiator, and according to the information recorded in the blockchain account The query authority determines the query authority of the query party for the historical transaction;

The second authority query unit 1103, when the target privacy data is other transaction-related data that is different from the historical transaction, reads the contract address of the business contract called by the historical transaction contained in the query transaction, and reads it according to Acquiring the business contract by the contract address, and executing the authority control code defined in the business contract to determine the query authority of the query party for the target private data;

The data acquisition unit 1104, when the determined query authority is allowed to query, acquires the target private data and reads the acquired target private data into a trusted execution environment for decryption, so as to be obtained by the querying party.

Optionally, the other transaction-related data includes at least one of the following:

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

The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.

For the convenience of description, when describing the above device, the functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in one or more software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

The present invention is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

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

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram. In a typical configuration, the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.

Computer-readable media includes permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or they also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that, although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determination".

The foregoing descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.

Claims (36)

1. A method for querying private data based on a blockchain account, which is applied to a blockchain node; the method includes:

   When receiving a query transaction for target privacy data initiated by the querying party, read the transaction identifier of the historical transaction related to the target privacy data and the identity information of the initiator of the historical transaction included in the query transaction;

   Determine the blockchain account of the initiator according to the identity information of the initiator, and determine the query authority of the query party for the target private data according to the query authority recorded in the blockchain account;

   When the determined query authority is query permission, the target privacy data is acquired and the acquired target privacy data is read into a trusted execution environment for decryption, so that the query party can obtain it.
2. The method according to claim 1, further comprising:

   When any transaction received is used to call a designated smart contract, the any transaction is regarded as the query transaction.
3. The method according to claim 1, wherein the target privacy data includes at least one of the following:

   The historical transaction, the transaction receipt corresponding to the historical transaction, the account attribute information of the initiator of the historical transaction, the account attribute information of the business contract called by the historical transaction, the contract code of the business contract, the The contract status data of the business contract.
4. The method according to claim 3, wherein the target privacy data includes the historical transaction and/or the transaction receipt; the reading the acquired target privacy data into a trusted execution environment for decryption includes:

   Acquiring the symmetric key used by the initiator;

   The historical transaction and/or the transaction receipt are decrypted by the symmetric key in the trusted execution environment.
5. The method according to claim 4, said obtaining the symmetric key used by the initiator comprises:

   Obtaining a symmetric key used to encrypt the historical transaction, the symmetric key being encrypted by the public key used by the initiator;

   In the trusted execution environment, the symmetric key is decrypted by the private key corresponding to the public key used by the initiator to obtain the decrypted symmetric key.
6. According to the method of claim 5, the public key used by the initiator is sent to the initiator by the key management server through remote certification, and the trusted execution environment of the blockchain node is established by the SGX architecture, and The private key corresponding to the public key is sent to the circle of blockchain nodes by the key management server through remote certification.
7. The method according to claim 3, wherein the target privacy data includes account attribute information of the initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, and contract of the business contract At least one of the status data; said reading the acquired target privacy data into a trusted execution environment for decryption, including:

   The target private data is decrypted through the specific symmetric key of the blockchain node in the trusted execution environment.
8. According to the method of claim 7, the trusted execution environment of the blockchain node is established by the SGX architecture, and the specific symmetric key is certified by the key management server after the SGX architecture of the blockchain node is remotely certified Sent, or negotiated between the blockchain node and other blockchain nodes.
9. The method according to claim 1, wherein the symmetric key used to encrypt the query transaction is encrypted by the public key used by the query party;

   After receiving the query transaction, the method further includes: decrypting the symmetric key that encrypts the query transaction by using a private key corresponding to the public key used by the query party in the trusted execution environment, and The decrypted symmetric key decrypts the query transaction to obtain the transaction content included in the query transaction;

   After decrypting the target private data, the method further includes: encrypting the decrypted target private data with the symmetric key of the querying party.
10. The method according to claim 1, after determining that the query permission is allowed to query, the method further comprises:

    Acquiring the historical transaction according to the transaction identifier;

    Determine the identity information of the initiator of the historical transaction according to the acquired historical transaction;

    When the determined identity information is inconsistent with the identity information of the initiator included in the query transaction, the operation of obtaining the target private data is prohibited.
11. The method according to claim 1, further comprising:

    When the determined query authority is query prohibition, a contract receipt indicating that the query party prohibits the query of the target private data is generated to be viewed by the query party.
12. The method according to claim 1, wherein a whitelist is configured in the blockchain account of the initiator, and the query permission of the users recorded in the whitelist for the private data of the initiator is allowed to query; the basis The query authority recorded in the blockchain account determines the query authority of the query party for the target private data, including:

    When the querying party is recorded in the whitelist, it is determined that the querying authority of the querying party for the target private data is allowed to query.
13. The method according to claim 12, further comprising:

    Receiving an update transaction for the whitelist initiated by the initiator;

    The white list is updated according to the updated content of the white list included in the update transaction.
14. The method according to claim 1, wherein a query condition for the privacy data of the initiator is recorded in the blockchain account of the initiator; and the query authority is determined according to the query authority recorded in the blockchain account. The query authority of the querying party for the target private data includes:

    When the identity information of the querying party meets the query condition, it is determined that the querying authority of the querying party for the target private data is allowed to query.
15. A method for querying private data, applied to a blockchain node; the method includes:

    When receiving a query transaction for target privacy data sent by the querying party, read the transaction identifier of the historical transaction related to the target privacy data and the identity information of the initiator of the historical transaction included in the query transaction;

    When the target privacy data is the historical transaction, determine the initiator’s blockchain account according to the identity information of the initiator, and determine the query policy according to the query authority recorded in the blockchain account Query authority for the historical transaction;

    When the target privacy data is other transaction-related data that is different from the historical transaction, read the contract address of the business contract called by the historical transaction contained in the query transaction, and obtain the contract address according to the contract address A business contract, and execute the authority control code defined in the business contract to determine the query authority for the target private data;

    When the determined query authority is query permission, the target privacy data is acquired and the acquired target privacy data is read into a trusted execution environment for decryption, so that the query party can obtain it.
16. The method according to claim 15, wherein the other transaction-related data includes at least one of the following:

    Corresponding to the transaction receipt of the historical transaction, the account attribute information of the initiator of the historical transaction, the account attribute information of the business contract, the contract code of the business contract, and the contract status data of the business contract.
17. A privacy data query device based on a blockchain account, applied to a blockchain node; the device includes:

    The transaction reading unit reads the transaction identifier of the historical transaction related to the target privacy data and the initiation of the historical transaction that are included in the query transaction and the transaction identification of the historical transaction related to the target privacy data when receiving the query transaction for the target private data initiated by the querying party Party’s identity information;

    The authority query unit determines the blockchain account of the initiator according to the identity information of the initiator, and determines the query authority of the query party for the target private data according to the query authority recorded in the blockchain account ；

    The data acquisition unit, when the determined query authority is query permission, acquires the target privacy data and reads the acquired target privacy data into a trusted execution environment for decryption, so that the query party can acquire it.
18. The device according to claim 17, further comprising:

    The transaction identification unit, when any received transaction is used to call a designated smart contract, uses the any transaction as the query transaction.
19. The device according to claim 17, wherein the target privacy data includes at least one of the following:

    The historical transaction, the transaction receipt corresponding to the historical transaction, the account attribute information of the initiator of the historical transaction, the account attribute information of the business contract called by the historical transaction, the contract code of the business contract, the The contract status data of the business contract.
20. The device according to claim 19, wherein the target privacy data includes the historical transaction and/or the transaction receipt; the data acquisition unit is specifically configured to:

    Acquiring the symmetric key used by the initiator;

    The historical transaction and/or the transaction receipt are decrypted by the symmetric key in the trusted execution environment.
21. According to the device of claim 20, the data acquisition unit is further configured to:

    Obtaining a symmetric key used to encrypt the historical transaction, the symmetric key being encrypted by the public key used by the initiator;

    In the trusted execution environment, the symmetric key is decrypted by the private key corresponding to the public key used by the initiator to obtain the decrypted symmetric key.
22. According to the device of claim 21, the public key used by the initiator is sent to the initiator by the key management server through remote certification, and the trusted execution environment of the blockchain node is established by the SGX architecture, and The private key corresponding to the public key is sent to the circle of blockchain nodes by the key management server through remote certification.
23. The device according to claim 19, wherein the target privacy data includes account attribute information of the initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, and contract of the business contract At least one of the status data; the data acquisition unit is specifically configured to:

    The target private data is decrypted through the specific symmetric key of the blockchain node in the trusted execution environment.
24. The device according to claim 23, wherein the trusted execution environment of the blockchain node is established by the SGX architecture, and the specific symmetric key is certified by the key management server after the SGX architecture of the blockchain node is remotely certified Sent, or negotiated between the blockchain node and other blockchain nodes.
25. The device according to claim 17, wherein the symmetric key used to encrypt the query transaction is encrypted by the public key used by the query party;

    After receiving the query transaction, the device further includes: a transaction decryption unit, which encrypts the symmetric secret of the query transaction through a private key corresponding to the public key used by the query party in the trusted execution environment Key decryption, decrypt the query transaction using the symmetric key obtained by decryption, to obtain the transaction content contained in the query transaction;

    After decrypting the target private data, the device further includes: a data encryption unit, which encrypts the decrypted target private data by the symmetric key of the querying party.
26. The device according to claim 17, after determining that the query permission is allowed to query, the device further comprises:

    A transaction acquisition unit, which acquires the historical transaction according to the transaction identifier;

    The identity determining unit determines the identity information of the initiator of the historical transaction according to the acquired historical transaction;

    The identity verification unit prohibits performing the operation of obtaining the target privacy data when the determined identity information is inconsistent with the identity information of the initiator included in the query transaction.
27. The device according to claim 17, further comprising:

    The privacy processing unit, when the determined query authority is query prohibition, generates a contract receipt indicating that the query party prohibits querying the target private data for viewing by the query party.
28. The device according to claim 17, wherein a whitelist is configured in the blockchain account of the initiator, and the query permission of the user recorded in the whitelist for the private data of the initiator is allowed to query; the permission The query unit is specifically used for:

    When the querying party is recorded in the whitelist, it is determined that the querying authority of the querying party for the target private data is allowed to query.
29. The device according to claim 28, further comprising:

    A transaction receiving unit that receives an update transaction for the white list initiated by the initiator;

    The update unit updates the white list according to the update content of the white list included in the update transaction.
30. The device according to claim 17, wherein a query condition for the privacy data of the initiator is recorded in the blockchain account of the initiator; the authority query unit is specifically configured to:

    When the identity information of the querying party meets the query condition, it is determined that the querying authority of the querying party for the target private data is allowed to query.
31. A device for querying private data, applied to a blockchain node; the device includes:

    The transaction reading unit, when receiving a query transaction for target privacy data sent by the querying party, reads the transaction identifier of the historical transaction related to the target privacy data contained in the query transaction and the initiation of the historical transaction Party’s identity information;

    The first authority query unit, when the target privacy data is the historical transaction, determines the initiator’s blockchain account according to the identity information of the initiator, and according to the query recorded in the blockchain account Authority to determine the inquiry authority of the inquiry party for the historical transaction;

    The second authority query unit, when the target privacy data is other transaction-related data that is different from the historical transaction, reads the contract address of the business contract called by the historical transaction contained in the query transaction, and reads it according to the Acquiring the business contract by the contract address, and executing the authority control code defined in the business contract to determine the query authority of the query party for the target private data;

    The data acquisition unit, when the determined query authority is query permission, acquires the target privacy data and reads the acquired target privacy data into a trusted execution environment for decryption, so that the query party can acquire it.
32. The device according to claim 31, wherein the other transaction-related data includes at least one of the following:

    Corresponding to the transaction receipt of the historical transaction, the account attribute information of the initiator of the historical transaction, the account attribute information of the business contract, the contract code of the business contract, and the contract status data of the business contract.
33. An electronic device including:

    processor;

    A memory for storing processor executable instructions;

    Wherein, the processor executes the executable instruction to implement the method according to any one of claims 1-14.
34. An electronic device including:

    processor;

    A memory for storing processor executable instructions;

    Wherein, the processor implements the method according to claim 15 or 16 by running the executable instruction.
35. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-14.
36. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implements the steps of the method as claimed in claim 15 or 16.

Images