CN113098697B - Block chain data writing and accessing method and device - Google Patents

Abstract

The embodiments of the present application provide a method and device for writing and accessing blockchain data, which are used to improve the security of data storage and data access on the blockchain. The method includes: each consensus node obtains a data write request sent by a data owner respectively; wherein, each data write request includes the same target ciphertext data and different key shares from each other, and the target ciphertext data is The data owner encrypts the plaintext data with the target key, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism; The target ciphertext data is subjected to consensus processing; after it is determined that a consensus is reached on the target ciphertext data, each consensus node saves the obtained target ciphertext data and key shares respectively.

Description

A method and device for writing and accessing blockchain data

technical field

The present application relates to the field of blockchain technology, and in particular to a method and device for writing and accessing blockchain data.

Background technique

Blockchain is a composite technology that uses cryptography, computer networks, and distributed storage technologies. Blockchain provides a distributed data sharing model with decentralization (point-to-point Tampering, leaving traces throughout the process, collective maintenance, openness and transparency, etc. Based on these characteristics of the blockchain, users can store data on the blockchain to achieve data sharing through the blockchain. User data generally involves the user's own privacy, so it is necessary to effectively protect the data stored on the blockchain to ensure data security.

In order to ensure the security of data on the blockchain, it is necessary to carry out security control in the process of data storage and data access. Therefore, how to improve the security of data storage and access on the blockchain is a problem that needs to be considered.

SUMMARY OF THE INVENTION

The embodiments of the present application provide a method and device for writing and accessing blockchain data, which are mainly used to improve the security of data storage and data access on the blockchain.

According to a first aspect of the embodiments of the present application, a method for writing blockchain data is provided, the method comprising:

Each consensus node obtains the data write request sent by the data owner respectively; wherein, each data write request includes the same target ciphertext data and different key shares from each other, and the target ciphertext data is the data owner. Obtained by encrypting plaintext data with the target key, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism;

The respective consensus nodes perform consensus processing on the target ciphertext data;

After it is determined that a consensus is reached on the target ciphertext data, each consensus node saves the obtained target ciphertext data and key shares respectively.

In a possible implementation manner, each data writing request further includes a key share signature corresponding to the key share, and each consensus node saves the obtained target ciphertext data and key share, including:

The respective consensus nodes store the obtained target ciphertext data, the key share and the corresponding key share signature.

In a possible implementation manner, each data writing request further includes access access condition information; after it is determined that a consensus is reached on the target ciphertext data, each consensus node saves the obtained target ciphertext data and Key shares, including:

After determining that both the target ciphertext data and the access access condition information have reached a consensus, each consensus node saves the obtained target ciphertext data, key share and access access condition information; or,

After it is determined that a consensus is reached on the target ciphertext data, each consensus node saves the obtained target ciphertext data, key share and access condition information.

In a possible implementation manner, the access access condition information includes condition information that allows the data owner to access the target ciphertext data.

In a possible implementation manner, after the respective consensus nodes save the obtained target ciphertext data and key shares, the method further includes:

The respective consensus nodes respectively send successful write indication information to the data owner, for the data owner to determine that the target ciphertext data is successfully written when the received successful write indication information exceeds a predetermined number .

In a possible implementation manner, each consensus node saves the obtained key share in the trusted execution environment of each consensus node.

According to a second aspect of the embodiments of the present application, a blockchain data access method is provided, the method comprising:

Each consensus node obtains a data access request initiated by the data access party, wherein the data access request includes a target data identifier;

The respective consensus nodes determine the target ciphertext data and the key share corresponding to the target data identifier from the local storage, wherein the key shares stored locally by the respective consensus nodes are different from each other, and each key share is the owner of the data. The target ciphertext data is obtained by splitting the target key through a secret sharing mechanism, and the target ciphertext data is obtained by encrypting the plaintext data with the target key by the data owner;

The respective consensus nodes send the locally stored target ciphertext data and key shares to the data access party, so that the data access party can determine the target key according to a predetermined number and different key shares, and decrypt the target ciphertext data according to the target key.

In a possible implementation manner, each consensus node determines the target ciphertext data and key share corresponding to the target data identifier from local storage, including:

The respective consensus nodes determine the target ciphertext data, the key share and the corresponding key share signature corresponding to the target data identifier from the local storage;

The respective consensus nodes send the locally stored target ciphertext data and key shares to the data access party, including:

The respective consensus nodes respectively send the locally stored target ciphertext data, the key share and the corresponding key share signature to the data access party.

In a possible implementation manner, the data access request further includes the permission information and permission signature of the data access party to be verified, and the locally stored target ciphertext data and key share are respectively stored at the consensus nodes. Before sending to the data access party, the method further includes:

The respective consensus nodes determine that the access authority verification of the data access party has passed according to the authority information to be verified and the authority signature; wherein, the authority information to be verified is verified according to the authority signature, and When the verification of the authority information to be verified is passed, it is determined that the verification of the access authority of the data access party is passed according to the authority information to be verified.

In a possible implementation manner, determining that the access authority verification of the data access party passes the verification according to the authority information to be verified, including:

Matching the permission information to be verified with access access condition information, wherein the access access condition information is determined by the data owner;

If the matching result is the set matching result, it is determined that the access authority verification of the data access party has passed.

In a possible implementation manner, the access access condition information includes condition information that allows the data owner to access the target ciphertext data.

In a possible implementation manner, each consensus node determines that the verification of the access authority of the data access party has passed according to the authority information to be verified and the authority signature, including:

The respective consensus nodes determine that the access authority verification of the data access party has passed according to the authority information to be verified and the authority signature; or,

The respective consensus nodes perform consensus processing on the permission information to be verified and the permission signature, and after reaching a consensus, determine that the access permission verification of the data access party has passed.

According to a third aspect of the embodiments of the present application, a block chain data writing device is provided, the device is configured in each consensus node, and the device includes:

The obtaining module is used to obtain the data writing request sent by the data owner; wherein, each data writing request includes the same target ciphertext data and different key shares from each other, and the target ciphertext data is owned by the data. The data is obtained by encrypting the plaintext data with the target key, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism;

a consensus module for performing consensus processing on the target ciphertext data;

The storage module is configured to save the obtained target ciphertext data and key share after it is determined that a consensus has been reached on the target ciphertext data.

In a possible implementation manner, each data write request further includes a key share signature corresponding to the key share, and the storage module is used for:

Save the obtained target ciphertext data, key share and corresponding key share signature.

In a possible implementation manner, each data write request further includes access access condition information, and the storage module is used for:

After it is determined that a consensus is reached on the target ciphertext data and the access access condition information, the obtained target ciphertext data, key share and access access condition information are saved; or,

After it is determined that a consensus is reached on the target ciphertext data, the obtained target ciphertext data, key share and access condition information are saved.

In a possible implementation manner, the access access condition information includes condition information that allows the data owner to access the target ciphertext data.

In a possible implementation manner, the apparatus further includes a sending module for:

After the storage module saves the obtained target ciphertext data and key share, it sends the successful write indication information to the data owner, so that the data owner receives the successful write indication information exceeding a predetermined value When the number is determined, the target ciphertext data is successfully written.

According to a fourth aspect of the embodiments of the present application, a blockchain data access device is provided, the device is configured in each consensus node, and the device includes:

an obtaining module for obtaining a data access request initiated by a data access party, wherein the data access request includes a target data identifier;

The determining module is used to determine the target ciphertext data and the key share corresponding to the target data identifier from the local storage, wherein the key shares stored locally by each consensus node are different from each other, and each key share is the owner of the data. The target ciphertext data is obtained by splitting the target key through a secret sharing mechanism, and the target ciphertext data is obtained by encrypting the plaintext data with the target key by the data owner;

A sending module, configured to send the locally stored target ciphertext data and key shares to the data access party, so that the data access party can determine the target key according to a predetermined number and different key shares, and Decrypt the target ciphertext data according to the target key.

In a possible implementation manner, the determining module is used for:

Determine the target ciphertext data, the key share and the corresponding key share signature corresponding to the target data identifier from the local storage;

The sending module is used for:

Send the locally stored target ciphertext data, the key share and the corresponding key share signature to the data access party.

In a possible implementation manner, the data access request further includes the permission information to be verified and the permission signature of the data access party, and the device further includes a permission verification module for:

Before the sending module sends the locally stored target ciphertext data and key share to the data access party, determine that the access authority verification of the data access party has passed according to the permission information to be verified and the permission signature; Wherein, the authority information to be verified is verified according to the authority signature, and when the verification of the authority information to be verified is passed, it is determined that the access authority verification of the data access party is passed according to the authority information to be verified.

In a possible implementation manner, the authority verification module is used for:

Matching the permission information to be verified with access access condition information, wherein the access access condition information is determined by the data owner;

If the matching result is the set matching result, it is determined that the access authority verification of the data access party has passed.

In a possible implementation manner, the access access condition information includes condition information that allows the data owner to access the target ciphertext data.

In a possible implementation manner, the authority verification module is used for:

According to the permission information to be verified and the permission signature, it is determined that the access permission verification of the data access party has passed; or,

Consensus processing is performed on the permission information to be verified and the permission signature, and after reaching a consensus, it is determined that the access permission verification of the data access party has passed.

According to a fifth aspect of the embodiments of the present application, a blockchain system is provided, including at least two consensus nodes, wherein:

Each consensus node is used to obtain the data write request sent by the data owner respectively, wherein each data write request includes the same target ciphertext data and different key shares from each other, and the target ciphertext data is the data The owner encrypts the plaintext data with the target key, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism; and performs consensus processing on the target ciphertext data ; and respectively save the obtained target ciphertext data and key share after reaching a consensus on the target ciphertext data.

According to a sixth aspect of the embodiments of the present application, a blockchain system is provided, including at least two consensus nodes, wherein:

Each consensus node is used to obtain the data access request including the target data identifier initiated by the data access party; and determine the target ciphertext data and key share corresponding to the target data identifier from the local storage, wherein each consensus node has a local The stored key shares are different from each other, each key share is obtained by the data owner splitting the target key through a secret sharing mechanism, and the target ciphertext data is the data owner using the target key to pair the plaintext. obtained by encrypting the data; and respectively sending the locally stored target ciphertext data and key shares to the data access party, so that the data access party can determine the target key according to a predetermined number and different key shares , and decrypt the target ciphertext data according to the target key.

According to a seventh aspect of the embodiments of the present application, a computer storage medium is provided, where a computer-readable program is stored in the computer storage medium, and the computer-readable program is used to execute the method described in the above-mentioned first aspect .

According to an eighth aspect of the embodiments of the present application, a computer storage medium is provided, where a computer-readable program is stored in the computer storage medium, and the computer-readable program is used to execute the method described in the second aspect above .

According to a ninth aspect of the embodiments of the present application, there is provided a computer program product that encodes an instruction for executing a process, the process including the method described in the first aspect above.

According to a tenth aspect of the embodiments of the present application, there is provided a computer program product, the computer program product encoding an instruction for executing a process, the process including the method described in the second aspect above.

According to the method and device for writing and accessing blockchain data in the embodiments of the present application, when the data owner uploads and stores the target ciphertext data on the chain, the target key used to encrypt and obtain the target ciphertext data is split into multiple The key shares are distributed and stored in each consensus node in the blockchain system in a distributed manner. The cryptographic technology of secret sharing is used to store each key share separately, even if the individual key shares are Malicious theft or tampering does not affect the accurate recovery of the target key, which improves the security of the target key in the blockchain system, thereby improving the security of the target ciphertext data. Furthermore, when the data access party accesses the target ciphertext data on the chain, on the basis of effectively protecting the target ciphertext data through multiple distributed key shares, it can also ensure that the data access party can pass a certain number of keys. The share restores the correct target key, thereby realizing effective and safe access to the target ciphertext data, and improving the security of access to the data stored on the blockchain.

Description of drawings

The drawings described herein are used to provide further understanding of the present application and constitute a part of the present application. The schematic embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation of the present application. In the attached image:

FIG. 1 is a schematic diagram of an application scenario to which an embodiment of the present application is applicable;

2 is a schematic flowchart of a method for writing blockchain data in an embodiment of the present application;

3 is a schematic flowchart of a blockchain data access method in an embodiment of the application;

FIG. 4 is a schematic diagram of a process of requesting data writing from a data owner-directed blockchain system in an embodiment of the application;

FIG. 5 is a schematic diagram of a process of requesting a data access direction block chain system to read data in an embodiment of the application;

6 is a structural block diagram of a block chain data writing device in an embodiment of the application;

FIG. 7 is a structural block diagram of a blockchain data access device in an embodiment of the present application.

Detailed ways

In order to make the technical solutions and advantages of the embodiments of the present application clearer, the exemplary embodiments of the present application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and Not all embodiments are exhaustive. It should be noted that the embodiments in the present application and the features of the embodiments may be combined with each other in the case of no conflict.

The technical solutions of the embodiments of the present application can be applied to the blockchain system, and through the technical solutions, a certain degree of security control can be performed when writing data to the blockchain system and accessing data on the blockchain, and further It can improve the security of data on the blockchain.

In order to better understand the technical solutions provided by the embodiments of the present application, some application scenarios to which the technical solutions provided by the embodiments of the present application are applicable are briefly introduced below. It should be noted that the application scenarios introduced below are only used to illustrate the embodiments of the present application. rather than limiting. During specific implementation, the technical solutions provided by the embodiments of the present application may be flexibly applied according to actual needs.

Please refer to FIG. 1. FIG. 1 is an application scenario to which the technical solution of the embodiment of the present application is applicable, which includes a data owner, a blockchain system, and a data accessor, and the data owner and data accessor may be clients. , terminal equipment, or a trusted certification center or an upper-layer program of a consensus protocol. Both the data owner and the data access party can communicate with the blockchain system. The data owner can send the data they want to store to the blockchain system to realize the on-chain storage of the data, and the data access party can request the blockchain system. To read the desired data, for example, you want to read the data stored on the chain by the aforementioned data owner, or you want to read the data stored on the chain before the data access party itself, so as to achieve the purpose of sharing data.

The blockchain system in Figure 1 can be understood as a blockchain network, which is a peer-to-peer communication network. The blockchain system includes multiple blockchain nodes that can communicate with each other. The node may be a physical node such as a server, or may be a logical node, which is not limited in this embodiment of the present application. Multiple blockchain nodes in a blockchain system can form a consensus network, and each blockchain node that constitutes a consensus network can also be called a consensus node. The consensus network can use a specific consensus algorithm to process information by consensus to reach a consensus. . The blockchain system has the characteristics of decentralization, non-tampering, full trace, collective maintenance, openness and transparency, etc. With the development of blockchain technology, its application in various fields is becoming more and more extensive. In practical applications, security protection is required for data involving some business scenarios to ensure the interests of users.

Each node in the blockchain system in Figure 1 can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud service, cloud database, cloud computing, cloud function, Cloud servers for basic cloud computing services such as cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms, and other basic cloud computing services. make restrictions.

The technical solutions of the embodiments of the present application are respectively described from the aspects of data writing (that is, storing data on the chain) and data access. The data access solution is implemented based on the data writing solution. When the blockchain system writes data, the key used to encrypt the data is split into multiple key shares using secret sharing technology, and then the encrypted data and each key share are uploaded to the blockchain system and stored in the blockchain system. In each blockchain node of the blockchain system, the keys of encrypted data are distributed in the blockchain system in this way. According to the principle of secret sharing technology, even if some blockchain nodes in the blockchain system fail ( For example, it has been controlled by an adversary or hardware failure, etc.), if there is not a sufficient number of key shares, the target key cannot be recovered, so as to achieve effective protection of the target key, and it can also ensure that the data access party can get a certain amount ( This number is related to the secret sharing technology) to recover the correct encryption key to decrypt the encrypted data, so as to obtain the correct plaintext data and complete the secure access to the data on the chain.

For ease of understanding, the following describes the process of data uploading on the chain with reference to Figure 2. The process of data uploading to the chain is the process in which the data owner writes the data to be stored into the blockchain system for storage. FIG. 2 is a schematic flowchart of a method for writing blockchain data according to an embodiment of the present application. The flowchart shown in FIG. 2 is described as follows.

S201: The data owner encrypts the plaintext data with the target key to obtain the corresponding target ciphertext data.

For example, the data owner needs to store a certain transaction data on the chain. In order to ensure the security of the transaction data, the transaction data can be encrypted before being uploaded to the chain. For example, the transaction data can be encrypted by using a general symmetric encryption algorithm. processing, the transaction data can be understood as the plaintext data in the embodiment of the present application, the key used for encryption can be understood as the target key in the embodiment of the present application, and the encrypted data obtained by encryption processing can be understood as the implementation of the present application The target ciphertext data in the example.

The data owner may be any authorized client, a trusted certification center, or an upper-layer program of a consensus protocol, which is not limited in this embodiment of the present application.

S202: The data owner uses a secret sharing mechanism to split the target key into at least two key shares.

That is to say, the target key can be split into multiple key shares, that is, the target key is split according to a specific algorithm, and each key share obtained by splitting is different.

In the embodiments of the present application, the secret sharing technology is used to realize the splitting of the target key, and the secret sharing technology is briefly introduced below.

The idea of secret sharing technology is to split the secret in an appropriate way. Each share obtained after splitting can be managed by different participants. A single participant cannot recover the secret information, and only several participants can cooperate to recover the secret information. More importantly, in the event of a problem with any of the corresponding in-scope participants, the secret can still be fully recovered. Secret sharing is a cryptographic technology that separates and stores secrets. The purpose is to prevent secrets from being too concentrated, so as to achieve the purpose of dispersing risks and tolerating intrusions. It is an important means in information security and data secrecy. There are two parameters in secret sharing. For example, if t and n represent these two parameters, it can be called (t, n) secret sharing, where n represents the number of shares to split the secret into, and t represents at least the number of shares to be obtained. Only t shares can recover the secret, and any less than t shares cannot obtain any relevant information about the secret. The specific understanding is as follows:

Assuming that the secret secret is split into n-share secret shares, then the secret secret can be recovered by any t (2≤t≤n) or more secret shares, and any one or more secret shares less than t can be recovered. The secret share cannot get any useful information about the secret secret.

In practice, depending on the choice of t and n, safety and reliability can be traded off. In general, larger values of t provide high security and low reliability; lower values of t provide low security and high reliability.

According to the secret sharing technology introduced above, for example, the target key is split into corresponding n (n is an integer greater than or equal to 2) key shares, and the n key shares obtained by splitting are, for example: K1, K2, K3, ..., Kn.

In this embodiment of the present application, the number of data owners splitting the target key into key shares using a secret sharing mechanism can be determined according to the number of consensus nodes included in the consensus network in the blockchain system. The number of key shares is the same as the number of consensus nodes, that is, how many consensus nodes there are, the target key is divided into how many key shares, and for example, the number of key shares can be slightly more than the number of consensus nodes, here The "slightly more" refers to the set value that is larger than the number of consensus nodes. The set value is, for example, a small integer such as 1, 2, or 3. The set value here is also the same as the t value in the secret sharing technology. Related, this ensures that each consensus node gets a key share that is different from each other, but also ensures that a sufficient number of mutually different key shares are obtained from the consensus nodes to recover accurately out the target key.

For example, if the consensus network in the blockchain system includes 20 consensus nodes, the data owner can split the target key into 20 key shares, so that the 20 key shares can be sent to each Consensus nodes, the 20 key shares can be obtained from each consensus node as much as possible in the future. Even if some of the consensus nodes fail, enough key shares can be obtained to recover the target key, so as to realize the target ciphertext data. accurate decryption.

For another example, the consensus network in the blockchain system includes 20 consensus nodes, then the data owner can split the target key into 21 key shares, so that the 20 keys in the obtained key shares can be divided into 20 key shares. It is sent to each consensus node, and the 20 key shares can be obtained from each consensus node later, even if all keys cannot be obtained (all keys are 21), and even if some of the consensus nodes fail and cannot be obtained correctly. The key shares kept by the consensus nodes can also obtain enough key shares to recover the target key, so as to achieve accurate decryption of the target ciphertext data.

S203: The data owner performs signature processing on each key share to obtain a key share signature corresponding to each key share.

Some common signature methods can be used to sign the key share. For example, a hash algorithm can be used to calculate the digital digest of the key share, and then the digital digest can be encrypted by using the private key in the asymmetric key. The resulting digital digest is the signature of the key share, called the key share signature. For example, the key share signatures corresponding to the key shares K1, K2, K3, ..., Kn are represented by Sig1, Sig2, Sig3, ..., Sign, respectively.

S204: The data owner determines access access condition information corresponding to the target ciphertext data.

Wherein, the access access condition information is the filter condition information used to control the access to the target ciphertext data. In the specific implementation process, the access access condition information may be an access control list (Access Control List, ACL), for example, it may be The blacklist or whitelist of user IDs, client IDs, device IDs and other user IDs, client IDs, and device IDs specified by the data owner to allow or disallow access to the target ciphertext data, or the access condition information can also be a specific access control condition, which can be understood as It is a restriction set by the data owner to allow or not allow access to the target ciphertext data. For example, to allow women between the ages of 35 and 50 to access the target ciphertext data, the "women between the ages of 35 and 50" can be understood. It is an access control condition, or, people younger than 20 years old or older than 65 years old are not allowed to access the target ciphertext data, in which "people younger than 20 years old or older than 65 years old" can be understood as access control conditions .

In practice, users may lose the encrypted data obtained by their own encryption or forget the encryption key of their own encrypted data, such as the above-mentioned target ciphertext data. The data owner encrypts the target plaintext data locally with the target key to obtain the target password. After the data is stored, the target ciphertext data may be lost (for example, deleted or stolen by mistake) or the target key may be forgotten. Even if the target key is known, the decryption operation cannot be performed. For example, when you forget the target key but want to obtain the target plaintext data or want to reset the key for the target ciphertext data, because there is no target key for encryption, it is also Therefore, it is impossible to perform these operations, and it can be seen that it is inconvenient for users to manage encrypted data. In view of this, in the embodiment of the present application, the data owner may allow the data owner to access the access condition information for the target ciphertext data when setting the access condition information. Condition information for the data owner to access the target ciphertext data, for example, the identity information such as the user ID of the data owner can be added to the access access condition information, so that after the target ciphertext data is stored on the blockchain and stored in the blockchain system , the data owner can then request the blockchain system to read the target ciphertext data as a visitor to obtain the target ciphertext data and the corresponding multiple key shares, and then the target ciphertext data can be retrieved from the blockchain system and multiple key shares, and then use the target key recovered from the multiple key shares to decrypt the target ciphertext data to obtain the corresponding target plaintext data, or the target ciphertext data can be decrypted according to the recovered target key. The key reset process is performed, so that it is convenient for the data owner to access the target ciphertext data on-chain and secondary management.

S205: The data owner generates a data write request according to the number of consensus nodes.

Specifically, how many consensus nodes can generate the same number of data write requests, that is, the number of data write requests is the same as the number of consensus nodes. As mentioned before, the number of key shares may be equal to or greater than the total number of consensus nodes. Considering the actual situation, when the number of key shares is the same as the total number of consensus nodes, for example, both are 20, then you can use All key shares are used to generate the same number of data write requests, so that each of the 20 data write requests generated includes one key share, and the key shares included in the 20 data write requests are each other’s Different; when the number of key shares is greater than the total number of consensus nodes, for example, the number of key shares is 21 and the total number of consensus nodes is 20, then part of the key shares can be used (that is, using random 20 of them). key share) to generate 20 data write requests, each of the 20 generated data write requests includes one key share, and the key shares included in the 20 data write requests are different from each other . That is to say, the data owner can generate the same number of data write requests as the total number of consensus nodes, and the key shares carried in each data write request are different from each other.

