CN111523110B - Authority query configuration method and device based on chain codes - Google Patents

Abstract

One or more embodiments of this specification provide a chaincode-based permission query configuration method and device; the method is applied to blockchain nodes, and may include: reading the obtained distribution code into a trusted execution environment to The chain code maintained in the above-mentioned trusted execution environment is updated, and the distribution code is used to call the business contract called by the historical transaction to execute the transaction when the query party receives the query transaction of the private data related to the historical transaction The authority control code defined in the above-mentioned business contract determines the inquiry authority of the inquiring party; when receiving the verification request for the distribution code initiated by the challenger, read the distribution code maintained in the trusted execution environment to generating a verification report, and sending the verification report to the challenger, so that the challenger verifies the distribution code in the trusted execution environment according to the verification report.

Description

Method and device for permission query configuration based on chain code

technical field

One or more embodiments of this specification relate to the technical field of blockchain, and in particular to a chaincode-based authority query configuration method and device.

Background technique

Blockchain technology is built on top of transmission networks such as peer-to-peer networks. 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 the technology of enterprise-level blockchain platforms are privacy and performance, and it is often difficult to solve these two challenges at the same time. Most solutions trade for privacy by losing performance, or pursue performance with little regard for privacy. Common encryption technologies to solve privacy problems, such as Homomorphic encryption and zero-knowledge proof, are highly complex, poor in versatility, and may cause serious performance loss.

Trusted Execution Environment (TEE) is another way to solve the privacy problem. TEE can function as a black box in the hardware, and the code and data operating system layer executed in the TEE cannot be peeked at, and only the predefined interface in the code can operate on it. In terms of efficiency, due to the black-box nature of TEE, plaintext data is used for operations in TEE, rather than complex cryptographic operations in homomorphic encryption, and there is no loss in the efficiency of the calculation process. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about TEE solutions. 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 AMDPSP (Platform Security Processor, Platform Security Processor).

Contents of the invention

In view of this, one or more embodiments of this specification provide a smart contract-based permission query configuration method and device, electronic equipment, and a storage medium.

In order to achieve the above purpose, one or more embodiments of this specification provide technical solutions as follows:

According to the first aspect of one or more embodiments of this specification, a chaincode-based permission query configuration method is proposed, which is applied to blockchain nodes; the method includes:

Read the obtained distribution code into the trusted execution environment to update the chain code maintained in the trusted execution environment, and the distribution code is used for querying the privacy data related to the historical transaction by the party receiving the query During the transaction, call the business contract called by the historical transaction to execute the authority control code defined in the business contract, and determine the inquiry authority of the inquiring party;

When receiving a verification request for the distribution code initiated by the challenger, read the distribution code maintained in the trusted execution environment to generate a verification report, and send the verification report to the challenger, so that the The challenger verifies the distribution code in the trusted execution environment according to the verification report.

According to the second aspect of one or more embodiments of this specification, a private data query method is proposed, which is applied to blockchain nodes; the method includes:

When receiving the query transaction of the privacy data related to the historical transaction submitted by the querying party, read the distribution code maintained in the trusted execution environment, and the distribution code is part of the chain code maintained in the trusted execution environment;

Execute the distribution code in the trusted execution environment to determine the query authority of the inquiring party according to the authority control code defined in the business contract invoked by the historical transaction;

When it is determined that the query authority is allowed to query, the decrypted private data is obtained for viewing by the querying party, and the private data is read into a trusted execution environment for decryption.

According to a third aspect of one or more embodiments of this specification, a chaincode-based permission query configuration device is proposed, which is applied to blockchain nodes; the device includes:

The first update unit reads the obtained distribution code into the trusted execution environment, so as to update the chain code maintained in the trusted execution environment, and the distribution code is used for the transaction related to the historical transaction when the query is received. When inquiring about private data of private data, call the business contract invoked by the historical transaction to execute the authority control code defined in the business contract, and determine the inquiry authority of the inquiring party;

The verification unit reads the distribution code maintained in the trusted execution environment to generate a verification report when receiving a verification request for the distribution code initiated by the challenger, and sends the verification report to the challenger, so that the challenger verifies the distribution code in the trusted execution environment according to the verification report.

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 blockchain nodes; the device includes:

The code reading unit reads the distribution code maintained in the trusted execution environment when receiving the query transaction of the private data related to the historical transaction submitted by the querying party, and the distribution code belongs to the distribution code maintained in the trusted execution environment part of the chaincode;

an authority determining unit, executing the distribution code in the trusted execution environment to determine the inquiry authority of the inquiring party according to the authority control code defined in the business contract invoked by the historical transaction;

The data obtaining unit obtains the decrypted private data to be viewed by the querying party when the determined query authority is allowed to query, and the private data is read into a trusted execution environment for decryption.

According to a fifth aspect of one or more embodiments of the present specification, an electronic device is provided, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to the first aspect by running the executable instruction.

According to a sixth aspect of one or more embodiments of the present specification, an electronic device is provided, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to the second aspect by running the executable instruction.

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

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

Description of drawings

Fig. 1 is a schematic diagram of creating a smart contract provided by 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 service contract provided by an exemplary embodiment.

Fig. 4A is a flowchart of a chaincode-based permission query configuration method provided by an exemplary embodiment.

Fig. 4B is a flowchart of a private data query method provided by an exemplary embodiment.

Fig. 5 is a schematic diagram of remote attestation for distributed codes provided by an exemplary embodiment.

6-7 are flowcharts of another private data query method 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 an apparatus for querying private data provided by 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 another device for querying private data provided by an exemplary embodiment.

Detailed ways

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

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

Blockchains 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 combinations. Among them, the public chain has the highest degree of decentralization. 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 bookkeeping rights of new blocks. Moreover, each participant (ie node) can freely join and exit the network and perform related operations. On the contrary, the private chain, 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. The alliance chain is a blockchain between the public chain and the private chain, which can realize "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; participants join the network through authorization and form an alliance of stakeholders to jointly maintain the operation of the blockchain.

Whether it is a public chain, a private chain or an alliance chain, it is possible to provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered by transactions on the blockchain system. Smart contracts can be defined in the form of code.

Taking Ethereum as an example, it supports users to create and invoke some complex logic in the Ethereum network, which 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 each Ethereum node can run the EVM. EVM is a Turing-complete virtual machine, which means that various complex logic can be implemented through it. Users publish and call smart contracts in Ethereum that run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as “bytecode”). Smart contracts deployed on the blockchain can be in the form of bytecode.

