WO2021179743A1

WO2021179743A1 - Method and apparatus for querying account privacy information in blockchain

Info

Publication number: WO2021179743A1
Application number: PCT/CN2020/139745
Authority: WO
Inventors: 刘琦; 闫莺; 魏长征
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-03-09
Filing date: 2020-12-26
Publication date: 2021-09-16
Also published as: CN111008228A

Abstract

Provided are a method and apparatus for querying account privacy information in a blockchain. The method may comprise: a blockchain node receiving a transaction initiated by a query party, wherein the transaction is used for acquiring privacy information contained in a privacy field in a target account, and the privacy information is encrypted and stored in the blockchain node; the blockchain node determining, according to permission management information recorded in a permission field in the target account, whether the query party has query permission; and insofar as a determination result indicates that the query party has query permission, the blockchain node reading the privacy information, which is in the form of ciphertext, in a trusted execution environment for decryption, so as to provide obtained privacy information in the form of plaintext to the query party.

Description

Method and device for querying account privacy information in blockchain

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and more particularly to a method and device for querying account privacy information in a blockchain.

Background technique

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

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

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

Summary of the invention

In view of this, one or more embodiments of this specification provide a method and device for querying account privacy information in a blockchain.

In order to achieve the foregoing objectives, one or more embodiments of the present specification provide the following technical solutions.

According to the first aspect of one or more embodiments of this specification, a method for querying account privacy information in a blockchain is proposed, which includes: a blockchain node receives a transaction initiated by a querying party, and the transaction is used to obtain a target account The private information contained in the privacy field in the private information is encrypted and stored at the blockchain node; the blockchain node determines the query according to the authority management information recorded in the authority field in the target account Whether the party has query authority; when the judgment result is that the blockchain node has query authority, the private information in ciphertext form is read into the trusted execution environment for decryption, so as to obtain all the information in plaintext form. The private information is provided to the inquiring party.

According to a second aspect of one or more embodiments of this specification, a device for querying account privacy information in a blockchain is proposed, which includes: a receiving unit that enables blockchain nodes to receive transactions initiated by the querying party, and the transaction is used To obtain the privacy information contained in the privacy field in the target account, the privacy information is encrypted and stored at the blockchain node; Authority management information to determine whether the query party has query authority; the decryption unit enables the blockchain node to read the private information in the form of cipher text into the trusted execution environment when the result of the determination is that it has query authority Decryption is performed in the process, so as to provide the obtained private information in the plaintext form to the inquiring party.

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

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

Description of the drawings

Fig. 1 is a flowchart of a method for querying account privacy information in a blockchain according to an exemplary embodiment.

Fig. 2 is a schematic diagram of a key version evolution provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of a data structure of private information in ciphertext form provided by an exemplary embodiment.

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

Fig. 5 is a block diagram of a device for querying account privacy information in a blockchain according to an exemplary embodiment.

Detailed ways

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

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

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

Regardless of whether it is a public chain, a private chain, or a consortium chain, relatively simple processing logic can be implemented, such as transfer logic, deposit logic, and so on. In related technologies, blockchain networks such as Ethereum can implement relatively complex processing logic by running virtual machines (such as the Ethereum virtual machine EVM used in the Ethereum network) on the blockchain nodes, and combining with smart contracts. , Such as conditional transfer logic, conditional query logic, etc. It can be seen that for a blockchain network that supports smart contracts, functions such as privacy protection and secure query of account information can be conveniently implemented based on complex processing logic, but simple processing logic is difficult to achieve in the same way.

The following describes the implementation process of an embodiment of the method for querying account privacy information in a blockchain in this specification with reference to FIG. 1, which can realize privacy protection and secure query of account information through simple processing logic. As shown in FIG. 1, the method may include the following steps 102 to 106.

Step 102: The blockchain node receives the transaction initiated by the querying party, the transaction is used to obtain the private information contained in the private field in the target account, and the private information is encrypted and stored at the blockchain node.

The above-mentioned blockchain nodes can obtain the above-mentioned transactions in a variety of ways. For example, the inquirer can submit the transaction to the aforementioned blockchain node through the client after generating the transaction on the client. Alternatively, the client can submit the transaction to another blockchain node, and the other blockchain node can further forward the transaction to the aforementioned blockchain node. Alternatively, the inquiring party can generate the transaction at the aforementioned blockchain node.

By analyzing the transaction content contained in the transaction, the blockchain node can determine the target account and privacy fields corresponding to the transaction. For example, the transaction content may include the account address of the target account, so that the above-mentioned blockchain node can determine the target account accordingly; and the transaction content may include the field name of the privacy field, so that the above-mentioned blockchain node can determine accordingly Out the privacy field.