In addition to the above-mentioned key shares, each data write request also includes target ciphertext data, and also includes access condition information and/or key share signatures. The key shares included and the corresponding key share signatures are different. That is to say, the same part included in each data write request is the target ciphertext data and access access condition information, and the different parts included are the key share and the corresponding key share signature.

In addition, it should be noted that the above-mentioned S203 and S204 may be optional steps, so they are represented by dotted lines in FIG. 2 . That is to say, in the specific implementation process, S203 and/or S204 may be executed, or S203 and/or S204 may not be executed. Correspondingly, if S203 is not executed, the data write request generated by the data owner does not include the key share signature, and if S204 is not executed, the data write request generated by the data owner also does not contain the key share signature. Does not include access access condition information, and can flexibly choose the implementation of S203 and S204 during implementation, and then flexibly configure the information included in the data write request to implement different verification functions, which is not limited in this embodiment of the present application.

S206: The data owner sends each data write request to each consensus node, and correspondingly, each consensus node obtains the data write request sent by the data owner respectively.

As mentioned earlier, the number of data write requests generated by the data owner is the same as the total number of consensus nodes, so that the data owner can send each data write request to a different consensus node, so that each Each consensus node obtains different key shares, so that each key share corresponding to the target key can be distributed in different nodes in the blockchain system to achieve distributed storage of key shares, In this way, even if an individual consensus node has been controlled by an adversary (such as being attacked by a malicious person), the consensus node cannot recover the target key because it cannot obtain enough (such as the aforementioned t) key shares. The security of the target key can be ensured to a large extent.