For example, as shown in Figure 1, after Bob sends a transaction containing information about creating a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. "0x6f8ae93..." in Figure 1 represents the address of the contract, the data field of the transaction can store bytecode, and the to field of the transaction is empty. After the nodes reach a consensus 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 saved in the contract account. The behavior of smart contracts is controlled by the contract code. In other words, the smart contract makes a virtual account containing contract code and account storage (Storage) generated on the blockchain.

As shown in Figure 2, still taking Ethereum as an example, after Bob sends a transaction for calling a smart contract to the Ethereum network, the EVM of a certain node can execute this 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 saved in the data field of the transaction. Smart contracts are independently executed by each node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will store data that cannot be tampered with and will not be tampered with. Lost transaction credentials.

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, relevant 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 nodes executing transactions can include the following:

The Result field indicates the execution result of the transaction;

The Gas used field indicates the gas value consumed by the transaction;

The Logs field indicates the log generated by the transaction. The log can further include the From field, To field, Topic field, and Log data field, etc., where the From field represents the account address of the initiator of the call, and the To field represents the called object (such as a smart contract) account address, the Topic field represents the subject of the log, and the Log data field represents the 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 receipt fields contained in the receipt data, without the settings and capabilities of privacy protection. 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 data collection organized in a specific logic and stored in the database of the node. 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 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 made public. In some cases, some content may even need to be retrieved to drive The implementation of relevant 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 calling a business contract, and sends the created transaction to the blockchain node.

User A can call 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 encrypt the created transaction by means of digital envelope encryption, which combines symmetric encryption algorithm and asymmetric encryption algorithm. Specifically, use a symmetric encryption algorithm to encrypt the transaction content (that is, use the symmetric key used by itself to encrypt the transaction content), and then use the public key of the asymmetric encryption algorithm to encrypt the symmetric key.

Step 304, the blockchain node executes the business contract.

After the blockchain node receives the encrypted transaction, it reads the transaction into the TEE, first uses the private key of the asymmetric encryption algorithm to decrypt to obtain the symmetric key, and then uses the decrypted symmetric key to decrypt the transaction Get the transaction content, and then execute the business code of the business contract inside the TEE.

Step 306, the blockchain node stores the privacy data related to the transaction.

On the one hand, after the blockchain node receives the transaction, (after passing the consensus) it will publish the transaction (encrypted in the form of a digital envelope) to the blockchain for deposit. On the other hand, after the blockchain node executes the transaction, it will also encrypt and store the relevant data obtained by executing the transaction (publish it on the blockchain for deposit, 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 transaction contract can be encrypted with a specific symmetric key inside the TEE. In addition, data such as account attribute information of user A, account attribute information of business contracts, and contract codes of business contracts can also be encrypted using a specific symmetric key inside the TEE. The data encrypted by the aforementioned blockchain nodes all belong to the private data of user A on the blockchain, that is, the private data related to the transaction created by user A in step 302 .

In the above-mentioned privacy protection scenario, users may need to share their private data related to the business realized by using the blockchain to some specific users for viewing, that is, these specific users can view the privacy data related to the historical transactions initiated by the user. data. Then, the query permission can be set for the user's private data, so that other users who are allowed to query can view it. Therefore, the chain code can be improved to configure the permission query function for private data on the blockchain. The chaincode-based permission query configuration scheme of this manual will be described below in conjunction with FIG. 4A .

Please refer to FIG. 4A . FIG. 4A is a flowchart of a chaincode-based permission query configuration method provided by an exemplary embodiment. As shown in Figure 4A, the method is applied to blockchain nodes and may include the following steps:

Step 402A, read the obtained distribution code into the trusted execution environment, so as to update the chain code maintained in the trusted execution environment, and the distribution code is used to verify the privacy related to the historical transaction by the party receiving the query. During data query transactions, call the business contract invoked by the historical transaction to execute the authority control code defined in the business contract to determine the query authority of the querying party.

In this embodiment, when developing a 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 private data related to the transaction that calls the business contract in the business contract, so as to determine Whether the query party for the private data is allowed to query. Through the above method of defining the authority control code in the business contract, the private data can be associated with the authority control code that controls the query authority of the private data, so that each business contract can control the private data related to the transaction that calls itself. Among them, the type of privacy data may include at least one of the following: historical transactions, transaction receipts corresponding to historical transactions, account attribute information of initiators of historical transactions, account attribute information of business contracts invoked by historical transactions, and contract codes of business contracts , The contract status data of the business contract.

The development and deployment of business contracts can be completed by roles such as blockchain users, blockchain members, and blockchain administrators. Taking the consortium chain as an example, the blockchain members (or blockchain users, administrators) with bookkeeping authority set the authority control rules, and define the authority control rules in the form of authority control codes in the business contract (also business code is defined). After completing the development of the business contract, the blockchain member can publish the business contract to the consortium chain through any node device in the consortium chain, and the member node device designated by the part of the consortium chain in the business contract (For example, several authoritative node devices with bookkeeping authority specified in the consortium chain) After the consensus is completed, it will be included in the distributed database (ie, distributed ledger) of the consortium chain. Based on the above method of deploying business contracts, the deployer of the business contract (that is, an ordinary user or ordinary member with accounting authority) can control whether other people are allowed to query 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 rights of each round of accounting cycle; for example, Proof of Work (POW), Proof of Stake (POS), appointment Delegated Proof of Stake (DPOS) and other consensus algorithms;

The second type of consensus algorithm is a consensus algorithm that pre-elects accounting nodes for each round of accounting cycle (no need to compete for accounting rights); for example, consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT).

In the blockchain network using the first type of consensus algorithm, the node devices competing for the bookkeeping right can execute the transaction after receiving the transaction. Among the node devices competing for bookkeeping rights, there may be a node device that wins the current round of competition for bookkeeping rights and becomes a 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 equipment with bookkeeping rights has been agreed before the current round of bookkeeping. Therefore, after the node device receives the transaction, if it is not the accounting node of the current round, it can send the transaction to the accounting node. For the bookkeeping nodes of this round, 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 the blockchain adopts, the bookkeeping nodes of this round can package the received transactions to generate the latest block, and will generate the latest block or the latest block The block header 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 verify that there is no problem, 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 bookkeeping node, other nodes can also execute the transactions contained in the block.

Based on the above method of deploying business contracts for controlling query permissions, each business contract (including update contracts) only controls the query permissions of private data related to the transaction calling itself. Therefore, when a user (as a query party) initiates a query transaction for private data related to historical transactions (initiated by any other user), the blockchain node needs to determine the business contract that controls the query authority of private data, Then the business contract can be invoked to implement authority control.