The privacy field can include any one or more fields in the target account, and this specification does not limit this. For example, in the Ethereum blockchain, the account can contain the Balance field, Nonce field, etc., and the Balance field is used to record the account balance. If the Balance field is a privacy field, the account balance recorded in the Balance field can be encrypted and stored. To protect the value of the account balance from being leaked.

Based on the received transaction, the above-mentioned blockchain node can first determine which field the querying party wants to query, and further determine whether the field is a private field. For example, for a field in all accounts, the above-mentioned blockchain node encrypts and stores the content of the corresponding field. Then, when the blockchain node knows that the querying party needs to query the field, the blockchain node can determine the query The field that the party needs to query must be a private field. For another example, if the blockchain node encrypts and stores the field content of a certain field in some accounts, and stores the field content of the certain field in the remaining accounts in plaintext, then the account can include a status field and pass the status field. The status indication information contained in the corresponding account indicates that the field content of the above-mentioned certain field in the corresponding account is encrypted storage or plaintext storage. For example, the status indication information can have multiple values: the first value indicates that the field content is encrypted storage, and the second The value indicates that the content of the field is stored in plain text; for another example, the value of the highest bit of the status indication information can be used to indicate the use of encrypted storage or plain text storage. Therefore, for the above-mentioned target account, the status field of the target account may contain the above-mentioned status indication information, which is used to indicate that the above-mentioned private information is stored in plaintext or encrypted and stored at the blockchain node : If stored encrypted, it indicates that the field where the private information is located is a private field, and the blockchain node needs to implement secure information query based on the following steps 104-106; if stored in plain text, it indicates the field where the private information is located It is not a private field, and the blockchain node can directly read the private information for returning to the inquiring party without performing the following steps 104-106.

The transaction submitted by the query party to the blockchain node can be a regular transaction in related technologies, that is, the transaction needs to be agreed by all blockchain nodes in the blockchain network and linked to the chain, so that the query party’s query can be traced back afterwards. operate. For example, in a blockchain network that uses Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS) and other consensus algorithms that compete for the right to bookkeeping , After receiving the above transaction submitted by the client, the blockchain node will immediately spread (such as broadcast) to other blockchain nodes in the blockchain network; then, if the above blockchain nodes compete for the right to keep accounts , And the blockchain node confirms that the above transaction submitted by the client is packaged into a new block, then all blockchain nodes in the blockchain network can execute the above transaction, and by adding a new block containing the transaction To the end of the blockchain and make the transaction on the chain. Of course, if other blockchain nodes compete for the right to bookkeeping, then other blockchain nodes will select the transactions that they want to package into the new block, which will not be repeated here. For another example, in a blockchain network that uses non-competitive accounting rights such as Practical Byzantine Fault Tolerance (PBFT), the accounting nodes have agreed before the current round of accounting, so that the blockchain nodes can receive After the transaction submitted by the client, if it is not the accounting node, the transaction is sent to the determined accounting node, so that the accounting node will package the transaction (including the transaction) and send it to each verification in the further consensus stage node. And when the above-mentioned blockchain node itself is the determined accounting node, the above-mentioned transaction submitted by the client can also be received, or after the client submits to another blockchain node, the other blockchain node forwards it to the above-mentioned A blockchain node, and the blockchain node can package and send the above-mentioned transactions (or other transactions) to each verification node in the consensus phase.

Since the inquirer’s needs are only to query the information in the target account, and will not cause changes such as account content, that is, it will not affect the state of the blockchain, this manual can also support new transactions that do not require consensus. For example, this specification can provide a new transaction type, such as a query type, based on related technologies; accordingly, the blockchain node can identify the above transaction type, and when the transaction belongs to a predefined query type, The blockchain node executes the transaction without consensus. In other words, after the blockchain node obtains the above transaction, it does not need the accounting node (whether it is a node competing for accounting rights or an agreed accounting node) to determine whether to add the transaction to a new block. The node can directly execute the transaction, and in fact the transaction will not be added to the new block and will not be on the chain. On the one hand, it can realize that query-type transactions are efficiently executed by the blockchain node, and on the other hand, it can be avoided Take up valuable block space. For example, the transaction in this specification can include a type field, and by setting the value of the type field, the blockchain node can identify whether the above transaction is a query type or other types (such as Transfer type, deposit type, etc.).

Step 104: The blockchain node determines whether the query party has query authority according to the authority management information recorded in the authority field in the target account.

Based on the simple processing logic described above, the account maintained on the blockchain node can include a permission field, and the permission management information contained in the permission field can be used to determine whether a query party has query permission. Correspondingly, in response to the querying party’s query requirements for the above-mentioned target account, the blockchain node can determine whether the querying party has query authority based on the authority management information contained in the authority field in the target account: if it has query authority, then The blockchain node can provide the decrypted private information to the querying party, otherwise it will not provide it.

