CN111523110B

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

Info

Publication number: CN111523110B
Application number: CN202010307195.XA
Authority: CN
Inventors: 刘琦; 闫莺
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-11-08
Filing date: 2019-11-08
Publication date: 2023-05-02
Anticipated expiration: 2039-11-08
Also published as: CN110580412A; CN111523110A; CN110580412B; WO2021088549A1

Abstract

One or more embodiments of the present disclosure provide a method and apparatus for configuring authority query based on a chain code; the method is applied to the blockchain node and can comprise 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 calling a business contract called by a historical transaction to execute a right control code defined in the business contract when receiving a query transaction of a query party for privacy data related to the historical transaction, and determining the query right of the query party; 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.

Description

Authority query configuration method and device based on chain codes

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for configuring authority query based on a chain code.

Background

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

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

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

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and apparatus for configuring rights inquiry based on smart contracts, an electronic device, and a storage medium.

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

according to a first aspect of one or more embodiments of the present specification, a chain code-based authority query configuration method is provided, which is applied to a blockchain node; 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 calling a business contract called by a historical transaction to execute a right control code defined in the business contract when receiving a query transaction of a query party for privacy data related to the historical transaction, and determining the query right of the query party;

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.

According to a second aspect of one or more embodiments of the present disclosure, a method for querying private data is provided, which is applied to a blockchain node; the method comprises the following steps:

when a query transaction of privacy data related to historical transactions submitted by a query party 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 distribution code in the trusted execution environment to determine the query authority of the querying party according to the authority control code defined in the business contract invoked by the historical transaction;

and when the determined query permission is permission for query, acquiring the decrypted private data for viewing by the query party, wherein the private data is read into a trusted execution environment for decryption.

According to a third aspect of one or more embodiments of the present specification, a chain code-based authority query configuration device is provided, which 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 calling a business contract called by a historical transaction to execute authority control codes defined in the business contract when a query transaction of a query party for privacy data related to the historical transaction is received, and determining the query authority of the query party;

And the verification unit is used for reading the distribution codes maintained in the trusted execution environment to generate a verification report when a verification request for the distribution codes initiated by the challenger is received, and sending the verification report to the challenger so that the challenger verifies the distribution codes in the trusted execution environment according to the verification report.

According to a fourth aspect of one or more embodiments of the present disclosure, a query device for private data is provided, which 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 of privacy data related to a historical transaction submitted by a query 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 query right of the querying party according to a right control code defined in a business contract called by the history transaction;

and the data acquisition unit acquires the decrypted private data for viewing by the inquirer when the determined inquiry authority is the permission for inquiry, 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, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

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

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the second aspect by executing the executable instructions.

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

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

Drawings

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

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

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

Fig. 4A is a flowchart of a method for configuring a link code-based permission query according to an exemplary embodiment.

Fig. 4B is a flowchart of a method for querying private data according to an exemplary embodiment.

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

Fig. 6-7 are flowcharts of another method for querying private data provided by an exemplary embodiment.

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

Fig. 9 is a block diagram of a private data querying device according to an exemplary embodiment.

Fig. 10 is a schematic diagram of another apparatus provided in an exemplary embodiment.

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

Detailed Description

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

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

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

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

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

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

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

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

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

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

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

output field, which indicates the Output of the transaction.

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

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

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

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

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

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

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

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

In the privacy preserving scenario, the user may need to share the privacy data related to the service implemented by the user using the blockchain to some specific users to view, that is, the specific users may view the privacy data related to the historical transaction initiated by the user. Then, the query rights may be set for the user's privacy data for viewing by other users that are allowed to query. Thus, the functionality of rights queries for private data can be configured for blockchains by improving the chain code. The chain code based permission query configuration scheme of the present specification is described below with reference to fig. 4A.

Referring to fig. 4A, fig. 4A is a flowchart of a link code-based authority query configuration method according to an exemplary embodiment. As shown in fig. 4A, the method applied to a blockchain node may include the steps of:

step 402A, reading the obtained distribution code into a trusted execution environment to update a chain code maintained in the trusted execution environment, where the distribution code is used to call a service contract called by a historical transaction to execute a permission control code defined in the service contract when a query transaction of a querying party for privacy data related to the historical transaction is received, and determine a query permission of the querying party.

In the present embodiment, when developing a business contract, it is necessary to define in the business contract, in addition to the business code, a rights control code of privacy data related to a transaction calling the business contract for determining whether or not a querying party for the privacy data is allowed to query. By defining the permission control codes in the business contracts, the association relation between the privacy data and the permission control codes for controlling the query permission of the privacy data can be established, so that each business contract can control the privacy data related to the transaction of calling the business contract. Wherein the type of privacy data may include at least one of: historical transaction, 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, contract code of the business contract, contract status data of the business contract.

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

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

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

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

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

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

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

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

And a distributing 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 or not, and when the received transaction is the 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 may be issued to each blockchain node by a particular server such that the blockchain node obtains the distribution code from the server. Of course, the block link points may also be enabled to acquire the distribution codes and update the versions of the chain codes by any other way of configuring the distribution codes.

In particular, a particular call address may be configured for the distribution code for identifying the query transaction. In other words, the query transaction created by the querying party is a transaction for calling the distribution code; then, any transaction received by the blockchain node may be treated as a query transaction when it invokes the dispatch code through the particular calling address. Taking ethernet as an example, the inquiring party can write the specific calling address in the to field of the inquiry transaction, and when the inquiring transaction is received, the blockchain node can identify the received transaction as the inquiry transaction according to the specific calling address recorded in the to field, and then execute the distributing code to call the corresponding service contract. The distribution logic of the distribution inquiry transaction is solidified into the chain code in the form of a distribution code, and the distribution logic is issued along with the chain code, so that subsequent redeployment of an administrator is not needed, and the contract code is solidified in the chain code, so that the contract code is controllable, and the safety is effectively improved. In other words, the distribution of the query transaction to the corresponding business contracts is accomplished by the block link points themselves, without the need to do so by invoking the intelligent contracts.

In this embodiment, in addition to configuring the distribution code in the chain code, version update may be performed on the chain code on the blockchain node, so as to cooperate with the configured distribution code to complete the process of rights inquiry. For example, after a new version of chain code is developed, a push of chain code upgrades may be issued to each blockchain node by a particular server, such that the blockchain node obtains the new version of chain code from the server, and updates the chain code (maintained in the TEE) according to the obtained new version of chain code. Of course, the block link point can acquire the new version chain code to update the version by any other way of updating the chain code.

In one case, the querying party may write the transaction identification of the historical transaction related to the private data to be queried only in the querying transaction when constructing the querying transaction. The transaction identifier of the historical transaction can be obtained by an offline sharing mode between an initiator and a inquirer of the historical transaction or by any other mode. In this case, the new version chain code is used to acquire a historical transaction according to a transaction identifier included in the query transaction, and determine a service contract called by the historical transaction based on the acquired historical transaction; the distribution code is used for calling the business contract determined by executing the new version chain code to execute the authority control code defined in the called business contract.

Taking ethernet as an example, when the querying party creates the query transaction, the hash value (as the transaction identifier) of the historical transaction notified by the initiator of the historical transaction may be recorded in the data field of the query transaction. Then, upon receiving the query transaction, the blockchain node (updated chain code) determines a business contract invoked by the historical transaction based on the to field of the historical transaction (the contract address of the intelligent contract used to record the invocation) by executing the new version chain code to obtain the historical transaction stored on the blockchain based on the hash value. After determining the business contracts called by the historical transaction, the blockchain node executes the distribution codes to call the determined business contracts to execute the authority control codes.