For the method of calling the business contract of the blockchain node to realize the permission control, the distribution code can be configured in the chain code of the blockchain node to identify whether the transaction received by the blockchain node is a query transaction, and when the transaction is received When the transaction is a query transaction, the corresponding business contract is further invoked to execute the authority control code (which can be understood as distributing the query transaction to the corresponding business contract). For example, after the distribution code is developed, a push to configure the distribution code can be sent to each blockchain node through a specific server, so that the blockchain node can obtain the distribution code from the server. Of course, the blockchain node can obtain the distribution code and update the version of the chain code through any other way of configuring the distribution code.

Specifically, a specific call address can be configured for the distribution code to identify query transactions. In other words, the query transaction created by the query party is a transaction used to call the distribution code; then, when any transaction received by the blockchain node calls the distribution code through the specific call address, any transaction can be used as a query transaction. Taking Ethereum as an example, the inquiring party can write the specific calling address in the to field of the querying transaction, then when the blockchain node receives the querying transaction, it can recognize the receiving address according to the specific calling address recorded in the to field The transaction is a query transaction, and then the distribution code is executed to call the corresponding business contract. By solidifying the distribution logic of the above-mentioned "distribution query transaction" into the chain code in the form of distribution code, and releasing it together with the chain code, there is no need for the administrator to deploy it later, and the contract code is solidified in the chain code, so that the contract code can be control, effectively improving safety. In other words, the operation of distributing the query transaction to the corresponding business contract is completed by the blockchain node itself without calling the smart contract.

In this embodiment, in addition to configuring the distribution code in the chain code, the version of the chain code on the blockchain node can also be updated, so as to cooperate with the configured distribution code to complete the process of permission query. For example, after developing a new version of the chain code, a chain code upgrade push can be sent to each blockchain node through a specific server, so that the blockchain node can obtain the new version of the chain code from the server, and then according to the acquired The new version of the chain code updates the chain code (maintained in the TEE). Of course, any other way to update the chain code can also be used to make the blockchain node obtain the new version of the chain code for version update.

In one case, when the querying party constructs the querying transaction, it may only write in the querying transaction the transaction identification of the historical transaction related to the privacy data to be queried. Wherein, the transaction identifier of the historical transaction may be obtained by offline sharing between the initiator and the inquiring party of the historical transaction, or obtained by any other method. In this case, the new version of the chain code is used to obtain the historical transaction according to the transaction identifier contained in the query transaction, and determine the business contract called by the historical transaction based on the obtained historical transaction; the distribution code is used to call the new version of the chain code The business contract determined by the code is used to execute the authority control code defined in the called business contract.

Taking Ethereum as an example, when creating a query transaction, the inquiring party can record the hash value of the historical transaction notified by the originator of the historical transaction (as a transaction identifier) in the data field of the querying transaction. Then, when the blockchain node (updated chain code) receives the query transaction, it executes the new version of the chain code to obtain the historical transactions stored on the blockchain according to the hash value, and then according to the to field of the historical transaction (The contract address of the smart contract used to record the call) Determine the business contract called by the historical transaction. After the blockchain node determines the business contract called by the historical transaction, it executes the distribution code to call the determined business contract to execute the authority control code.

In another case, when constructing a query transaction, the querying party can write in the query transaction the transaction identifier of the historical transaction related to the private data to be queried, and the contract address of the business contract invoked by the historical transaction; among them, The transaction identifier of the historical transaction and the contract address of the business contract can be obtained by offline sharing between the initiator and the inquiring party of the historical transaction, or by any other means. In this case, the distribution code is used to determine the corresponding business contract according to the contract address of the business contract called by the historical transaction contained in the query transaction, and call the determined business contract to execute the corresponding authority control code to determine the query of the querying party. authority. It should be noted that the query transaction is created by the query party, and the contract address of the business contract called by the historical transaction included in the query transaction is declared by the query party, so the contract address is not necessarily the contract of the business contract actually called by the historical transaction Address, that is, there is a risk that the inquiring party forges the contract address. Therefore, when it is determined through the business contract that the query authority of the querying party is allowed to query, the new version of the chain code is used to obtain the historical transaction according to the transaction identifier contained in the query transaction (that is, the transaction ID, usually the hash value of the transaction), and Determine the contract address of the business contract actually invoked by the historical transaction according to the obtained historical transaction. When the determined contract address is inconsistent with the contract address of the business contract invoked by the historical transaction included in the query transaction, it is determined that the query authority of the query party is to prohibit query, which can effectively exclude the query party from stealing user privacy data by forging the contract address Case.

Furthermore, when it is finally determined that the inquiry authority of the inquiring party is allowed to inquire, the new version of the chain code is also used to obtain the decrypted private data for viewing by the inquiring party; wherein, the private data is read into the trusted execution environment for decryption. For example, the private data can be obtained according to the transaction identifier of the historical transaction included in the query transaction, and the obtained private data can be read into the trusted execution environment for decryption, so as to be obtained by the querying party. In other words, when it is finally determined that the inquiry authority of the inquiring party is allowed to inquire, the blockchain node executes the new version code to obtain private data for the inquiring party to view.

In this embodiment, the authority control rules defined in the form of authority 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 authority control rules. In one case, the identity information of the inquiring party can be used as the basis for authority control. Correspondingly, when the querying party creates a querying transaction, the querying transaction should include the identity information of the querying 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 can be recorded in the from field of the inquiring transaction. Further, the authority control rule can be set to allow the querying party to query corresponding private data when the identity information of the querying party meets certain conditions. For example, when the inquiring party belongs to a pre-designated query user set, it can be determined that the querying authority of the inquiring party is allowed to query, or when the credit score of the inquiring party exceeds the preset credit threshold, it can be determined that the inquiring party’s querying authority is allowed query and so on. Therefore, when determining the inquiry authority of the inquiring party, the authority control code defined in the business contract can be executed to determine the inquiring party's inquiry authority for private data according to the identity information of the inquiring party.

In another case, the identity information of the inquiring party and the initiator of historical transactions can be used together as the basis for authority control. 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 certain 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 corresponding relationship of which other users can be viewed by each user; or When the inquiring party and the initiating party belong to the same team, it can be determined that the inquiry authority of the inquiring party is permission to inquire and so on. Therefore, when determining the inquiry authority of the inquiring party, the authority control code defined in the business contract can be executed to determine the inquiring party's inquiry authority for private data according to the identity information of the inquiring party and the identity information of the initiator. Among them, the query party can write the identity information of the originator of the historical transaction in the created query transaction, or the blockchain node (by executing the new version of the chain code) can obtain the historical transaction according to the transaction identifier contained in the query transaction, and based on The obtained historical transactions are obtained.