The authority management information recorded in the authority field can exist in various forms, so that the blockchain node can determine whether the querying party has query authority in a variety of ways.

For example, the authority management information may include the public key of the authority owner, that is, a predetermined set of public keys of all users with query authority; at the same time, the transaction submitted by the querying party contains a transaction signature, and the transaction signature is passed by the querying party. Therefore, the blockchain node can verify the transaction signature with the public key of the above-mentioned authority owner: if the public key of a authority owner is successfully verified, it indicates that the inquiring party is the authority owner , And the blockchain node can determine that the inquiring party has the inquiry authority; and if all the public keys fail to verify, it indicates that the inquiry party is not the authority owner, that is, the inquiry party does not have the inquiry authority. It can be seen that by managing the public key contained in the authority management information, it is possible to control the users who are allowed to query the privacy fields in the target account, that is, the authority owner mentioned above can be set reasonably. For example, the above-mentioned authority owner may include the owner of the target account, or the above-mentioned authority owner may include the owner of the target account and at least one other user. The owner of the target account can be the permission owner by default, and the owner can control adding the public key of at least one other user to the permission field to set the at least one other user as the permission owner. In addition to the owner of the target account, the above-mentioned authority owner can also be set by administrators or other users in the blockchain network, and this manual does not limit this.

Take the target account as an example. When the authority owner of the target account includes both the owner and at least one other user, it is equivalent to the owner and other users jointly managing the target account, that is, the target account belongs to a co-managed account of the owner and other users. All accounts in the blockchain can contain an authmap field. The authmap field of a non-shared account (or ordinary account) only contains the public key of the account owner, while the authmap field of a shared account contains all co-managers (as mentioned above). The public key of the owner and at least one other user). Based on the authority judgment method described above, only the account owner has the query authority for non-co-managed accounts, and all co-managers have the query authority for co-managed accounts.

For another example, the authority management information may include the authority scope or authority type of one or more users. For example, each user has corresponding specific authority management information to indicate what operations the corresponding user can perform on the target account. Correspondingly, the blockchain node can determine the specific authority management information corresponding to the querying party recorded in the authority field, and the specific authority management information may include authority information owned by the querying party, such as query authority, edit authority, delete authority, etc.; Then, in the case that the specific authority management information contains the query authority, the blockchain node can determine that the query party has the query authority, otherwise it is determined that the query party does not have the query authority. The owner of the target account can default to having all the permissions for the target account, and the owner can control adding specific permission management information for at least one user to the permission field to set the permissions of the at least one user. In addition to the owner of the target account, the above-mentioned specific authority management information can also be set by the administrator or other users in the blockchain network, and this manual does not limit this. The above-mentioned specific authority management information adopts a positive description method to define which authority the corresponding user has; similarly, the specific authority management information can adopt a negative description method to define which authority the corresponding user does not have.

Take the target account as an example. By adding the above-mentioned specific authority management information to the target account, it is equivalent to establishing ACL (Access Control Lists) information for these users, for example, identifying whether the querying party has query authority according to the ACL information corresponding to the querying party. According to whether the account contains specific authority management information, the account can be divided into non-ACL accounts (or ordinary accounts) and ACL accounts. The authmap field of all accounts records the public key of the corresponding account owner to give the account all The person’s management authority for the corresponding account (including all permissions such as query permissions); at the same time, all accounts can also contain ACLmap fields, and the ACLmap field in ACL accounts can be used to record specific authority management information as described above, thereby recording relevant The permissions that the user has (such as query permissions or others), and the ACLmap field in the non-ACL account can be empty. In addition to adding the ACLmap field on the basis of related technologies, you can also record specific authority management information in the authmap field, which can avoid field expansion of the account; for example, the authmap field of a non-ACL account only records the public key of the account owner , And the authmap account of the ACL account records the public key of the account owner and specific authority management information for each user at the same time.

Step 106: When the judgment result is that the blockchain node has the query authority, read the private information in cipher text into a trusted execution environment for decryption, so as to obtain the private information in plain text. Provided to the inquiring party.

Trusted Execution Environment (TEE) is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside world. TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. ARM's Trust Zone technology is the first to realize the real commercial TEE technology.

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

Taking Intel SGX technology as an example, SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking the first blockchain node using a CPU that supports SGX as an example, using the newly added processor instructions, a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) can be allocated in the memory, and through the CPU The encryption engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in the EPC will only be decrypted into plaintext after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage. In practical applications, the private data can be encrypted and transmitted to the circle in cipher text, and the corresponding key can also be transmitted to the circle through remote attestation. Then, use the data to perform operations under the encryption protection of the CPU, and the result will be returned in the form of ciphertext. Therefore, encrypting and decrypting the above-mentioned private information based on TEE can ensure sufficient security without worrying about data leakage.