In another case, when the inquiring party constructs the inquiring transaction, the inquiring party can write the transaction identification of the historical transaction related to the privacy data to be inquired and the contract address of the business contract called by the historical transaction in the inquiring transaction; the transaction identifier of the historical transaction and the contract address of the business contract can be obtained by an offline sharing mode between an initiator and a inquirer of the historical transaction or by any other mode. In this case, the distribution code is configured to determine a corresponding service contract according to a contract address of a service contract called by a historical transaction included in the query transaction, and call the determined service contract to execute a corresponding authority control code to determine a query authority of the querying party. It should be noted that, the inquiry transaction is created by the inquirer, and the contract address of the business contract called by the history transaction included in the inquiry transaction is declared by the inquirer, then the contract address is not necessarily the contract address of the business contract actually called by the history transaction, that is, there is a risk that the inquirer falsifies the contract address. Therefore, when the inquiry authority of the inquirer is determined to be the permission inquiry through the service contract, the new version chain code is used for acquiring the historical transaction according to the transaction identification (namely the transaction ID, generally the hash value of the transaction) contained in the inquiry transaction, and determining the contract address of the service contract actually invoked by the historical transaction according to the acquired historical transaction. When the determined contract address is inconsistent with the contract address of the business contract called by the historical transaction contained in the inquiry transaction, the inquiry authority of the inquirer is judged to be forbidden to inquire, so that the condition that the inquirer steals the user privacy data by forging the contract address can be effectively eliminated.

Further, when the query authority of the querying party is finally determined to be allowed to query, the new version chain code is further used for acquiring the decrypted privacy data to be checked by the querying party; wherein the private data is read into the trusted execution environment for decryption. For example, the private data may be obtained according to a transaction identifier of a historical transaction included in the query transaction, and the obtained private data may be read into a trusted execution environment for decryption for acquisition by the querying party. In other words, when it is finally determined that the querying authority of the querying party is allowed to query, the blockchain node obtains the private data for the querying party to view by executing the new version code.

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

In another case, the identity information of the inquirer and the identity information of the initiator of the historical transaction can be used as the basis of authority control. Then, the rights control rule may be set to allow the inquirer to inquire the corresponding privacy data when the identity information of the inquirer and the identity information of the initiator meet a specific condition. For example, the inquiry group and the inquired group are recorded in the authority control rule, and the members belonging to the inquiry group are allowed to view the privacy data of the inquired group members; or, the authority control rule directly records the corresponding relation of other users which can be checked by each user; or when the inquirer and the initiator belong to the same team, the inquirer's inquiry authority can be determined to be permission inquiry and the like. Thus, in determining the querying rights of the querying party, the rights control code defined in the business contract may be executed to determine the querying rights of the querying party for the private data based on the identity information of the querying party and the identity information of the initiating party. The inquiring party can write the identity information of the initiator of the historical transaction in the created inquiring transaction, or the blockchain node (by executing the new version chain code) acquires the historical transaction according to the transaction identifier contained in the inquiring transaction, and the obtained historical transaction is obtained based on the acquired historical transaction.

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

When the basis of the rights control includes the identity information of the initiator of the historical transaction, since the identity information of the initiator included in the inquiry transaction is only the identity information declared by the inquirer, the identity information is not necessarily the actual identity information of the initiator of the historical transaction, i.e. there is a risk that the inquirer falsifies the identity information of the initiator. Therefore, the verification logic for the identity information of the historical transaction initiator contained in the query transaction can be added in the new version chain code executed by the block chain node, namely, after the query authority of the query party is determined to be allowed to be queried according to the authority control code, the block chain node (by executing the new version chain code) can acquire the historical transaction according to the transaction identifier (namely, the transaction ID, generally, the hash value of the transaction) of the historical transaction contained in the query transaction, so that the identity information of the historical transaction initiator (namely, the actual identity information of the initiator) is determined according to the acquired historical transaction. When the determined identity information is inconsistent with the identity information of the initiator contained in the inquiry transaction, the operation of acquiring the private data is forbidden (namely, the inquiry permission is judged to be forbidden), so that the condition that the inquirer steals the private data of the user by forging the identity information of the initiator can be effectively eliminated.

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

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

Step 404A, when receiving a verification request for the distribution code initiated by a challenger, reading the distribution code maintained in the trusted execution environment to generate 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.