Continuing the foregoing example, since there are n key shares K1, K2, K3, . 2. Data write request 3, ..., data write request n, and send these n data write requests to consensus node 1, consensus node 2, consensus node 3, ..., consensus node n respectively. It should be noted that, in order to simplify the illustration, only the consensus node 1 and the consensus node n are shown in FIG. 2 , and other consensus nodes are represented by "..." instead.

Continuing to refer to FIG. 2 , the step of the data owner correspondingly sending each data write request to each consensus node may specifically include steps S206a, S206n and the like. Among them, S206a is that the data owner sends the data write request 1 carrying the target ciphertext data and key share 1 to the consensus node 1, and S206n is that the data owner writes the data carrying the target ciphertext data and key share n Request n is sent to consensus node n. It should be noted that, in order to simplify the illustration, only the consensus node 1 and the consensus node n are used for illustration in Figure 2, so only the consensus node 1 and the consensus node n are shown in Figure 2, and the other consensus nodes are marked with "… "..." instead means that in the specific implementation process, other more consensus nodes may be included. Correspondingly, the data owner may also send different data writes that carry other key shares and target ciphertext data to other consensus nodes. ask.

S207: Each consensus node performs consensus processing on the target ciphertext data, and reaches a consensus.

After each consensus node in the blockchain system obtains the data write request sent by the data owner, each consensus node obtains the same target ciphertext data. The ciphertext data is processed by consensus to ensure that the target ciphertext data finally stored by each consensus node is accurate, unique and valid, that is, to ensure that the target ciphertext data finally stored by each target blockchain node is the same correct data .