As mentioned earlier, for the privacy information contained in the privacy field in the target account, for privacy protection reasons, the privacy information outside the TEE is in the form of ciphertext, and can only be decrypted after being read into the TEE It is in plain text and is based on the characteristics of TEE to ensure that the private information in plain text will not be stolen. The blockchain node encrypts the private information in the plaintext form in the TEE to obtain the above-mentioned private information in the ciphertext form. Blockchain nodes can use symmetric encryption or asymmetric encryption to implement the above encryption and decryption process, which is not limited in this specification. The encryption algorithm used by symmetric encryption, such as DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. The encryption algorithm used in asymmetric encryption is, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.

Take symmetric encryption as an example. A key can be maintained in the TEE on the blockchain node, the key is a symmetric key, and the private information in plaintext form can be encrypted in the TEE by this key to obtain the above-mentioned private information in ciphertext form . Similarly, the blockchain node reads the private information in the cipher text form into the TEE, and decrypts the private information in the cipher text form with the above key, to obtain the above private information in the plain text form. Since the key is maintained in the TEE, it has sufficient security to avoid the key from leaking.

The blockchain node can generate the above-mentioned key based on a security key maintained in the TEE. In a coarse-grained scenario, the above-mentioned key used by the blockchain node is the security key itself, so that the blockchain node uses the same key when encrypting and decrypting private information of all accounts. In a fine-grained scenario, the above-mentioned key used by the blockchain node is generated by the security key and the impact factor, so that different impact factors can form a differentiated key, and the corresponding account can use different keys Realize the encryption and decryption of private information. Due to the addition of the influence factor, different keys can be used for the privacy information of different accounts. Even if the privacy information of different accounts has the same plaintext, the encrypted ciphertext can also have different values. Then when a user knows When the plaintext of the private information of the account Qa is Ua and the ciphertext is Um, even if the user knows that the ciphertext of the private information of another account Qb is Um, it cannot be inferred that the plaintext of the private information of the account Qb must be Ua( If the keys used in accounts Qa and Qb are different, the same ciphertext corresponds to different plaintext), which helps to improve security. In the case of the impact factor participation, although the blockchain node can maintain all the keys generated by the security key and the impact factor in the TEE, since the frequency of use of the key may not be high, it can only be maintained in the TEE The security key does not maintain the key generated by the security key and the impact factor, but temporarily generates the required key based on the security key and the impact factor when it needs to be used.

By using different impact factors, further granularity can be achieved to meet the privacy protection requirements of different security levels. For example, by using account-related impact factors, account-level privacy protection can be achieved, that is, different accounts use different keys, and all private fields in the same account use the same key; for another example, by using field-related The impact factor can achieve field-level privacy protection, that is, different privacy fields in the same account use different keys, and the same privacy fields in different accounts (such as the Balance field in different accounts) use the same keys; for example, By using impact factors related to accounts and fields at the same time, privacy protection at the account and field levels can be achieved, that is, different accounts use different keys, and different privacy fields in the same account use different keys.

Take the example that the key is generated based on the security key and at least one influence factor related to the target account. The impact factor related to the target account can include at least one of the following: the block height of the block where the account creation transaction corresponds to the target account, the position offset of the account creation transaction in the block, and the target account in all accounts The creation sequence number in, the account address of the target account, etc.

The impact factor may include the block height of the block at which the account creation exchange corresponds to the target account. The account creation transaction can refer to the transaction used to create the target account, and the blockchain node creates the target account by executing the transaction. Then, the blockchain node can determine the block height of the block in the blockchain where the account creation transaction is located, and use it as one of the influencing factors related to the target account. Therefore, when the account creation transactions corresponding to different accounts are in blocks of different heights, it can be ensured that the impact factors corresponding to these accounts are different, so that these accounts correspond to different keys, and therefore the privacy information contained in the privacy fields in these accounts Different keys can be used for encryption and storage, so that the same plaintext corresponds to ciphertext with different values to improve security.

The impact factor may include the position offset of the account creation transaction in the block. Each block on the blockchain contains a number of transactions, which are arranged in sequence in the block, and the position offset can be regarded as the sequence number or index number of each transaction in the block, which is used to perform the transaction. position. For example, the position offset of the transaction in the first position is 0, the position offset of the transaction in the second position is 1, and so on. It can be seen that different transactions in the same block have different position offsets. After a certain block is specified, each transaction can be uniquely located by the position offset. Therefore, when the position offsets of different account creation transactions are different, it can be ensured that the corresponding accounts have different impact factors, so that these accounts correspond to different keys, so the privacy information contained in the privacy fields in these accounts can be different. The key is encrypted and stored so that the same plaintext corresponds to the ciphertext of different values to improve security.