In this embodiment, the chain code may be maintained in the TEE of the blockchain node, that is, the blockchain node executes the chain code (including the distribution code) within the TEE, so that a remote attestation mechanism may be utilized to ensure that the distribution code is illegally tampered, and further ensure that the distribution code maintained within the TEE is authentic and trustworthy. For example, the distribution code maintained within the blockchain node's TEE may be verified by the feature server (i.e., at the source of the distribution code) as a challenger to determine whether the distribution code maintained within the blockchain node's TEE is consistent with the distribution code published by itself or consistent with the distribution code maintained by itself.

Accordingly, based on the above process of solidifying the distribution code to the chain code, the present specification further provides a scheme for querying the private data. Referring to fig. 4B, fig. 4B is a flowchart of a method for querying private data according to an exemplary embodiment. As shown in fig. 4B, the method applied to a blockchain node may include the steps of:

Step 402B, when a query transaction of privacy data related to a historical transaction submitted by a querying party is received, a distribution code maintained in a trusted execution environment is read, wherein the distribution code is part of a chain code maintained in the trusted execution environment.

Step 404B, executing the distributing code in the trusted execution environment to determine the querying authority of the querying party according to the authority control code defined in the business contract invoked by the historical transaction.

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

In the present embodiment, the privacy data is stored encrypted for the protection of the user privacy data described above. Therefore, when it is determined that the querying authority of the querying party is allowed to query, the blockchain node (by executing the updated chain code) may acquire the private data according to the transaction identifier of the historical transaction included in the query transaction, and read the acquired private data into the trusted execution environment to decrypt, so as to be acquired by the querying party. The decryption scheme used is different depending on the type of data contained in the private data (because the encryption scheme is different).

When the privacy data includes historical transactions and/or transaction receipts for historical transactions, as can be seen from the embodiment of FIG. 3 described above, both the historical transactions and the transaction receipts for the historical transactions are encrypted with a symmetric key used by the initiator of the historical transaction. Thus, after obtaining the historical transaction and/or the transaction receipt of the historical transaction, the symmetric key used by the initiator (user a in the embodiment shown in fig. 3) may be obtained first, and then the historical transaction and/or the transaction receipt of the historical transaction may be decrypted within the TEE by the symmetric key. For the acquisition of the symmetric key used by the initiator, the symmetric key used for encrypting the historical transaction (the symmetric key is encrypted by the public key used by the initiator, that is, the mode of encrypting by using a digital envelope in the embodiment shown in fig. 3 described above) may be acquired first, and the symmetric key is decrypted in the TEE by the private key corresponding to the public key used by the initiator to obtain the decrypted symmetric key. When the privacy data is the historical transaction, the process of acquiring the historical transaction and decrypting the historical transaction is performed when the historical transaction is acquired according to the transaction identifier, namely, the historical transaction is acquired according to the transaction identifier, and the historical transaction is decrypted to obtain plaintext transaction content, so that a business contract called by the historical transaction is determined according to the plaintext transaction content. Therefore, when the query permission is determined to be the permission for query, the decrypted historical transaction is directly acquired (without executing the operation of acquiring the historical transaction and decrypting the historical transaction) for the query party to view.

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

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

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

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

For easy understanding, the technical solutions of the present specification are described in detail below with reference to fig. 5 to 7.

Referring to fig. 5, fig. 5 is a schematic diagram of remote attestation of distributed code provided by an exemplary embodiment. As shown in fig. 5, the process of remote attestation may include the steps of:

at step 502, challenger 51 sends a validation request for the distribution code to blockchain node 52.

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

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

Based on the manner in which the distribution code is maintained as described above, a challenge may be initiated by the server that issued the distribution code as a challenge to blockchain node 52, requiring blockchain node 52 to present a verification report to prove that the distribution code maintained within the TEE of blockchain node 52 was issued by the server, or is consistent with the distribution code maintained by the server.

At step 504, blockchain node 52 generates a verification report and signs with the private key of the SGX's CPU.

At step 506, blockchain node 52 returns a validation report to challenger 51.

At step 508, challenger 51 forwards the validation report to IAS 53.

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