Each consensus node in the blockchain system can form a consensus network. In the specific implementation process, the consensus network can use a predetermined consensus algorithm to perform consensus processing on the target ciphertext data to reach a consensus on the target ciphertext data. Yes, the consensus network performs consensus processing on the target ciphertext data, that is, each consensus node jointly performs consensus processing on the target ciphertext data. Among them, the predetermined consensus algorithm can adopt the current common consensus algorithm, such as Proof of Work (Pow) algorithm, Proof of Stake (PoS) algorithm, Delegated Proof of Stake (DPoS), practical Byzantine Fault Tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm, etc.

Reaching a consensus on the target ciphertext data, on the one hand, may include reaching a consensus on the target ciphertext data itself, and on the other hand, it may also include reaching a consensus on the sorting information of the target ciphertext data, where the sorting information is used to indicate the target ciphertext data. The order of arrangement in the blockchain system, for example, can be information such as number or serial number. In this way, each consensus node in the consensus system can reach a consensus on the data itself and the arrangement order of the target ciphertext data, that is, it is determined that the target ciphertext data and the corresponding arrangement order are unique and accurate.

In a possible implementation, the consensus network can also perform consensus processing on the access access condition information in each data write request and reach a consensus, so as to ensure that the access access condition information finally determined and stored by each consensus node is Accurate and unique information to ensure access to access condition information is valid.

S208: Each consensus node saves the obtained target ciphertext data and key shares respectively.

That is to say, after the consensus system reaches a consensus on the target ciphertext data, each consensus node stores the same copy of the target ciphertext data received from the data owner locally, and stores the data received from the data owner respectively. Different key shares are also stored locally, thus realizing the on-chain storage of target ciphertext data and multiple key shares, and since each key share is stored in different consensus nodes, this can be achieved. Realize the separate storage of several key shares, so that even if a consensus node fails, such as being attacked by an adversary, the key shares saved in the failed consensus node are leaked, but since the adversary cannot obtain other key shares, so It is impossible to obtain a sufficient number of key shares to recover the target key, so the method of storing each key share separately can improve the security of the target key, thereby ensuring the security of the target ciphertext data stored on the chain.

In addition, if the data write request also includes key share signature and/or access access condition information, each consensus node can also send the received key share signature and/or access access condition information together with the target ciphertext data It is stored locally with each consensus node together with the key share.

For example, if the data writing request also includes a key share signature, each consensus node can sign the obtained target ciphertext data, key share, and corresponding key share after determining that they have reached a consensus on the target ciphertext data. Saved locally on each consensus node.

For another example, if the data writing request also includes access access condition information, after each consensus node determines to reach a consensus on the target ciphertext data, or each consensus node determines that both the target ciphertext data and the access access condition information are After reaching a consensus, the obtained target ciphertext data, key share, and access access condition information can be saved locally in each consensus node.

For another example, if the data writing request also includes key share signature and access access condition information, then each consensus node determines that the target ciphertext data has reached a consensus, or each consensus node determines that the target ciphertext data and After reaching a consensus on the access access condition information, the obtained target ciphertext data, access access condition information, key share, and the corresponding key share signature can be stored locally in each consensus node, that is, these data are stored locally.

S209: Each consensus node sends the successful write indication information to the data owner respectively, and correspondingly, the data owner receives the successful write indication information sent by each consensus point.

After each consensus node saves the information in the data write request sent by the data owner locally, it can send the successful write indication information to the data owner respectively, and the successful write indication information is used to indicate the corresponding data write request. The data to be written has been successfully stored in each consensus node, for example, the target ciphertext data and key share in the data write request have been successfully stored in the consensus node.

During implementation, the successful writing indication information sent by each consensus node to the data owner may be the same, that is, the sent format and content may be the same, or they may be different, in FIG. The successful write indication information of , is illustrated as an example.

S210: When the data owner determines that the successful writing indication information exceeds a predetermined number, it is determined that the target ciphertext data has been successfully written.

In practice, since individual consensus nodes in the blockchain system may have been maliciously attacked or malfunctioned, these consensus nodes may not be able to successfully send the successful write indication to the data owner, but generally speaking, normal The number of consensus nodes running is the majority, that is, the number of successful write indications received by the data owner may be equal to or less than the number of consensus nodes. For this reason, even if the data owner fails to receive the write success indication information sent by all the consensus nodes, it can determine the target ciphertext data and the target ciphertext data through a predetermined number (for example, referred to as the first predetermined number) of successful write indication information. The key (corresponding to multiple key shares in decentralized storage) has been successfully written into the blockchain system, that is, when the received successful write indication information exceeds the first predetermined number, it can be considered that the target ciphertext data and the target key It has been successfully stored in the blockchain system. The first predetermined number here is related to the value of t in the (t, n) secret sharing mechanism introduced above. The first predetermined number can be any integer equal to or greater than t and less than or equal to n, which ensures that the The number of accurately stored key shares is sufficient for subsequent recovery of the target key. Or, for example, the entire consensus system includes n consensus nodes, and assuming that the number of nodes that have been controlled by the adversary in the entire consensus system is at most f, then the value of t can be f+1≤t≤n-f, that is, the value of t The value can be determined according to the assumed number of failed nodes in the consensus system.

In the specific implementation process, when each consensus node saves the key share, it can save the key share in the Trusted Execution Environment (TEE) of each consensus node to improve the security of the key share as much as possible.

Specifically, in order to ensure the security of the target ciphertext data and key share as much as possible, each consensus node can save the target ciphertext data and key share in the trusted execution environment of the consensus node when storing them. Taking a consensus node (for example, consensus node A) as an example, consensus node A can save the target ciphertext data, key share, and the corresponding key share signature in the first storage area, and save the access access condition information. In the second storage area, the second storage area is a conventional memory area, and the first storage area is located in the TEE, which can further ensure the security of the target ciphertext data and the key share. In another possible implementation, since the trusted execution environment requires additional maintenance, in order to reduce the storage occupation of the TEE, it is necessary to maintain the security of the key share as much as possible to ensure the security of the target ciphertext data. Only the key shares can be stored in the trusted execution environment, and the target ciphertext data, access condition information, and key share signatures can be stored in the conventional storage area, or only the key shares and key shares can be stored The signature is stored in the TEE, and the target ciphertext data and access condition information are stored in the conventional storage area to ensure the security of the key share as much as possible.

Among them, TEE is a trusted execution environment based on the security extension of CPU hardware and completely isolated from the outside world. TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and to provide a trusted and secure execution environment for applications in parallel with the operating system. With the rapid development of the Internet, the demand for security is getting higher and higher, not only mobile devices, cloud devices, and data centers have put forward more demands on TEE, and the concept of TEE has also been rapidly developed and expanded. Compared with the concept originally proposed, TEE is a broader TEE. For example, server chip manufacturers Intel, AMD, etc. have successively launched hardware-assisted TEE and enriched the concept and characteristics of TEE. widely recognized.