In yet another case, the identity information of the originator of the historical transaction can be used as the basis for authority control. Then, the authority control rule can be set to allow the inquiring party to query the corresponding private data when the identity information of the originating party meets certain conditions. For example, when the originator belongs to the pre-designated set of users who can be queried, it can be determined that the inquiry authority of the inquiring party is allowed to inquire, or when the credit score of the initiator exceeds the preset credit threshold, it can be determined that the inquiry authority of the inquiring party is 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 querying authority for private data according to the identity information of the initiator.

When the authority control basis includes the identity information of the initiator of the historical transaction, since the identity information of the initiator contained in the query transaction is only the identity information declared by the querying party, the identity information is not necessarily the actual information of the initiator of the historical transaction. identity information, that is, there is a risk that the query party forges the identity information of the originator. Therefore, the verification logic for the identity information of the initiator of the historical transaction contained in the query transaction can be added to the new version of the chain code executed by the blockchain node, that is, when the query permission of the query party is determined to be allowed according to the permission control code After the query, the blockchain node (by executing the new version of the chain code) can obtain the historical transaction according to the transaction ID of the historical transaction contained in the query transaction (that is, the transaction ID, usually the hash value of the transaction), so that according to the obtained historical transaction The 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 initiator’s identity information contained in the query transaction, the operation of obtaining private data is prohibited (that is, the query authority is determined to be prohibited from querying), so that the query party can be effectively excluded by forging the initiator’s identity information. Stealing user privacy data.

In this embodiment, when it is determined that the inquiry authority of the inquiring party is forbidden to inquire, there is no need to perform the above steps of verifying the identity information of the originator or verifying the contract address of the business contract by obtaining historical transactions. Since the verification step is an unnecessary operation when the query authority of the querying party is prohibited, it can reduce the occupation of processing resources of the blockchain node, thereby improving the performance of the blockchain node. At the same time, when it is determined that the inquiry authority of the inquiring party is prohibited from inquiring, a contract receipt indicating that the inquiring party is prohibited from inquiring private data can be generated for viewing by the inquiring party.

It should be noted that the types of requests initiated by users accessing the blockchain may specifically refer to transactions used in traditional blockchains. Of course, the types of requests initiated on the blockchain by users accessing the blockchain can also be other than transactions, other forms of instructions and messages with standard data structures, one or more embodiments of this specification It is not particularly limited. In each of the following embodiments, a request initiated by a user who accesses the blockchain is taken as a transaction as an example for illustration.

Step 404A, when receiving a verification request for the distribution code initiated by the challenger, read the distribution code maintained in the trusted execution environment to generate a verification report, and send the verification report to the challenger, so that the challenger verifies the distribution code in the trusted execution environment according to the verification report.

In this embodiment, the chain code can be maintained in the TEE of the blockchain node, that is, the blockchain node executes the chain code (including the distribution code) in the TEE, so that the remote proof mechanism can be used to ensure that the distribution code is illegally tampered with , thus ensuring the authenticity and credibility of the distribution code maintained in the TEE. For example, the above-mentioned feature server (that is, the source of the distribution code) can be used as the challenger to verify the distribution code maintained in the TEE of the blockchain node, so as to determine whether the distribution code maintained in the TEE of the blockchain node is consistent with the distribution code issued by itself. The code is consistent, or whether it is consistent with the distribution code it maintains.

Correspondingly, based on the above-mentioned process of solidifying the distribution code into the chain code, this specification further provides a private data query scheme. Please refer to FIG. 4B . FIG. 4B is a flow chart of a private data query method provided by an exemplary embodiment. As shown in Figure 4B, the method is applied to blockchain nodes and may include the following steps:

Step 402B, when receiving the query transaction of the private data related to the historical transaction submitted by the querying party, read the distribution code maintained in the trusted execution environment, and the distribution code belongs to the chain code maintained in the trusted execution environment a part of.

Step 404B, execute the distribution code in the trusted execution environment to determine the inquiry authority of the inquiring party according to the authority control code defined in the business contract invoked by the historical transaction.

Step 406B, when it is determined that the query authority is allowed to query, obtain the private data, and read the obtained private data into the 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 blockchain node (by executing the updated chain code) can obtain private data according to the transaction identification of the historical transaction contained in the query transaction, and the obtained private data The data is read into the trusted execution environment for decryption to be obtained by the querying party. Depending on the type of data contained in the privacy data, the decryption method adopted is also different (because the encryption method is different).

When the privacy data includes historical transactions and/or transaction receipts of historical transactions, it can be known from the above embodiment shown in FIG. 3 that both historical transactions and transaction receipts of historical transactions are encrypted using the symmetric key used by the originator of the historical transactions. Therefore, after obtaining the historical transaction and/or the transaction receipt of the historical transaction, you can first obtain the symmetric key used by the initiator (in the embodiment shown in Figure 3, that is, user A), and then pass the symmetric key key to decrypt historical transactions and/or transaction receipts for 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 above-mentioned embodiment shown in Figure 3 encryption method), the symmetric key is decrypted in the TEE with the private key corresponding to the public key used by the initiator to obtain the decrypted symmetric key. It should be noted that when the private data is historical transactions, the process of obtaining historical transactions and decrypting historical transactions is carried out when obtaining historical transactions according to transaction identifiers, that is, obtaining historical transactions according to transaction identifiers, and decrypting historical transactions to obtain plaintext transaction content , so as to determine the business contract invoked by the historical transaction according to the plaintext transaction content. Therefore, when it is determined that the query authority is allowed to query, (no need to perform the operations of acquiring and decrypting historical transactions) the decrypted historical transactions can be obtained directly for the querying party to view.

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 a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm, and the like. 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 An enclave (also known as an enclave) of nodes. The asymmetric encryption algorithm used to generate the public key and the private key may be, for example, RSA, Elgamal, Knapsack Algorithm, Rabin, D-H, ECC (Elliptic Curve Encryption Algorithm) and the like.