The impact factor may include the creation sequence number of the target account in all accounts. All accounts on the blockchain are created sequentially, and the blockchain node can set the creation sequence number for these accounts according to the creation sequence, so that each account can be distinguished based on the creation sequence number, that is, the creation sequence corresponding to all accounts The numbers are all different. Therefore, based on the difference in the creation sequence number, it can be ensured that the impact factors corresponding to each account are not the same, so that these accounts correspond to different keys, so the privacy information contained in the privacy fields in these accounts can be processed using different keys. Encrypted storage, so that the same plaintext corresponds to ciphertext with different values, to improve security.

The impact factor may include the account address of the target account. The account address is generated when the corresponding account is created, and each account has a unique corresponding account address, that is, the account address corresponding to all accounts is different. Therefore, based on the difference of account addresses, it can be ensured that the corresponding impact factors of each account are not the same, so that these accounts correspond to different keys, so the private information contained in the privacy fields in these accounts can be encrypted with different keys Storage, so that the same plaintext corresponds to ciphertext with different values, to improve security.

Although some impact factors are not unique to each account, such as the block height and position offset mentioned above, when keys are generated based on these impact factors, the probability that different accounts use the same key can still be greatly reduced to improve safety. At the same time, by combining multiple types of impact factors with each other, it can further reduce the probability of different accounts using the same key, and even ensure that all accounts use different keys, thereby completely preventing the same plaintext from being encrypted to generate the same secret. Text, to prevent the value of the plain text can be inferred by comparing the cipher text.

All blockchain nodes in the blockchain network maintain the same security key mentioned above, and all blockchain nodes use the same impact factor for the target account, so that all blockchain nodes generate the same The key ensures that all blockchain nodes obtain the same ciphertext after encrypting the private information contained in the private field in the target account, so that all blockchain nodes can maintain the same state.

Blockchain nodes can obtain the above-mentioned security keys in a variety of ways. For example, after confirming that the blockchain node has passed the remote certification, the key management (KMS) server can issue the security key to the blockchain node, and the blockchain node will maintain the obtained security key In TEE. Then, the KMS server issues the same security key to all blockchain nodes that have passed remote certification, which can ensure that the security keys maintained by all blockchain nodes are consistent. For another example, a security key can be negotiated between blockchain nodes, and all blockchain nodes maintain the negotiated security key in the TEE.

Although blockchain nodes can use the same security key for a long time, there may be some potential or unknown security risks. Therefore, in order to further improve security, the security key maintained by the blockchain node may have a version update, so that the blockchain node can update the version of the security key used regularly or irregularly. There are many ways to update the version of the security key. For example, a blockchain node can obtain an updated version of the security key through the method described above, that is, a new version of the security key is issued through the KMS server, or a new version of the security key is negotiated between the blockchain nodes. For another example, blockchain nodes can implement the version update of the security key by themselves, so as long as the version update logic adopted by all blockchain nodes is consistent, it can ensure that the updated security key is maintained at all blockchain nodes Unanimous.

It is assumed that the security key initially obtained by the blockchain node is the root key, and the version of the root key is the highest. The blockchain node can calculate the security key of the lower version based on the security key of the higher version, thereby obtaining the security key of several versions arranged in sequence. At the same time, the calculation method adopted by the blockchain node can be irreversible calculation, that is, the security key of the higher version can be calculated to obtain the security key of the lower version, but the security key of the lower version can be calculated irreversibly to obtain the security key of the higher version. .

As shown in Figure 2, the above-mentioned root key can be used as the highest version of the security key, and based on the root key, other lower versions of the security key can be generated in turn, such as 256 versions with version numbers ranging from 0 to 255. Security key. For example, by hashing the root key and the version factor 0xFF (the decimal value is 255, that is, the version number of the key that needs to be generated; of course, other values can also be used) to obtain the security of the version number 255 Key key-255; by hashing the security key key-255 and the version factor 0xFE, the security key key-254 with the version number of 254 is obtained; ...by combining the security key key-1 with the version factor 0x00 Perform a hash calculation to obtain the security key key-0 with a version number of 0. 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 security key key-0 can be calculated from the security key key-1 and the version factor 0x00, but it cannot pass the security The key key-0 and version factor 0x00 deduces the security key key-1.