Taking Intel SGX technology as an example, SGX provides an encrypted trusted execution area in memory, and data is protected from theft by the CPU. Taking the above-mentioned consensus node A using a CPU supporting SGX as an example, using the newly added processor instructions, a part of the memory of consensus node A can be allocated as an enclave page cache or an enclave page cache (Enclave PageCache, EPC), The data of the EPC is encrypted by the encryption engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in the EPC will only be decrypted after entering the CPU. Therefore, the key share can be stored in this area. In SGX, users can not trust the operating system, virtual machine monitor (Virtual Machine Monitor, VMM), or even the basic input output system (Basic Input Output System, BIOS), only need to trust the CPU to ensure that private data will not leak, Therefore, by storing the key share in the EPC, the sufficient security of the key share can be ensured, and the possibility of the key share being leaked is very small.

In the blockchain data writing scheme in the embodiment of the present application, since a secret sharing mechanism is used to split the target key and store it in a distributed manner in multiple consensus nodes in the blockchain system, it can improve the The security of the target key, so that even if some blockchain nodes are invalid or insecure due to malicious attacks or hardware failures, it is difficult for an attacker to obtain a certain number of keys (such as the aforementioned t) share to restore the target key, which further ensures the security of the target ciphertext data, thereby improving the security of data storage on the chain.

Figure 2 above introduces the process of the data owner uploading the target ciphertext data and each key share to the blockchain system. The process of the chain system requesting access to the target ciphertext data is introduced. FIG. 3 is a schematic flowchart of a blockchain data access method in an embodiment of the present application. The flowchart shown in FIG. 3 is described as follows.

S301: The data access direction initiates a data access request to each consensus node, and correspondingly, each consensus node obtains the data access request initiated by the data access party.

When the data access party wants to read the data on the blockchain, it can send a request to the blockchain system. For example, when the data access party wants to read the target ciphertext data stored on the blockchain, it can send a request to the blockchain system. The system sends a data access request including a target data identifier, where the target data identifier is the identification information used to uniquely identify the target ciphertext data, for example, it can be sorting information such as the number or serial number of the target ciphertext data, or it can be an indication of the target Relevant indication information of when the data owner of the ciphertext data will be stored on the chain.

Based on the foregoing introduction to the method of writing blockchain data, it can be seen that each consensus node in the blockchain system stores the target ciphertext data and the key share corresponding to the target key used to encrypt the target ciphertext data. And the key shares stored in each consensus node are different from each other, wherein the key shares stored in each consensus node are obtained by splitting the target key by the data owner through a secret sharing mechanism. In order to obtain the target ciphertext data and enough key shares, the data access direction initiates a data access request to the blockchain system, which can be directed to each consensus node to initiate a data access request. In the specific implementation process, each consensus node can pass the following Either way to obtain the data access request initiated by the data access party.

In Mode 1, the data access party generates a data access request carrying the target data identifier, and sends the data access request to each consensus node, so that each consensus node can directly receive the data access request from the data access party.

Mode 2, the data access party generates a data access request carrying the target data identifier, and sends the data access request to a consensus node in the consensus network, for example, the consensus node is called the target consensus node, and then the target consensus node Diffusion (such as broadcasting) to other consensus nodes in the consensus network, so that each consensus node can also obtain data access requests. The target consensus node that directly receives the data access party from the data access party can be any consensus node in the consensus network, and the target consensus node can be pre-specified or randomly selected by the data access party. Consensus networks with consensus algorithms that compete for accounting rights, such as POS, DPOS, etc., the data access party can randomly select one of the consensus nodes as the target consensus node. , the data access party can determine the accounting node (pre-agreed) as the target consensus node.

The data access request carries the target data identifier, and may also include the authority information to be verified of the data access party, or may also include the authority information to be verified of the data access party and the authority signature corresponding to the authority information to be verified. The permission information to be verified is the information used to verify whether the data access party has the permission to read the target ciphertext data, and the permission signature is the signature information used to verify the validity of the permission information to be verified.

Wherein, the data access party may be any authorized client, a trusted certification center, or an upper-layer program of a consensus protocol, which is not limited in this embodiment of the present application.

S302: Each consensus node determines the target ciphertext data and the key share corresponding to the target data identifier from the local storage.

Among them, please refer to the introduction of the contents stored in each consensus node in the corresponding embodiment section of FIG. 2. It can be seen that the same target ciphertext data is stored in different consensus nodes, but the key shares stored in each consensus node are different from each other. The key shares stored in all consensus nodes are obtained by splitting the target key used to encrypt the target ciphertext data by the data owner through the secret sharing mechanism. Therefore, after obtaining the data access request sent by the data owner, each consensus node can determine the target ciphertext data indicated by the target data identifier from the local storage according to the target data identifier, and determine the corresponding key share.

S303: Each consensus node determines that the access authority verification of the data access party has passed according to the authority information to be verified and the authority signature.

In the specific implementation process, each consensus node can independently verify the access authority of the data access party according to the authority information to be verified and the authority signature, so as to obtain the access authority verification result of the data access party. Specifically, each consensus node first verifies the validity of the authority information to be verified according to the authority signature, and then verifies the access authority of the data access party according to the authority information to be verified when the validity verification of the authority information to be verified passes. The permission information to be verified is matched and compared with the access access condition information stored in the blockchain system by the data owner in advance. The access access condition information, as mentioned above, may be a blacklist or whitelist specified by the data owner that allows or does not allow access to the target ciphertext data, such as user identifiers, client identifiers, device identifiers, etc. The list, or the access access condition information can also be a restriction condition that allows or does not allow access to the target ciphertext data. Each consensus node independently verifies the access rights of the data access party locally, and the access rights verification of each consensus node to the data access party can be carried out in parallel, which can speed up the rights of the entire blockchain system to the data access party to a certain extent. The verification process, and the independent verification of each consensus node can minimize the occupation of public resources on the chain.

In another embodiment, each consensus node can also jointly perform consensus processing on the permission information to be verified and the permission signature, and determine that the access permission of the data access party has passed the verification when a consensus is reached. Specifically, the consensus network can determine the consensus node with the accounting right by running the consensus algorithm, and then the consensus node with the accounting right uses the above consensus node to independently determine the data access party according to the permission information to be verified and the permission signature. The way to verify the access authority determines whether the data accessor has the access authority, and then spreads the determination result to other consensus nodes. All consensus nodes verify access rights through consensus, making full use of the consensus characteristics of the blockchain network, which can ensure the consistency of each consensus node's cognition of the final verification result. rounds of consensus processing, or, in order to improve the accuracy of the verification result, different consensus algorithms may be used to perform at least two rounds of consensus verification, which is not limited in this embodiment of the present application.

The access access condition information, as mentioned above, may be a blacklist or whitelist specified by the data owner that allows or does not allow access to the target ciphertext data, such as user identifiers, client identifiers, device identifiers, etc. The list, or the access access condition information can also be a restriction condition that allows or does not allow access to the target ciphertext data.

In the embodiment of the present application, the access authority of the data access party is verified by the authority signature and the authority information to be verified, so as to realize the access control of the visitor, so as to improve the security and effectiveness of data access as much as possible, and at the same time ensure the chain data security.

In practice, the data access party may be the data owner described in the corresponding embodiment in FIG. 2 , that is, the data access party may request access to the encrypted data stored in the blockchain system by itself, for example, in the data When the visitor forgets the key of the encrypted data stored on the chain before, this method can be used to obtain the target ciphertext data and the target key again, so that the plaintext data corresponding to the encrypted data can be obtained again, and the data can be retrieved again. manage. In this case, the access access condition information pre-stored by the data owner (also the data accessor at this time) may include relevant information that allows the data accessor to access the target ciphertext data, such as the user of the data accessor In this way, when matching and comparing, it can ensure that the data access party can pass the authorization authentication, and then obtain the target ciphertext data and multiple key shares from the blockchain.

During specific implementation, S303 is an optional step, so it is represented by a dashed box in FIG. 3 .

S304: Each consensus node sends the local target ciphertext data and key share to the data access party, correspondingly, the data access party receives the target ciphertext data and key share sent by each consensus node.

When the access authority verification of the data access party passes, it indicates that the data access party has the right to access the target ciphertext data on the chain, then each consensus node can send the target ciphertext data to the data access party, and at the same time, for the purpose of data access To complete the decryption of the target ciphertext data, it is also necessary to send the decryption key to the data access party. However, since the target key for encryption has been split into multiple key shares, each consensus node also has separate The key shares kept by them are sent to the data access party, so that the data access party can recover the target key according to the received multiple key shares, and then use the target key to decrypt the target ciphertext data.