Intel configures a private key to a CPU at the time of shipment of the CPU, but does not disclose a public key corresponding to the private key, but is configured in an IAS (Intel Attestation Server, intel authentication server) of Intel. Then, after signing the verification report with the private key of the CPU, the challenger 51 needs to forward to the IAS to verify the signature by the IAS after acquiring the quoise returned by the blockchain node 52, as there is no corresponding public key.

Step 510, IAS53 verifies the signature using the public key of the SGX's CPU.

In the present embodiment, if the verification is passed, the verification result is returned to the challenger 51. For example, an AVR report may be generated in which "YES" indicates that the verification signature passed and "NO" indicates that the verification signature failed. Among other things, to prevent AVR reports from being intercepted or modified during transmission, the IAS may also sign AVR reports with its own certificate in addition to SSL (Secure Sockets Layer ) encryption for the link of the transmission.

Step 512, IAS53 returns the verification result to challenger 51.

At step 514, challenger 51 verifies the distribution code.

In this embodiment, after receiving the verification result, the challenger 51 verifies the signature of the IAS a priori, and obtains the verification result recorded in the AVR report after the verification is passed. If YES, comparing the hash value in the quote with a local hash value (obtained by performing hash calculation on a distributed code maintained locally). When the comparison results agree, verification by the remote attestation is judged, and it is further judged that the distribution code maintained in the TEE of the blockchain node 52 is issued by the challenger 51 or agrees with the distribution code maintained by the challenger 51.

Referring to fig. 6, fig. 6 is a flowchart of another method for querying private data according to an exemplary embodiment. With the scenario of fig. 3, after user a initiates a transaction that invokes a business contract, user a may share the private data associated with the transaction (in this scenario, as a historical transaction) with user B, or user B may have a need to view the private data. As shown in fig. 6, the process of querying private data by the user B as a querying party may include the following steps:

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

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

In step 604, user B queries the transaction via the client using digital envelope encryption.

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

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

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

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

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

In step 612, the blockchain node determines the business contracts invoked by the historical transactions based on the to field of the historical transactions recorded in the query transaction.

At step 614, the block link point invokes the business contract.

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

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

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

Step 620, after determining that the query authority of the user B is allowed for query, the block link point verifies the from field and the to field of the historical transaction.

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

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

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

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

In step 622, the blockchain node obtains the private data.

In step 624, the block link reads the private data into the TEE for decryption.

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

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

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

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

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

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

At step 628, user B views the private data.

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

In another embodiment, the blockchain node may directly return the encrypted private data to the client used by user B after encrypting the private data. Similarly, the user B decrypts the private data by the client by adopting the symmetric key used by the user B, so that the private data of the plaintext content can be obtained.

In the embodiment shown in fig. 5, the query transaction created by the user B includes the hash value of the historical transaction, the from field and the to field, and the analysis shows that the query transaction may also include only the hash value of the historical transaction without writing the contents of the from field and the to field. The following is a description with reference to fig. 7. As shown in fig. 7, the process of querying private data by the user B as a querying party may include the following steps:

in step 702, user B creates a query transaction through the client being used.

In this embodiment, the to field of the query transaction records the specific call address of the distribution code, while the hash value of the historical transaction (i.e., the transaction ID) may also be recorded in the data field (or other field) of the query transaction. The hash value of the historical transaction can be obtained by an offline sharing manner between the user B and the user a, or can be obtained by any other manner.

In step 704, user B queries the transaction via the client using digital envelope encryption.

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

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

It should be noted that, the encryption and decryption processes in this embodiment are similar to those in the embodiment shown in fig. 5, and are not repeated here.

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

In step 712, the block link point obtains the from field and the to field of the historical transaction according to the hash value.

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

In step 714, the block link point determines the business contract invoked by the historical transaction based on the to field of the historical transaction.

At step 716, the block link point invokes the business contract.

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

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

In step 722, when the query authority of the user B is permission for query, the blockchain node acquires the private data.

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

In step 724, the block link reads the private data into the TEE for decryption.

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