All blockchain nodes in the blockchain network use the same version of the security key to ensure that all blockchain nodes maintain the same world state. Each blockchain node can generate all versions of the security key in advance, and then select the corresponding version of the security key when it needs to update the version of the security key, or it can temporarily generate it when the version of the security key needs to be updated The security key of the corresponding version is not restricted in this manual. Each blockchain node can negotiate to implement the version update of the security key; or, the update logic for the security key can be added to the chain code of the blockchain network, for example, the update logic can be used to determine where Which version of the security key is updated at any time, so that the blockchain node can automatically update the security key based on the update logic.

As mentioned above, because the high version of the key can be calculated to obtain the low version of the security key, and the low version of the security key cannot reverse the high version of the security key, so each blockchain node can start from the low version of the security key. The security key is used, and only the security key of the lower version is allowed to be updated to the security key of the higher version. On the one hand, when the security key of the lower version is lost, the security key of the higher version cannot be changed from the lower version. If the security key is reversed, you only need to upgrade the version of the key to stop the loss in time. On the other hand, the security key of the higher version can be calculated at any time from the security key of the lower version. The encrypted data of the version of the security key is compatible.

In order to indicate the key used in encryption for each account, the blockchain node can associate each encrypted account with the description of the generation method of the corresponding key. Taking the target account as an example, the key generation method description information may include: the version information of the security key and the value of the impact factor related to the target account. For example, as shown in Figure 3, the blockchain node can write the version information of the security key in the Info field, the value of the impact factor in the Nounce field, and the encrypted private information (such as Balance) in the Cipher field. The value of the field), and the Tag field is used to verify the integrity of the Cipher field.

The length of the Info field can be 4Bytes, of which 2Bytes is used to write the key version number, and the remaining 2Bytes are reserved bytes. The length of the Nounce field can be 12Bytes, of which 4Bytes is used to write the height of the historical block, 4Bytes is used to write the position offset of the transaction in the block, and 4Bytes is used to write other information. The length of the Cipher field can be 8Bytes. The length of the Tag field can be 16Bytes. Of course, other field lengths, field combinations, etc. can also be used, which are not limited in this specification. Among them, the blockchain node can also encrypt the description information of the key generation method, for example, the above-mentioned lowest version key-0 can be used for encryption to improve security.

Therefore, when the blockchain node encrypts and stores the private information contained in the private field in the target account, it can be stored in the form of key-value pairs, where the value can adopt the structure shown in Figure 3. Correspondingly, when the blockchain node needs to obtain the private information contained in the private field in the target account, the processing operations adopted include: indexing to the value according to the key, and the structure of the value is shown in Figure 3; using the key key-0 Decrypt the Info and Nounce fields, determine the key version number, historical block height, offset and other information, generate the corresponding key based on the security key, and use the key to decrypt the content of the Cipher field. The data integrity can be verified through the Tag field (if the Tag is generated based on plain text, the decrypted data is verified; if the tag is generated based on cipher text, the data before decryption is verified), so as to obtain privacy in the form of plain text information.

After the blockchain node determines that the querying party has the query authority for the target account, it can obtain the stored private information in the form of ciphertext, and decrypt the private information in the form of ciphertext in the TEE to obtain the corresponding private information in the form of plaintext . Then, the blockchain node can provide the private information in plaintext to the querying party.

In order to avoid the leakage of plaintext private information during data transmission, blockchain nodes can encrypt the plaintext private information before transmitting it to the querying party, and ensure that only the querying party can decrypt the plaintext private information again. For example, the inquiring party can maintain a symmetric key, and share the symmetric key with the blockchain node in some way, so that the blockchain node can use the symmetric key to encrypt private information in plaintext in the TEE Then it is sent to the inquiring party, and the inquiring party can decrypt the private information in plaintext based on the symmetric key. For another example, the inquirer can maintain a private key of the inquirer, and the blockchain node can learn the corresponding public key of the inquirer, so that the blockchain node can use the inquirer's public key to encrypt private information in plaintext in the TEE Then it is sent to the inquiring party, and the inquiring party can decrypt the private information based on the private key of the inquiring party to obtain the private information in plain text.

The symmetric key maintained by the inquiring party can be negotiated between the inquiring party and the blockchain node. Alternatively, the inquiring party can generate (such as randomly generated) the symmetric key, and then share it with the blockchain node in the following way:

When the querying party wants to query the private information in the private field in the target account, it can generate the corresponding plaintext transaction content, encrypt the plaintext transaction content with the above-mentioned symmetric key, and obtain the corresponding ciphertext transaction content. At the same time, there is a node public and private key pair on the blockchain node. The node private key is maintained in the TEE by the blockchain node, and the node public key is disclosed. For example, the query party can learn the node public key, and the node private key can be in After the blockchain node passes the remote certification, it is distributed to the blockchain node by the KMS server. Then the query party can encrypt the above symmetric key with the node public key to obtain the encrypted key, and the transaction submitted by the query party to the blockchain node as mentioned above contains both the ciphertext transaction content and the encrypted key .