When the privacy data includes at least one of the account attribute information of the originator of the historical transaction, the account attribute information of the business contract, the contract code of the business contract, and the contract state data of the business contract, it can be seen from the above-mentioned embodiment shown in Figure 3 that these privacy Data is encrypted using a specific symmetric key inside the TEE. Therefore, after obtaining these private data, they can be decrypted within the TEE through the specific symmetric key of the blockchain node. As for the specific symmetric key inside the TEE, it is sent by the key management server after the SGX architecture of the blockchain node passes remote certification, or it is obtained through negotiation 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 querying transaction, it can also use its own symmetric key to encrypt the created querying transaction, and use its own The public key encrypts the symmetric key. Therefore, after the blockchain node receives the query transaction, it first decrypts the symmetric key of the encrypted query transaction through the private key corresponding to the public key used by the query party in the TEE, and then uses the decrypted symmetric key to query the transaction Decrypt to obtain the transaction content contained in the query transaction. After obtaining the private data and decrypting the private data, the blockchain node can encrypt the decrypted private data through the symmetric key of the querying party, so that the querying party can use the symmetric key used by the querying party to encrypt the private data. Decrypt to view, so as to avoid the leakage of private data.

Wherein, the sources of the above-mentioned symmetric key, public key and private key used for privacy protection for the query party are similar to the above, and will not be repeated here. Certainly, the asymmetric key (public key and private key) used in this process may be the above-mentioned asymmetric key used for privacy protection for the initiator.

For ease of understanding, the technical solution of this specification will be described in detail below with reference to FIGS. 5-7 .

Please refer to FIG. 5 . FIG. 5 is a schematic diagram of remote attestation for code distribution provided by an exemplary embodiment. As shown in Figure 5, the remote attestation process may include the following steps:

Step 502, the challenger 51 sends a verification request for the distributed code to the blockchain node 52.

In this embodiment, blockchain nodes 52 maintain distribution codes within the TEE. TEE is a security extension based on CPU hardware and a trusted execution environment completely isolated from the outside world. 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 applications with a trusted and secure execution environment. ARM's Trust Zone technology is the first to realize the real commercial TEE technology. With the rapid development of the Internet, the demand for security is getting higher and higher, not limited to mobile devices, cloud devices, and data centers have put forward more demands on TEE. The concept of TEE has also been developed and expanded at a high speed. The TEE now referred to is a broader TEE than the concept originally proposed. For example, server chip manufacturers Intel and AMD have launched hardware-assisted TEE successively and enriched the concept and characteristics of TEE, which have been widely recognized in the industry. The TEE mentioned now usually refers more to this kind of hardware-assisted TEE technology. Unlike mobile terminals, cloud access requires remote access, and end users are invisible to the hardware platform. Therefore, the first step in using TEE is to confirm the authenticity of TEE. Therefore, a remote certification mechanism can be introduced for TEE technology, endorsed by hardware manufacturers (mainly CPU manufacturers) and digitally signed to ensure that users can verify the state of TEE. At the same time, only secure resource isolation cannot meet the security requirements, and further data privacy protection has also been proposed. Commercial TEEs including Intel SGX and AMD SEV also provide memory encryption technology, which limits the trusted hardware inside the CPU, and the data on the bus and memory are encrypted to prevent malicious users from snooping. For example, TEE technologies such as Intel's Software Guard Extensions (SGX) isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution. Applications running in TEE are secured and almost impossible to be accessed by third parties.

Taking Intel SGX technology as an example, SGX provides an enclave, which is an encrypted trusted execution area in memory, and the CPU protects data from being stolen. Taking the blockchain node adopting a CPU that supports SGX as an example, using the newly added processor instructions, a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) can be allocated in the memory, through the encryption in the CPU The engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in the EPC will only be decrypted into plaintext after entering the CPU. Therefore, in SGX, users can not trust the operating system, VMM (Virtual Machine Monitor, virtual machine monitor), or even BIOS (Basic Input Output System, basic input and output system), only need to trust the CPU to ensure that private data will not leakage.

Based on the above method of maintaining the distribution code, the server that issues the distribution code can initiate a challenge to the block chain node 52 as the challenger, requiring the block chain node 52 to produce a verification report to prove that the distribution code maintained in the TEE of the block chain node 52 is made by published by this server, or consistent with the distribution code maintained by this server.

Step 504, the blockchain node 52 generates a verification report and signs it with the private key of the CPU of SGX.

Step 506, the blockchain node 52 returns a verification report to the challenger 51.

Step 508, the challenger 51 forwards the verification report to the IAS53.

Taking Intel SGX technology as an example, after receiving the verification request, the blockchain node 52 exports the distribution code maintained in SGX to generate a verification report based on the distribution code. For example, hash calculation can be performed on the distribution code to obtain the corresponding hash value, and the hash value is stored in the quote (reference structure), and the quote (as a verification report) is signed with the private key of the CPU of SGX.

Intel configures a private key to the CPU when the CPU leaves the factory, but does not disclose the public key corresponding to the private key, but configures it in Intel's IAS (Intel Attestation Server, Intel Authentication Server). Then, after using the private key of the CPU to sign the verification report, since there is no corresponding public key, the challenger 51 needs to forward the quote returned by the blockchain node 52 to the IAS to verify the signature by the IAS.

In step 510, the IAS53 uses the public key of the CPU of the SGX to verify the signature.

In this embodiment, if the verification passes, the verification result is returned to the challenger 51 . For example, an AVR report may be generated, in which "YES" is used to indicate that the verification signature is passed, and "NO" is used to indicate that the verification signature is not passed. Among them, in order to prevent the AVR report from being intercepted or modified during transmission, in addition to using SSL (Secure Sockets Layer, Secure Sockets Layer) encryption for the transmission link, IAS can also use its own certificate to sign the AVR report.

In step 512, the IAS53 returns the verification result to the challenger 51.

In step 514, the challenger 51 verifies the distribution code.

In this embodiment, after receiving the verification result, the challenger 51 first verifies the signature of the IAS, and then obtains the verification result recorded in the AVR report after the verification is passed. If it is YES, compare the hash value in the quote with the local hash value (obtained by hash calculation of the locally maintained distribution code). When the comparison results are consistent, it is determined that the verification of the remote proof is passed, and then it is determined that the distribution code maintained in the TEE of the blockchain node 52 is issued by the challenger 51, or is consistent with the distribution code maintained by the challenger 51.

Please refer to FIG. 6 . FIG. 6 is a flow chart of another private data query method provided by an exemplary embodiment. Based on the scenario in Figure 3 above, after user A initiates a transaction calling a business contract, user A can share private data related to the transaction (in this scenario as a historical transaction) with user B, or user B exists to view the private data data needs. As shown in Figure 6, the process for user B to query private data as a query party may include the following steps:

In step 602, user B creates a query transaction through the client.