Referring to Figure 3, S304 may include steps such as S304a and S304n. S304a is the consensus node 1 sending the target ciphertext data and key share 1 to the data access party, and S304n is the consensus node n sending the target ciphertext to the data access party. Data and key shares n. It should be noted that in Figure 3, only consensus node 1 and consensus node n are used for illustration. In the specific implementation process, other consensus nodes can also be included. Correspondingly, other consensus nodes can also send data to the data access party. Target ciphertext data and other key shares.

S305: The data access party determines the target key according to the predetermined number and different key shares, and decrypts the target ciphertext data according to the target key.

In practice, because some consensus nodes in the blockchain system may have been maliciously attacked or have hardware failures, the target ciphertext data and the corresponding key share cannot be returned to the data access party, or the data cannot be accessed. The party sends the correct target ciphertext data and the corresponding key share. For this reason, according to the principle of (t, n) secret sharing technology, the data access party at least only needs to receive a predetermined number (for example, called the second predetermined number, which is an integer greater than or equal to t and less than or equal to n) and different from each other The target key can be recovered, and then the target ciphertext data can be decrypted according to the target key, so as to achieve effective access to the data on the chain.

As mentioned above, in addition to the stored target ciphertext data and different key shares, each consensus node may also include a key share signature corresponding to the key share. Based on this, each consensus node sends data to the data access party. When sending the target ciphertext data and the key share, the key share signature corresponding to the key share can also be sent together, so that the data access party can first verify the validity of the key share itself according to the key share signature. When the validity verification of the key share is passed, it is regarded as a valid key share, and a second predetermined number of different valid key shares are further used to restore the target key. After obtaining the target key, the target ciphertext data can be decrypted by running the decryption algorithm corresponding to the symmetric encryption algorithm used by the data owner, so as to obtain the plaintext data corresponding to the target ciphertext data, so as to realize the effective data on the chain. access.

In the embodiment of the present application, while storing the target ciphertext data on the chain, the data owner splits the target key used to encrypt the target ciphertext data into multiple key shares, and splits the obtained ciphertext data into multiple key shares. The key shares are stored in each node in the blockchain system in a distributed manner. The secret sharing cryptographic technology is adopted. Even if individual key shares are maliciously stolen or tampered with, the accurate recovery of the target key will not be affected, and the target key will be improved. The security of the key in the blockchain system also improves the security of the target ciphertext data. Furthermore, when the data access party accesses the target ciphertext data on the chain, it passes through multiple distributed key pairs. On the basis of effective protection of the target ciphertext data, it can also ensure that the data access party can recover the correct target key through a certain number of key shares, so as to achieve effective and safe access to the target ciphertext data, and improve the performance of the target ciphertext data. Security of access to data stored on the blockchain.

For ease of understanding, the technical solutions in the embodiments of the present application are described below with reference to FIG. 4 and FIG. 5 .

Please refer to Figure 4, assuming that the target ciphertext data that the data owner needs to store on the chain is C, and the access access condition information determined by the data owner to be able to access the target ciphertext data is represented by ACL, which is used to encrypt the data using symmetric encryption. The target key of the target ciphertext data C is K. The data owner uses the secret sharing technology to split the target key K into four key shares of K1, K2, K3, and K4. The corresponding key share signatures are represented by Sig1, Sig2, Sig3, and Sig4, respectively. In the specific implementation process, the number of key shares that the data owner splits the target key K into can be the same as the number of consensus nodes included in the consensus network in the blockchain system, such as shown in Figure 4 All are 4.

Further, the data owner generates 4 data write requests according to different key shares, such as Write1, Write2, Write3, and Write4 in Figure 4. Among them, Write1, Write2, Write3, and Write4 all carry the target ciphertext data C and the access access condition information ACL, and the key shares carried in the four data write requests and the corresponding key share signatures are different. As shown in Figure 4, Write1, Write2, Write3, and Write4 respectively carry the key share K1 and the key share signature Sig1, the key share K2 and the key share signature Sig2, the key share K3 and the key share signature Sig3 , key share K4 and key share signature Sig4. After each consensus node receives the corresponding data write request, for example, consensus node 1 receives Write1, consensus node 2 receives Write2, consensus node 3 receives Write3, and consensus node 4 receives Write4 , the information carried in the received data write request is stored locally, as shown in the lower figure in FIG. 4 . Then, each consensus node sends the successful write indication information to the data owner. In Figure 4, Success1, Success2, Success3, and Success4 represent the successful write indication information sent by each consensus node. The successful writing indication information confirms that the target ciphertext data has been successfully written into the blockchain system, realizing the on-chain storage of encrypted data.

Referring to Figure 5 again, when the data access party wants to read the target ciphertext data from the blockchain system, it can send the corresponding read command to each consensus node. In Figure 5, it is Read1, Read2, Read3, Read4 Respectively represent the data access requests sent by the data access direction to each consensus node, and the information carried by each data access request is the same, assuming that ts represents the number of the target ciphertext data (corresponding to the aforementioned target data identifier), IDc represents Sigc is the identity signature of the data access party (corresponding to the aforementioned permission information to be verified), and Sigc is the identity signature (corresponding to the aforementioned permission signature) corresponding to the identity of the data access party. Figure 5 shows the way of sending data access requests to each consensus node. In another possible implementation, the data access party can also send data access requests to only one of the consensus nodes, and then the node Broadcast data access requests to the rest of the nodes.

Further, each consensus node can verify the validity of the identity identifier IDc of the data access party according to the Sigc in the data writing request, and verify the access authority according to the IDc. After the verification is passed, the corresponding ts can be determined from the local storage. Target ciphertext data, key share, and key share signature. Further, consensus node 1, consensus node 2, consensus node 3, and consensus node 4 respectively send the respective stored target ciphertext data, key share and corresponding key share signature to the data access party, as shown in Figure 5. As shown, consensus node 1 sends C, K1, Sig1 to the data access party, consensus node 2 sends C, K2, Sig2 to the data access party, consensus node 3 sends C, K3, Sig3 to the data access party , Consensus node 4 sends C, K4, Sig4 to the data access party. After receiving the data returned by each node, the data owner can recover the target key K through a sufficient number of different key shares according to the secret sharing mechanism, and then use the target key K to perform the target ciphertext data C. Decryption to complete effective access to on-chain data.

In the embodiment of the present application, the data owner, the data access party, and the blockchain system can use encrypted channels to exchange data, so as to ensure the safe transmission of data as much as possible. In addition, data owners, data access parties, and blockchain systems can use trusted hardware, TEE, Trusted Platform Module (TPM), cryptographic cards, cryptographic machines, etc., to ensure safe and reliable data processing and storage .

Based on the same inventive concept, the embodiments of the present application provide a blockchain system, for example, the blockchain system in FIG. 1 , the blockchain system includes at least two consensus nodes, the at least two consensus nodes Nodes form a consensus network, where:

Each consensus node is used to obtain the data write request sent by the data owner, wherein each data write request includes the same target ciphertext data and different key shares from each other, and the target ciphertext data is the target ciphertext data of the data owner. The key is obtained by encrypting the plaintext data, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism; consensus processing is performed on the target ciphertext data; After the consensus, the obtained target ciphertext data and key share are saved respectively.

Based on the blockchain system in the embodiment of the present application, the aforementioned processes described in FIG. 2 and FIG. 4 can be implemented. Based on the secret sharing technology, the target key corresponding to the target ciphertext data is split into multiple key shares and each The key shares are distributed and stored in each target blockchain node, and the security of the target key can be improved by storing the key shares in a distributed manner, thereby enhancing the protection of the target ciphertext data.

Based on the same inventive concept, the embodiments of the present application provide a blockchain system, for example, the blockchain system in FIG. 1 , the blockchain system includes at least two consensus nodes, the at least two consensus nodes Nodes form a consensus network, where:

Each consensus node is used to obtain the data access request including the target data identifier initiated by the data access party; and determine the target ciphertext data and key share corresponding to the target data identifier from the local storage, wherein the key stored locally by each consensus node The shares are different from each other, each key share is obtained by the data owner splitting the target key through the secret sharing mechanism, and the target ciphertext data is obtained by the data owner encrypting the plaintext data with the target key; The target ciphertext data and the key share are sent to the data access party, so that the data accessor can determine the target key according to a predetermined number and different key shares, and decrypt the target ciphertext data according to the target key.