Therefore, when the blockchain node receives the transaction submitted by the querying party, it can read the transaction into the TEE, and use the node private key to decrypt the encrypted key contained in the transaction in the TEE to obtain the above-mentioned symmetric Then use the symmetric key to decrypt the ciphertext transaction content contained in the exchange in the TEE to obtain the above-mentioned plaintext transaction content, and then execute the plaintext transaction content to realize the query scheme based on this specification.

It can be seen that based on the above method, the blockchain node can obtain the symmetric key maintained by the inquiring party. The symmetric key is in an encrypted state during transmission and the node private key used for encryption is maintained in the TEE of the blockchain node. At the same time, the blockchain node decrypts the symmetric key in the TEE, that is, when the symmetric key is at the blockchain node, it only exists in plain text in the TEE, which can avoid the occurrence of leakage.

It should be pointed out that the query scheme in this manual can be applied to blockchain networks that only support simple processing logic, such as Bitcoin blockchain, etc.; at the same time, the query scheme in this manual can also be applied to blocks that support complex processing logic. The chain network does not conflict with the complex processing logic based on smart contracts implemented by the blockchain network, and can be compatible.

Fig. 4 is a schematic structural diagram of a device provided by an exemplary embodiment. The device can be configured as a blockchain node in this specification. 4, at the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410. Of course, it may also include hardware required for other services. The processor 402 reads the corresponding computer program from the non-volatile memory 410 to the memory 408 and then runs it to form a query device for account privacy information in the blockchain on a logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and so on. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Referring to FIG. 5, in the software implementation, the device for querying account privacy information in the blockchain may include the following units.

The receiving unit 51 enables the blockchain node to receive the transaction initiated by the inquiring party, the transaction is used to obtain the private information contained in the private field in the target account, and the private information is encrypted and stored at the blockchain node; judge Unit 52 enables the blockchain node to determine whether the inquiring party has the inquiry authority according to the authority management information recorded in the authority field in the target account; the information decryption unit 53 makes the blockchain node to determine whether the result In the case of having the query authority, the private information in the form of cipher text is read into a trusted execution environment for decryption, so as to provide the obtained private information in the form of plain text to the inquiring party.

Optionally, the judging unit 52 is specifically configured to: enable the blockchain node to read the public key of the authority owner contained in the authority management information; and enable the blockchain node to pass the authority owner's public key The public key of the exchange verifies the transaction signature contained in the transaction, and the transaction signature is generated by the private key of the querying party; if the blockchain node passes the verification, it is determined that the querying party has the query Authority; otherwise, it is determined that the inquiring party does not have inquiry authority.

Optionally, the authority owner includes the owner of the target account; or, the authority owner includes the owner of the target account and at least one other user.

Optionally, the judging unit 52 is specifically configured to: enable the blockchain node to determine the specific permission management information corresponding to the inquiring party recorded in the permission field; and enable the blockchain node to be in the In the case that the specific authority management information contains the query authority, it is determined that the query party has the query authority; otherwise, it is determined that the query party does not have the query authority.

Optionally, the status field of the target account includes status indication information, and the status indication information is used to indicate that the private information is stored in plaintext or encrypted and stored at the blockchain node.

Optionally, it further includes: an identification unit 54 to enable the blockchain node to identify the type of the transaction; an execution unit 55 to enable the blockchain node to be free when the transaction belongs to a predefined query type The transaction is executed in the case of consensus.

Optionally, the transaction includes ciphertext transaction content and an encrypted key, the ciphertext transaction content is obtained by encrypting the plaintext transaction content with a symmetric key maintained by the querying party, and the encrypted key is obtained by the node The public key is obtained by encrypting the symmetric key, and the node public key corresponds to the node private key maintained by the blockchain node in the trusted execution environment; the device further includes: a key decryption unit 56 , Enable the blockchain node to read the transaction into the trusted execution environment, and decrypt the encrypted key through the node's private key to obtain the symmetric key; the content decryption unit 57 makes The blockchain node decrypts the ciphertext transaction content through the symmetric key in the trusted execution environment to obtain the plaintext transaction content; the encryption unit 58 makes the blockchain node available in the In the letter execution environment, the symmetric key is used to encrypt the private information in plain text, so as to provide the obtained encrypted information to the querying party.

Optionally, the private information is stored after being encrypted by the blockchain node in the trusted execution environment using a key, and the key is based on a security key maintained in the trusted execution environment. generate.