It should be noted that, when the privacy data is the historical transaction, the process of obtaining the historical transaction and decrypting the historical transaction is performed in the step 712, that is, the historical transaction is obtained according to the hash value of the historical transaction, and the historical transaction is decrypted to obtain the plaintext transaction content of the historical transaction, so as to read the from field and the to field of the historical transaction. Therefore, in this case, when it is determined that the inquiry authority is permitted to inquire, the decrypted historical transaction is directly acquired (without executing the operation of acquiring the historical transaction and decrypting the historical transaction) for the inquirer to view.

In step 728, user B views the private data.

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

Corresponding to the method embodiment, the present specification also provides an embodiment of a rights inquiry configuration device based on the chain code.

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

In terms of hardware, please refer to fig. 8, fig. 8 is a schematic block diagram of an apparatus according to an exemplary embodiment. At the hardware level, as shown in fig. 8, the device includes a processor 802, an internal bus 804, a network interface 806, memory 808, and non-volatile storage 810, although other hardware required for the service is possible. The processor 802 reads a corresponding computer program from the nonvolatile memory 810 into the memory 808 and then runs, forming a chain code-based authority query configuration means at a logic level. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

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

a first updating unit 91, configured to read the obtained distribution code into a trusted execution environment, so as to update a chain code maintained in the trusted execution environment, where the distribution code is configured to, when receiving a query transaction of a querying party for privacy data related to a historical transaction, invoke a service contract invoked by the historical transaction to execute a permission control code defined in the service contract, and determine a query permission of the querying party;

and a verification unit 92, when receiving a verification request for the distribution code initiated by a challenger, reading the distribution code maintained in the trusted execution environment to generate 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.

Optionally, a specific call address is configured for the distribution code; the apparatus further comprises:

and a transaction identification unit 93, when any received transaction calls the distribution code through the specific call address, the any transaction is used as a query transaction.

Alternatively to this, the method may comprise,

further comprises: a second updating unit 94, configured to update a chain code maintained in the trusted execution environment according to the acquired new version chain code, where the new version chain code is used to acquire the historical transaction according to the transaction identifier included in the query transaction, and determine a service contract invoked by the historical transaction based on the historical transaction;

the distribution code is used for calling the business contracts determined by executing the new version chain code so as to execute the authority control codes defined in the called business contracts.

Optionally, the distributing code is configured to determine a corresponding service contract according to a contract address of the service contract called by the historical transaction included in the query transaction, and call the determined service contract to execute a corresponding authority control code to determine a query authority of the query party; the apparatus further comprises:

the third updating unit 95 updates the chain code maintained in the trusted execution environment according to the obtained new version chain code, where the new version chain code is used to obtain the historical transaction according to the transaction identifier included in the query transaction when the query authority of the querying party is determined to be allowed to query through the service contract, determine the contract address of the service contract actually invoked by the historical transaction according to the obtained historical transaction, and determine that the query authority of the querying party is forbidden to query when the determined contract address is inconsistent with the contract address included in the query transaction.

Optionally, the new version chain code is further configured to obtain the decrypted private data for viewing by the querying party when determining that the querying authority of the querying party is permission to query, where the private data is read into a trusted execution environment to decrypt.

Optionally, the privacy data includes at least one of:

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

Referring to fig. 10, fig. 10 is a schematic structural diagram of an apparatus according to an exemplary embodiment. At the hardware level, as shown in fig. 10, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, although other hardware required by other services is possible. The processor 1002 reads the corresponding computer program from the nonvolatile memory 1010 into the memory 10010 and then runs to form a query device for private data on a logical level. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

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

a code reading unit 1101 that, when a query transaction of privacy data related to a history transaction submitted by a querying party is received, reads a distribution code maintained in a trusted execution environment, the distribution code being part of a chain code maintained in the trusted execution environment;

a right determining unit 1102 that executes the distribution code in the trusted execution environment to determine a query right of the querying party according to a right control code defined in a business contract called by the history transaction;

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

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

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

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

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

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

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

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

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

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

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

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

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

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

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

Claims

1. A 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:

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:

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

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.