Based on the blockchain system in this embodiment of the present application, the processes described in the aforementioned FIG. 3 and FIG. 5 can be implemented. When accessing data on the blockchain, even some nodes in the blockchain system may have been maliciously attacked. When it is not safe, for example, the target ciphertext data and key shares stored on the node have been tampered with. Since the secret sharing technology is used, a sufficient number of key shares are required to recover the target key, so it can ensure that the target key is recovered. The security of the target key, and the data access party can recover the correct target key when it receives a sufficient number of correct key shares, even if some key shares are no longer trusted, it can still be recovered. The validity of the target key, thereby improving the security control of data access.

Based on the same inventive concept, the embodiments of the present application provide a basic blockchain data writing device. The device can be a hardware structure, a software module, or a hardware structure plus a software module. The device can be configured in each block chain system. in the consensus node. Referring to FIG. 6, the block chain data writing device in the embodiment of the present application includes an obtaining module 601, a consensus module 602 and a storage module 603, wherein:

The obtaining module 601 is used to obtain the data write request sent by the data owner; wherein, each data write request includes the same target ciphertext data and different key shares, and the target ciphertext data is the target ciphertext data of the data owner to target. The key is obtained by encrypting the plaintext data, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism;

A consensus module 602, configured to perform consensus processing on the target ciphertext data;

The storage module 603 is configured to save the obtained target ciphertext data and the key share after it is determined that a consensus is reached on the target ciphertext data.

In a possible implementation manner, each data write request further includes a key share signature corresponding to the key share, and the storage module 603 is used for:

Save the obtained target ciphertext data, key share and corresponding key share signature.

In a possible implementation manner, each data write request further includes access access condition information, and the storage module 603 is used for:

After it is determined that both the target ciphertext data and the access access condition information have reached a consensus, save the obtained target ciphertext data, key share and access access condition information; or,

After it is determined that a consensus is reached on the target ciphertext data, the obtained target ciphertext data, key share and access condition information are saved.

In a possible implementation manner, the access access condition information includes condition information that allows the data owner to access the target ciphertext data.

In a possible implementation, the block chain data writing device in the embodiment of the present application further includes a sending module 604, configured to:

After the storage module 603 saves the obtained target ciphertext data and key shares, it sends successful write indication information to the data owner, so that the data owner can determine the target password when the received successful write indication information exceeds a predetermined number. The text data was successfully written.

During specific implementation, the sending module 604 is an optional module, that is, the sending module 604 is not a necessary module, so it is represented by a dashed box in FIG. 6 .

All relevant contents of the steps involved in the foregoing embodiments of the blockchain data writing method can be cited in the functional descriptions of the functional modules corresponding to the blockchain data writing device in the embodiments of the present application, and are not described herein. Repeat.

Based on the same inventive concept, the embodiments of the present application provide a blockchain data access device, which can be a hardware structure, a software module, or a hardware structure plus a software module, and the device can be configured on each consensus node in the blockchain system middle. Referring to FIG. 7 , the blockchain data access device in this embodiment of the present application includes an obtaining module 701, a determining module 702, and a sending module 703, wherein:

Obtaining module 701, configured to obtain a data access request initiated by a data access party, wherein the data access request includes a target data identifier;

The determination module 702 is used to determine the target ciphertext data and the key share corresponding to the target data identifier from the local storage, wherein the key shares stored locally by each consensus node are different from each other, and each key share is the data owner through secret sharing. The mechanism splits the target key, and the target ciphertext data is obtained by the data owner encrypting the plaintext data with the target key;

The sending module 703 is used to send the locally stored target ciphertext data and key shares to the data access party, so that the data access party can determine the target key according to a predetermined number and different key shares, and according to the target key pair Decrypt the target ciphertext data.

In a possible implementation, the determining module 702 is used to:

Determine the target ciphertext data, the key share and the corresponding key share signature corresponding to the target data identifier from the local storage;

The sending module 703 is used for:

Send the locally stored target ciphertext data, key share and corresponding key share signature to the data access party.

In a possible implementation manner, the data access request further includes the permission information to be verified and the permission signature of the data access party, and the blockchain data access device in the embodiment of the present application further includes a permission verification module 704 for:

Before sending the locally stored target ciphertext data and key share to the data access party, the sending module 703 determines that the access authority verification of the data access party has passed according to the authority information to be verified and the authority signature; wherein, the authority information to be verified is verified according to the authority signature. Verification is performed, and when the verification of the authority information to be verified is passed, it is determined that the access authority verification of the data access party is passed according to the authority information to be verified.

In a possible implementation, the authority verification module 704 is used to:

Matching the permission information to be verified with the access access condition information, wherein the access access condition information is determined by the data owner;

If the matching result is the set matching result, it is determined that the access authority verification of the data access party has passed.

In a possible implementation manner, the access access condition information includes condition information that allows the data owner to access the target ciphertext data.

In a possible implementation, the authority verification module 704 is used to:

According to the permission information to be verified and the permission signature, it is determined that the access permission verification of the data access party has passed; or, consensus processing is performed on the permission information to be verified and the permission signature, and after a consensus is reached, it is determined that the access permission verification of the data access party has passed.

During specific implementation, the authority verification module 704 is an optional module, that is, the authority verification module 704 is not a necessary module, so it is represented by a dotted box in FIG. 7 .

All relevant contents of the steps involved in the foregoing embodiments of the blockchain data access method can be cited in the functional descriptions of the functional modules corresponding to the blockchain data access device in the embodiments of the present application, which will not be repeated here. .

The division of modules in the embodiments of the present application is schematic, and is only a logical function division. In actual implementation, there may be other division methods. In addition, the functional modules in the various embodiments of the present application may be integrated into one processing unit. In the device, it can also exist physically alone, or two or more modules can be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware, and can also be implemented in the form of software function modules.

Based on the same inventive concept, an embodiment of the present application further provides a computer storage medium, which may be a computer-readable storage medium, where computer instructions or computer-readable programs are stored in the computer storage medium. When the computer-readable program runs on the computer, the computer executes the steps of the aforementioned method for writing blockchain data.

Based on the same inventive concept, an embodiment of the present application further provides a computer storage medium, which may be a computer-readable storage medium, where computer instructions or computer-readable programs are stored in the computer storage medium. When the computer-readable program runs on the computer, the computer executes the steps of the aforementioned blockchain data access method.

In some possible implementations, various aspects of the blockchain data writing method provided by the embodiments of the present application may also be implemented in the form of a program product, which includes program code, and when the program product runs on a computer , the program code is used to cause the computer to execute the steps in the block chain data writing method described above according to various exemplary embodiments of the present application.

In some possible implementations, various aspects of the blockchain data access method provided by the embodiments of the present application may also be implemented in the form of a program product, which includes program code, and when the program product runs on a computer, The program code is used to cause the computer to execute the steps in the aforementioned blockchain data access method according to various exemplary embodiments of the present application.

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

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

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions An apparatus implements the functions specified in a flow or flows of the flowcharts and/or a block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in one or more of the flowcharts and/or one or more blocks of the block diagrams.

While the preferred embodiments of the present application have been described, additional changes and modifications to these embodiments may occur to those skilled in the art once the basic inventive concepts are known. Therefore, the appended claims are intended to be construed to include the preferred embodiment and all changes and modifications that fall within the scope of this application.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (26)

1. A method for writing block chain data, the method comprising:

each consensus node respectively obtains a data writing request sent by a data owner; each data write-in request comprises the same target ciphertext data, mutually different key shares and access admission condition information, the target ciphertext data is obtained by encrypting plaintext data by a target key by a data owner, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism;

carrying out consensus processing on the target ciphertext data by each consensus node;

after the goal ciphertext data are determined to be agreed, the consensus nodes respectively store the obtained goal ciphertext data, the key share and the access admission condition information; the target ciphertext data and the key share are stored in the trusted execution environment of each consensus node, and the access admission condition information is stored in the conventional memory area of each corresponding consensus node.

2. The method according to claim 1, wherein each data write request further includes a key share signature corresponding to a key share, and each consensus node respectively stores the obtained target ciphertext data and the obtained key share, including:

and the common identification nodes respectively store the obtained target ciphertext data, the key share and the corresponding key share signature.

3. The method according to claim 1, wherein after determining that consensus is achieved on the target ciphertext data, the respective consensus nodes respectively save the obtained target ciphertext data, the key share, and the access admission condition information, and the method includes:

after determining that the target ciphertext data and the access admission condition information are both agreed, the consensus nodes respectively store the obtained target ciphertext data, the key share and the access admission condition information; or,

after the target ciphertext data are determined to be agreed, the all the agreed nodes store the obtained target ciphertext data, the key share and the access admission condition information.

4. The method of claim 3, wherein the access admission condition information comprises condition information for allowing the data owner to access the target ciphertext data.