Optionally, the key is generated based on the security key and at least one influence factor related to the target account.

Optionally, the impact factor related to the target account includes at least one of the following: the block height of the block where the account creation transaction corresponding to the target account is located, and the position of the account creation transaction in the block where the account creation transaction is located. The offset, the creation sequence number of the target account in all accounts, and the account address of the target account.

Optionally, the security key has a version update, and the security key of the lower version is irreversibly calculated from the security key of the higher version.

The systems, devices, modules, or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

In a typical configuration, the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

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

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

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

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

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

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

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

Claims

A query method for account privacy information in the blockchain includes:

The blockchain node receives the transaction initiated by the inquiring party, the transaction is used to obtain the private information contained in the private field in the target account, and the private information is encrypted and stored at the blockchain node;

The blockchain node determines whether the query party has query authority according to the authority management information recorded in the authority field in the target account;

When the result of the judgment is that the blockchain node has query authority, the private information in the form of ciphertext is read into the trusted execution environment for decryption, so as to provide the obtained private information in the form of plaintext to all parties. The query party.
The method according to claim 1, wherein the blockchain node determines whether the inquiring party has the inquiry authority according to the authority management information recorded in the authority field in the target account, comprising:

The blockchain node reads the public key of the authority owner included in the authority management information;

The blockchain node verifies the transaction signature contained in the exchange through the public key of the authority owner, and the transaction signature is generated by the private key of the querying party;

If the blockchain node passes the verification, it is determined that the inquiring party has the inquiry authority; otherwise, it is determined that the inquiring party does not have the inquiry authority.
According to the method of claim 2, the authority owner includes the owner of the target account; or, the authority owner includes the owner of the target account and at least one other user.
The method according to claim 1, wherein the blockchain node determines whether the inquiring party has the inquiry authority according to the authority management information recorded in the authority field in the target account, comprising:

Determining, by the blockchain node, specific authority management information corresponding to the querying party recorded in the authority field;

The blockchain node determines that the inquiring party has the inquiry authority in the case that the specific authority management information includes the inquiry authority; otherwise, it is determined that the inquiry party does not have the inquiry authority.
The method according to claim 1, wherein the status field of the target account contains status indication information, and the status indication information is used to indicate that the private information is stored in plaintext or encrypted and stored at the blockchain node.
The method according to claim 1, further comprising:

The blockchain node identifies the type of the transaction;

When the transaction belongs to a predefined query type, the blockchain node executes the transaction without consensus.
The method according to claim 1, wherein the transaction includes a ciphertext transaction content and an encrypted key, the ciphertext transaction content is obtained by encrypting the plaintext transaction content with a symmetric key maintained by the querying party, and the encryption The latter key is obtained by encrypting the symmetric key with the public key of the node, and the public key of the node corresponds to the private key of the node maintained in the trusted execution environment by the blockchain node; the method further includes:

The blockchain node reads the transaction into the trusted execution environment, and decrypts the encrypted key through the node's private key to obtain the symmetric key;

The blockchain node decrypts the ciphertext transaction content through the symmetric key in the trusted execution environment to obtain the plaintext transaction content;

The blockchain node uses the symmetric key to encrypt the private information in plain text in the trusted execution environment, so as to provide the obtained encrypted information to the querying party.
The method according to claim 1, wherein the private information is stored after being encrypted by the blockchain node in the trusted execution environment using a key, and the key is maintained in the trusted execution environment based on The security key is generated.
According to the method of claim 8, the key is generated based on the security key and at least one influence factor related to the target account.
The method according to claim 9, wherein the impact factor related to the target account includes at least one of the following:

The block height of the block of the account creation exchange corresponding to the target account, the position offset of the account creation transaction in the block where the account creation transaction is located, the creation sequence number of the target account in all accounts, the The account address of the target account.
According to the method of claim 8, the security key has a version update, and the security key of the lower version is irreversibly calculated from the security key of the higher version.
A query device for account privacy information in the blockchain includes:

The receiving unit enables the blockchain node to receive the transaction initiated by the querying party, the transaction is used to obtain the private information contained in the private field in the target account, and the private information is encrypted and stored at the blockchain node;

A judging unit, enabling the blockchain node to judge whether the inquiring party has inquiry authority according to the authority management information recorded in the authority field in the target account;

The decryption unit enables the blockchain node to read the private information in ciphertext form into a trusted execution environment for decryption when the judgment result is that it has query authority, so as to obtain the privacy information in plaintext form. Information is provided to the inquiring party.
An electronic device including:

processor;

A memory for storing processor executable instructions;

Wherein, the processor implements the method according to any one of claims 1-11 by running the executable instruction.
A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-11.