In this embodiment, the to field of the query transaction records the specific calling address of the distribution code, and 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 The content of (the address of the originator 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 and the address of the originator can be obtained by sharing offline between user B and user A, or by any other means.

Step 604, user B uses the digital envelope to encrypt and query the transaction through the client.

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

Step 608, the blockchain node decrypts the query transaction in the TEE.

In this embodiment, the key of the asymmetric encryption algorithm may 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 encirclement of the blockchain node. A blockchain node can contain multiple enclaves, and the above-mentioned private key can be passed into a security enclave in these enclaves; for example, the security enclave can be a QE (Quoting Enclave) enclave instead of an AE (Application Enclave ) circle. For the asymmetrically encrypted public key, it can be sent to the user's client by the key management server. 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 receiving the encrypted transaction, the blockchain node can first use the private key of the asymmetric encryption algorithm to decrypt it to obtain the symmetric key of the symmetric encryption algorithm, and then use the symmetric encryption algorithm to decrypt it. The symmetric key decrypts to get the transaction content.

Step 610, the blockchain node determines that the received transaction is a query transaction.

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 specific call address of the distribution code, it means that the transaction is used to call the distribution code, and then it can be determined that the transaction is a query transaction.

Step 612, the blockchain node determines the business contract invoked by the historical transaction according to the to field of the historical transaction recorded in the query transaction.

Step 614, the blockchain node invokes the business contract.

Step 616, the business contract determines the query authority of 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 originator of the historical transaction are jointly used as the basis for authority control as an example. For example, the access control rules (defined in the business contract in the form of access 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 members of the queried group; or, directly record in the access control rules Which other users' correspondences can be viewed by each user. Wherein, the account address is used as the identity information of the user. Then, the blockchain node executes the authority control code defined in the business contract, so as to determine according to the account address of the inquiring party (the content of the from field of the query transaction) and the account address of the originator of the historical transaction (the content of the from field of the historical transaction) User B's query permission.

Step 618, the business contract returns the query authority of user B to the blockchain node.

Step 620, after determining that the query authority of user B is allowed to query, the blockchain node checks the from field and to field of the historical transaction.

In this embodiment, the initiator's address and the contract address of the business contract recorded in the query transaction are filled in by user B, so the initiator's address 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 invoked by the historical transaction declared by user B. However, the actual address of the 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 through the above-mentioned way of deploying business contracts, and the authority control code defined in the business contract allows user B to view user A's private data; then, user B can use The contract address of the business contract invoked by the historical transaction initiated by user A is filled in with the contract address of the above business contract deployed by user B. Therefore, when it is determined that user B's query authority is allowed to query, the blockchain node can further verify the initiator's address and contract address of the historical transaction declared by user B, so as to ensure the security of private data.

For example, after the blockchain node determines that the query authority of user B is allowed to query, it can obtain historical transactions from the blockchain (stored on the blockchain) according to the hash value of the historical transactions, and read out The content recorded in the from field of the historical transaction and the content of the to field of the historical transaction. 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 private data can be further performed; otherwise, the execution of the acquisition is prohibited Operation of private data. Similarly, if the content of the read to field is the same as that declared in the query transaction, the operation of obtaining private data can be further performed; otherwise, the operation of obtaining private data is prohibited.

It should be noted that when it is determined that the query authority of the querying party is prohibited from querying, the above verification steps are unnecessary operations, so the above verification steps do not need to be performed, thereby reducing the occupation of blockchain node processing resources. This improves the performance of blockchain nodes.

Further, after using the business contract to determine that the query authority of user B is prohibited from querying, a contract receipt about user B's prohibition of querying private data can be generated for user B to view. Alternatively, the block chain node returns to user B a receipt of prohibition of query to inform user B that the query authority is prohibited.

Step 622, the blockchain node acquires private data.

Step 624, the blockchain node reads the private data into the TEE for decryption.

In this embodiment, it can be seen from the above 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 privacy data, the encryption methods adopted are also different. Therefore, after obtaining the private data (for example, obtaining the private data according to the hash value of the historical transaction), the obtained private data can be read into the trusted execution environment for decryption, so as to be obtained by the querying party.

When the privacy data includes historical transactions and/or transaction receipts of historical transactions, it can be known from the above embodiment shown in FIG. 3 that both historical transactions and transaction receipts of historical transactions are encrypted using the symmetric key used by the originator of the historical transactions. Therefore, after obtaining the historical transaction and/or the transaction receipt of the historical transaction, the symmetric key used by user A can be obtained first, and then the historical transaction and/or the transaction receipt of the historical transaction can be decrypted in the TEE by using the symmetric key . For the acquisition of the symmetric key used by the initiator, the symmetric key used to encrypt the historical transaction can be obtained first (the symmetric key is encrypted by the public key used by user A), and the public key used by user A can be used in the TEE The corresponding private key is decrypted to obtain the decrypted symmetric key.

When the privacy data includes at least one of user A's account attribute information, account attribute information of business contracts, contract code of business contracts, and contract status data of business contracts, specific symmetric key pairs of blockchain nodes can be passed in TEE These private data are decrypted.

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 passing the remote certification, or can be the key between each blockchain node. Negotiated, and then blockchain nodes use the seal key to encrypt and decrypt private data. Of course, the symmetric key sent by the key management server to the blockchain node after remote certification, or negotiated between each blockchain node, may not be the above-mentioned seal key, but the root key (the 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 sequence, and any adjacent two keys can irreversibly derive a lower version key from a higher version key, thus forming a chained key derivative structure. For example, if you need to derive 256 versions of keys with version numbers from 0 to 255, you can combine the root key with the version factor 0xFF (the decimal value is 255, which is the version number of the key to be generated; of course, Other values) can also be used 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-255 with the version number 254 is obtained. 254; ... By performing hash calculation on the key key-1 and the version factor 0x00, the key key-0 whose version number is 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 obtained through the key key. -0 and version factor 0x00 deduce the key key-1.

Then, a derived key of a certain version can be designated as the above-mentioned seal key to encrypt private data. Furthermore, it is also possible to update the version of the seal key, and based on the characteristics described above, 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.

Step 626, the blockchain node encrypts the private data using the symmetric key of user B.

Step 628, user B checks private data.

In an embodiment, after the blockchain node encrypts the private data, it can generate an event containing the private data and store it in the blockchain log. Then, user B can use the client through the callback mechanism of the blockchain to Get this event to view private data. After obtaining the private data, user B can use the symmetric key used by the client to decrypt the private data to obtain the private data in plain text.

In another embodiment, after the blockchain node encrypts the private data, it can directly return the encrypted private data to the client used by user B. In the same way, user B decrypts the private data through the client using its own symmetric key to obtain the private data in plain text.

In the embodiment shown in Figure 5 above, the query transaction created by user B contains the hash value of the historical transaction, the from field and the content of the to field, but it can be known from the above analysis that the query transaction can only contain the hash value of the historical transaction , without writing the contents of the from field and to field. The following description will be made in conjunction with FIG. 7 . As shown in Figure 7, the process of user B querying private data as the querying party may include the following steps:

In step 702, user B creates an inquiry transaction through the client used.

In this embodiment, the to field of the query transaction records the specific calling address of the distribution code, and the hash value of the historical transaction (that is, the transaction ID) can also be recorded in the data field (or other fields) of the query transaction. Among them, the hash value of the historical transaction can be obtained by offline sharing between user B and user A, or obtained by other arbitrary methods.

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

Step 706, user B initiates a query transaction to the blockchain node through the client.

Step 708, the blockchain node decrypts the query transaction in the TEE.

It should be noted that the process of encryption and decryption in this embodiment is similar to the above embodiment shown in FIG. 5 , and will not be repeated here.

Step 710, the blockchain node determines that the received transaction is a query transaction.

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 specific call address of the distribution code, it means that the transaction is used to call the distribution code, and then it can be determined that the transaction is a query transaction.

Step 712, the blockchain node obtains the from field and to field of the historical transaction according to the hash value.

In this embodiment, the content of the from field of the historical transaction is the address of the initiator of the historical transaction (in this embodiment, the identity information of the initiator), and the content of the to field of the historical transaction is the contract of the business contract called by the historical transaction address.

Step 714, the blockchain node determines the business contract invoked by the historical transaction according to the to field of the historical transaction.

Step 716, the blockchain node invokes the business contract.

Step 718, the business contract determines the query authority of 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 originator of the historical transaction are jointly used as the basis for authority control as an example. For example, the access control rules (defined in the business contract in the form of access 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 members of the queried group; or, directly record in the access control rules Which other users' correspondences can be viewed by each user. Wherein, the account address is used as the identity information of the user. Then, the blockchain node executes the authority control code defined in the business contract, so as to determine according to the account address of the inquiring party (the content of the from field of the query transaction) and the account address of the originator of the historical transaction (the content of the from field of the historical transaction) User B's query permission.

Step 720, the business contract returns the query authority of user B to the blockchain node.

Step 722, when user B's query permission is allowed to query, the blockchain node obtains private data.

In this embodiment, after using the business contract to determine that user B's query authority is prohibited from querying, a contract receipt for user B's prohibition of querying private data can be generated for user B to view. Alternatively, the block chain node returns to user B a receipt of prohibition of query to inform user B that the query authority is prohibited.

Step 724, the blockchain node reads the private data into the TEE for decryption.

Step 726, the blockchain node encrypts the private data using the symmetric key of user B.

It should be noted that when the private data is historical transactions, the process of obtaining historical transactions and decrypting historical transactions is performed when step 712 is executed, that is, obtaining historical transactions according to the hash value of historical transactions, and decrypting historical transactions to obtain the historical transaction Clear text transaction content, so as to read the from field and to field of the historical transaction. Therefore, in this case, when it is determined that the query authority is allowed to query, (there is no need to perform the operations of acquiring and decrypting historical transactions) the decrypted historical transactions can be obtained directly for the querying party to view.

Step 728, user B checks private data.

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

Corresponding to the above method embodiments, this specification also provides an embodiment of a chaincode-based permission query configuration device.

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

From the perspective of hardware, 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 , and of course may also include hardware required by other services. The processor 802 reads the corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs it, forming a chaincode-based permission query configuration device on a logical level. Of course, in addition to software implementations, 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 A logic unit, which can also be a hardware or logic device.

Please refer to FIG. 9, in a software implementation, the configuration device is applied to a block chain node, and may include:

The first update unit 91 reads the obtained distribution code into the trusted execution environment to update the chain code maintained in the trusted execution environment, and the distribution code is used to match the historical transaction with the party receiving the query When inquiring about the relevant privacy data, call the business contract invoked by the historical transaction to execute the authority control code defined in the business contract, and determine the inquiry authority of the inquiring party;

The verification unit 92, when receiving a verification request for the distribution code initiated by the challenger, reads the distribution code maintained in the trusted execution environment to generate a verification report, and sends the verification report to the challenger , so that the challenger verifies the distribution code in the trusted execution environment according to the verification report.

Optionally, a specific calling address is configured for the distribution code; the device also includes:

The transaction identifying unit 93, when any received transaction calls the distribution code through the specific calling address, takes the any transaction as a query transaction.

optional,

It also includes: a second update unit 94, which updates the chaincode maintained in the trusted execution environment according to the obtained new version chaincode, and the new version chaincode is used to identify Obtaining the historical transaction, and determining the business contract invoked by the historical transaction based on the historical transaction;

The distribution code is used to call the business contract determined by executing the new version chain code, so as to execute the permission control code defined in the called business contract.

Optionally, the distribution code is used to determine the corresponding business contract according to the contract address of the business contract called by the historical transaction contained in the query transaction, and call the determined business contract to execute the corresponding authority control code to Determine the inquiry authority of the inquiring party; the device also includes:

The third updating unit 95 updates the chain code maintained in the trusted execution environment according to the obtained new version of the chain code, and the new version of the chain code is used to determine that the query authority of the querying party is allowed through the business contract When querying, obtain the historical transaction according to the transaction identifier contained in the query transaction, and determine the contract address of the business contract actually called by the historical transaction according to the obtained historical transaction, and when the determined contract address is consistent with the When the contract addresses contained in the query transaction are inconsistent, it is determined that the query authority of the query party is prohibition of query.

Optionally, the new version of the chain code is also used to obtain the decrypted private data for viewing by the querying party when it is determined that the querying authority of the querying party is allowed to query, and the private data is read into the trusted execution environment for decryption.

Optionally, the private 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 Contract state data for business contracts.

From the perspective of hardware, 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 by other services. The processor 1002 reads the corresponding computer program from the non-volatile memory 1010 into the memory 10010 and then runs it, forming a private data query device on a logical level. Of course, in addition to software implementations, 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 A logic unit, which can also be a hardware or logic device.

Please refer to Figure 11. In a software implementation, the query device is applied to a block chain node and may include:

The code reading unit 1101 reads the distribution code maintained in the trusted execution environment when receiving the query transaction of the private data related to the historical transaction submitted by the querying party, and the distribution code belongs to the distribution code maintained in the trusted execution environment. part of the chaincode;

The authority determining unit 1102, executes the distribution code in the trusted execution environment, so as to determine the inquiry authority of the inquiring party according to the authority control code defined in the business contract invoked by the historical transaction;

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

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular 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 Combinations of any of these devices.

For the convenience of description, when describing the above devices, 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 pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

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

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile 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 that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

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

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

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

The above 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. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims (21)

1. A permission query configuration method based on a chain code is applied to block chain nodes; the method comprises the following steps:

reading the acquired distribution codes into a trusted execution environment to update chain codes maintained in the trusted execution environment, wherein the distribution codes are used for determining corresponding business contracts according to contract addresses of business contracts called by historical transaction contained in query transactions when query transactions of query parties aiming at privacy data related to the historical transaction are received, and executing authority control codes defined in the determined business contracts to determine query authorities of the query parties; wherein, when the historical transaction invokes a business contract, business codes defined in the business contract invoked by the historical transaction are executed;

updating the chain code maintained in the trusted execution environment according to the acquired new version chain code, wherein the new version chain code is used for acquiring the historical transaction according to the transaction identifier contained in the query transaction when the query authority of the query party is determined to be allowed to query, determining the contract address of the service contract actually called by the historical transaction according to the acquired historical transaction, and judging that the query authority of the query party is forbidden to query when the determined contract address is inconsistent with the contract address contained in the query transaction.

2. The method of claim 1, configured with a specific call address for the distribution code; the method further comprises the steps of:

and when any received transaction calls the distribution code through the specific call address, taking any transaction as a query transaction.

3. The method of claim 1, further comprising:

when a verification request for the distributed code initiated by a challenger is received, the distributed code maintained in the trusted execution environment is read to generate a verification report, and the verification report is sent to the challenger, so that the challenger verifies the distributed code in the trusted execution environment according to the verification report.

4. The method of claim 1, wherein the new version chain code is further configured to, when determining that the querying authority of the querying party is permission to query, obtain the decrypted private data for viewing by the querying party, where the private data is read into a trusted execution environment for decryption.

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

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

6. A query method of privacy data is applied to a blockchain node; the method comprises the following steps:

when a query transaction submitted by a query party for privacy data related to historical transactions is received, reading a distribution code maintained in a trusted execution environment, wherein the distribution code belongs to a part of chain codes maintained in the trusted execution environment;

executing the distributing code in the trusted execution environment to determine a corresponding business contract according to the contract address of the business contract called by the historical transaction contained in the query transaction, and executing the authority control code defined in the determined business contract to determine the query authority of the query party; wherein, when the historical transaction calls a business contract, a business code defined in the business contract called by the historical transaction is executed;

when the determined inquiry authority is the permission of inquiry, executing other chain codes different from the distribution codes in the chain codes in the trusted execution environment so as to acquire the historical transaction according to the transaction identifier contained in the inquiry transaction, and determining the contract address of the business contract actually invoked by the historical transaction according to the acquired historical transaction; if the determined contract address is consistent with the contract address contained in the inquiry transaction, acquiring the decrypted privacy data to be checked by the inquirer, wherein the privacy data is read into a trusted execution environment for decryption; otherwise, judging the query authority of the query party as forbidden query.

7. The method of claim 6, configured with a specific call address for the dispatch code; the method further comprises the steps of:

and when any received transaction calls the distribution code through the specific call address, taking any transaction as a query transaction.

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

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

9. The method of claim 8, the privacy data comprising the historical transaction and/or the transaction receipt; the method further comprises the steps of:

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

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

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

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

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

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

12. The method of claim 8, the privacy data comprising at least one of account attribute information of an initiator of the historical transaction, account attribute information of a business contract invoked by the historical transaction, a contract code of the business contract, contract status data of the business contract; the method further comprises the steps of:

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

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

14. The method according to claim 6, wherein the method comprises,

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

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

15. The method of claim 14, after determining that the query authority is permissible for the query, the method further comprising:

acquiring the historical transaction according to the transaction identifier;

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

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

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

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

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

17. The method of claim 6, further comprising:

and when the determined inquiry authority is inquiry prohibition, generating a contract receipt for indicating that the inquirer prohibits inquiring the private data for viewing by the inquirer.

18. A permission query configuration device based on a chain code is applied to a blockchain node; the device comprises:

the first updating unit reads the acquired distribution codes into a trusted execution environment to update chain codes maintained in the trusted execution environment, wherein the distribution codes are used for determining corresponding business contracts according to contract addresses of business contracts called by historical transactions contained in query transactions when query transactions of query parties aiming at privacy data related to the historical transactions are received, and executing authority control codes defined in the determined business contracts to determine query authorities of the query parties; wherein, when the historical transaction calls a business contract, a business code defined in the business contract called by the historical transaction is executed;

the second updating unit is used for updating the chain code maintained in the trusted execution environment according to the acquired new version chain code, wherein the new version chain code is used for acquiring the historical transaction according to the transaction identifier contained in the query transaction when the query permission of the query party is determined to be permission for query, determining the contract address of the service contract actually invoked by the historical transaction according to the acquired historical transaction, and judging that the query permission of the query party is prohibition of query when the determined contract address is inconsistent with the contract address contained in the query transaction.

19. A query device of privacy data is applied to a blockchain node; the device comprises:

a code reading unit for reading a distribution code maintained in a trusted execution environment when a query transaction for privacy data related to a historical transaction submitted by a querying party is received, wherein the distribution code belongs to a part of chain codes maintained in the trusted execution environment;

a right determining unit executing the distribution code in the trusted execution environment to determine a corresponding business contract according to a contract address of the business contract called by the history transaction included in the query transaction, and executing a right control code defined in the determined business contract to determine a query right of the querying party; wherein, when the historical transaction calls a business contract, a business code defined in the business contract called by the historical transaction is executed;

the data acquisition unit is used for executing other chain codes different from the distribution codes in the chain codes in the trusted execution environment when the determined query permission is the permission for query so as to acquire the historical transaction according to the transaction identifier contained in the query transaction and determining the contract address of the service contract actually invoked by the historical transaction according to the acquired historical transaction; if the determined contract address is consistent with the contract address contained in the inquiry transaction, acquiring the decrypted privacy data to be checked by the inquirer, wherein the privacy data is read into a trusted execution environment for decryption; otherwise, judging the query authority of the query party as forbidden query.

20. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

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

Images