5. The method according to claim 1, wherein after the respective consensus nodes respectively save the obtained target ciphertext data and the key shares, the method further comprises:

and the common identification nodes respectively send successful writing indication information to the data owner, so that the data owner determines that the target ciphertext data is successfully written when the received successful writing indication information exceeds a preset number.

6. The method according to any of claims 1-5, wherein the respective consensus nodes save the obtained key shares in trusted execution environments of the respective consensus nodes.

7. A method of blockchain data access, the method comprising:

each consensus node obtains a data access request initiated by a data access party, wherein the data access request comprises a target data identifier;

each consensus node determines target ciphertext data and a key share corresponding to the target data identifier from a local storage, wherein the target ciphertext data, access admission condition information and the key shares different from each other are locally stored in each consensus node, each key share is obtained by splitting a target key by a data owner through a secret sharing mechanism, the target ciphertext data is obtained by encrypting plaintext data by the data owner through the target key, the target ciphertext data and the key shares are stored in a trusted execution environment of each consensus node, and the access admission condition information is stored in a conventional memory area of each corresponding consensus node;

and the common identification nodes respectively send the locally stored target ciphertext data and the key shares to the data access party, so that the data access party determines the target key according to the preset number of different key shares and decrypts the target ciphertext data according to the target key.

8. The method of claim 7, wherein determining, by each consensus node, a target ciphertext data and a key share corresponding to the target data identity from a local store comprises:

each consensus node determines target ciphertext data, a key share and a corresponding key share signature corresponding to the target data identifier from a local storage;

the method for sending the locally stored target ciphertext data and the locally stored key share to the data access party by the common identification nodes comprises the following steps:

and the common identification nodes respectively send the locally stored target ciphertext data, the key share and the corresponding key share signature to the data access party.

9. The method according to claim 7, wherein the data access request further includes authority information to be verified and an authority signature of the data access party, and before the respective consensus nodes respectively send target ciphertext data and key shares stored locally to the data access party, the method further includes:

the common identification nodes determine that the access authority of the data access party passes the verification according to the information of the authority to be verified and the authority signature; and when the authority information to be verified passes the verification, determining that the access authority of the data access party passes the verification according to the authority information to be verified.

10. The method of claim 9, wherein determining that the access right of the data accessing party is verified according to the information of the right to be verified comprises:

matching the authority information to be verified with access admission condition information, wherein the access admission condition information is determined by the data owner;

and if the matching result is the set matching result, determining that the access authority of the data access party passes the verification.

11. The method of claim 10, wherein the access admission condition information comprises condition information for allowing the data owner to access the target ciphertext data.

12. The method according to claim 9, wherein the determining, by each consensus node, that the access right of the data accessing party passes the verification according to the information of the right to be verified and the right signature comprises:

the common identification nodes respectively determine that the access authority of the data access party passes the verification according to the information of the authority to be verified and the authority signature; or,

and the mutual identification nodes carry out mutual identification processing on the information of the authority to be verified and the authority signature, and determine that the access authority of the data access party passes the verification after the mutual identification is achieved.

13. An apparatus for writing block chain data, configured in each of the common nodes, the apparatus comprising:

the acquisition module is used for acquiring a data write-in request sent by a data owner; each data write-in request comprises the same target ciphertext data, mutually different key shares and access admission condition information, the target ciphertext data is obtained by encrypting plaintext data by a target key by a data owner, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism;

the consensus module is used for performing consensus processing on the target ciphertext data;

the storage module is used for storing the obtained target ciphertext data, the key share and the access admission condition information after the target ciphertext data is determined to be agreed; the target ciphertext data and the key share are stored in a trusted execution environment, and the access admission condition information is stored in a conventional memory area.

14. The apparatus of claim 13, wherein each data write request further includes a key share signature corresponding to a key share, and wherein the storage module is configured to:

and storing the obtained target ciphertext data, the key share and the corresponding key share signature.

15. The apparatus of claim 13, wherein the storage module is configured to:

after the target ciphertext data and the access admission condition information are determined to be commonly identified, storing the obtained target ciphertext data, the key share and the access admission condition information; or,

and after the target ciphertext data is determined to be agreed, storing the obtained target ciphertext data, the key share and the access admission condition information.

16. The apparatus according to claim 15, wherein the access admission condition information includes condition information for allowing the data owner to access the target ciphertext data.

17. The apparatus of claim 13, further comprising a sending module configured to:

after the storage module stores the obtained target ciphertext data and the key share, sending successful writing indication information to the data owner, so that the data owner determines that the target ciphertext data is successfully written when the received successful writing indication information exceeds a preset number.

18. An apparatus for blockchain data access, the apparatus being configured in each of a plurality of common nodes, the apparatus comprising:

the system comprises an obtaining module, a processing module and a processing module, wherein the obtaining module is used for obtaining a data access request initiated by a data access party, and the data access request comprises a target data identifier;

the determining module is used for determining target ciphertext data and key shares corresponding to the target data identifier from a local storage, wherein each consensus node locally stores the target ciphertext data, access admission condition information and mutually different key shares, each key share is obtained by splitting a target key by a data owner through a secret sharing mechanism, the target ciphertext data is obtained by encrypting plaintext data by the data owner through the target key, the target ciphertext data and the key shares are stored in a trusted execution environment, and the access admission condition information is stored in a conventional memory area;

and the sending module is used for sending the locally stored target ciphertext data and the key share to the data access party so as to enable the data access party to determine the target key according to a predetermined number of different key shares and decrypt the target ciphertext data according to the target key.

19. The apparatus of claim 18, wherein the determining module is configured to:

determining target ciphertext data corresponding to the target data identifier, a key share and a corresponding key share signature from a local storage;

the sending module is used for:

and sending the target ciphertext data, the key share and the corresponding key share signature which are locally stored to the data access party.

20. The apparatus of claim 18, wherein the data access request further includes information of a right to be verified and a right signature of the data accessing party, and the apparatus further includes a right verifying module configured to:

before the sending module sends the locally stored target ciphertext data and the key share to the data access party, determining that the access right of the data access party passes the verification according to the information of the right to be verified and the right signature; and when the authority information to be verified passes the verification, determining that the access authority of the data access party passes the verification according to the authority information to be verified.

21. The apparatus of claim 20, wherein the rights verification module is configured to:

matching the authority information to be verified with access admission condition information, wherein the access admission condition information is determined by the data owner;

and if the matching result is the set matching result, determining that the access authority of the data access party passes the verification.

22. The apparatus according to claim 21, wherein the access admission condition information includes condition information for allowing the data owner to access the target ciphertext data.

23. The apparatus of claim 20, wherein the rights verification module is configured to:

determining that the access authority of the data access party passes the verification according to the information of the authority to be verified and the authority signature; or,

and performing consensus processing on the information of the authority to be verified and the authority signature, and determining that the access authority of the data access party passes verification after consensus is achieved.

24. A blockchain system comprising at least two consensus nodes, wherein:

each consensus node is used for respectively obtaining data write-in requests sent by a data owner, wherein each data write-in request comprises same target ciphertext data, different key shares and access admission condition information, the target ciphertext data is obtained by encrypting plaintext data by the data owner through a target key, and each key share is obtained by splitting the target key by the data owner through a secret sharing mechanism; performing consensus processing on the target ciphertext data; and respectively storing the obtained target ciphertext data, the key share and the access admission condition information after determining that the target ciphertext data are agreed, wherein the target ciphertext data and the key share are stored in the trusted execution environment of each agreed node, and the access admission condition information is stored in the conventional memory area of each corresponding agreed node.

25. A blockchain system comprising at least two consensus nodes, wherein:

each consensus node is used for obtaining a data access request which is initiated by a data access party and comprises a target data identifier; determining target ciphertext data and key shares corresponding to the target data identifier from a local storage, wherein each consensus node locally stores the target ciphertext data, access admission condition information and different key shares, each key share is obtained by a data owner by splitting a target key through a secret sharing mechanism, the target ciphertext data is obtained by encrypting plaintext data by the data owner through the target key, the target ciphertext data and the key shares are stored in a trusted execution environment of each consensus node, and the access admission condition information is stored in a conventional memory area of each corresponding consensus node; and respectively sending the locally stored target ciphertext data and the key share to the data access party, so that the data access party determines the target key according to the preset number of different key shares and decrypts the target ciphertext data according to the target key.

26. A computer storage medium, characterized in that a computer readable program is stored in the computer storage medium for performing the method according to any one of claims 1-6 or for performing the method according to any one of claims 7-12.

Images