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

Block chain data writing and accessing method and device Download PDF

Info

Publication number
CN113098697B
CN113098697B CN202110634791.3A CN202110634791A CN113098697B CN 113098697 B CN113098697 B CN 113098697B CN 202110634791 A CN202110634791 A CN 202110634791A CN 113098697 B CN113098697 B CN 113098697B
Authority
CN
China
Prior art keywords
data
target
key
access
target ciphertext
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110634791.3A
Other languages
Chinese (zh)
Other versions
CN113098697A (en
Inventor
王小云
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tsinghua University
Original Assignee
Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tsinghua University filed Critical Tsinghua University
Priority to CN202110634791.3A priority Critical patent/CN113098697B/en
Publication of CN113098697A publication Critical patent/CN113098697A/en
Application granted granted Critical
Publication of CN113098697B publication Critical patent/CN113098697B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Abstract

The embodiment of the application provides a method and a device for writing and accessing block chain data, which are used for improving the safety of data storage and data access on a block chain. The method comprises the following steps: 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 and different key shares, the target ciphertext data is obtained by encrypting plaintext data by a target key through a data owner, and each key share is obtained by splitting the target key through a secret sharing mechanism through the data owner; 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 and the obtained key share.

Description

Block chain data writing and accessing method and device
Technical Field
The present application relates to the field of blockchain technologies, and in particular, to a method and an apparatus for writing and accessing blockchain data.
Background
The blockchain is a composite technology comprehensively realized by using technologies such as a cryptography method, a computer network and distributed storage, provides a distributed data sharing mode, and has the characteristics of decentralization (point-to-point network communication), no tampering, trace retention in the whole process, collective maintenance, openness and transparency and the like. Based on these characteristics of the blockchain, a user may store data on the blockchain to enable sharing of the data through the blockchain. Since user data generally relates to the privacy of the user, it is necessary to effectively protect the data stored on the blockchain to ensure the security of the data.
In order to ensure the security of data on the blockchain, security control needs to be performed in the processes of data storage, data access and the like, so how to improve the security of data storage and access on the blockchain is a problem to be considered.
Disclosure of Invention
The embodiment of the application provides a block chain data writing and accessing method and device, which are mainly used for improving the safety of data storage and data access on a block chain.
According to a first aspect of embodiments of the present application, there is provided a method for writing block chain data, the method including:
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 and different key shares, the target ciphertext data is obtained by encrypting plaintext data by a target key through a data owner, and each key share is obtained by splitting the target key through a secret sharing mechanism through the data owner;
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 and the obtained key share.
In a possible implementation manner, 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.
In a possible implementation manner, each data write request further includes access admission condition information; after determining that consensus is achieved on the target ciphertext data, each consensus node respectively stores the obtained target ciphertext data and the obtained key share, including:
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; alternatively, the first and second electrodes may be,
after the goal ciphertext data are determined to be agreed, the all the agreed nodes store the obtained goal ciphertext data, the key share and the admission condition information.
In a possible implementation manner, the access admission 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 respectively save the obtained target ciphertext data and the key share, the method further includes:
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.
In one possible implementation, the respective consensus node saves the obtained key shares in a trusted execution environment of the respective consensus node.
According to a second aspect of embodiments of the present application, there is provided a method for accessing blockchain data, the method including:
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 key shares locally stored by the consensus nodes are different from each other, each key share is obtained by splitting a target key through a secret sharing mechanism by a data owner, and the target ciphertext data is obtained by encrypting plaintext data by the data owner through the target key;
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.
In a possible implementation manner, the determining, by each consensus node, target ciphertext data and a key share corresponding to the target data identifier from a local storage includes:
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.
In a possible implementation manner, the data access request further includes to-be-verified authority information and an authority signature of the data access party, and before the respective consensus nodes respectively send locally stored target ciphertext data and a key share 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.
In a possible implementation manner, determining that the access right of the data accessing party passes the verification according to the information of the right to be verified includes:
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.
In a possible implementation manner, the access admission condition information includes condition information that allows the data owner to access the target ciphertext data.
In a possible implementation manner, the determining, by each consensus node, 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 includes:
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; alternatively, the first and second electrodes may be,
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.
According to a third aspect of the embodiments of the present application, there is provided an apparatus for writing blockchain data, the apparatus being configured in each of the common nodes, the apparatus including:
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 and different key shares, the target ciphertext data is obtained by encrypting plaintext data by a target key through a data owner, and each key share is obtained by splitting the target key through a secret sharing mechanism through the data owner;
the consensus module is used for performing consensus processing on the target ciphertext data;
and the storage module is used for storing the obtained target ciphertext data and the key share after the target ciphertext data is determined to be agreed.
In a possible implementation manner, each data write request further includes a key share signature corresponding to a key share, and the storage module is configured to:
and storing the obtained target ciphertext data, the key share and the corresponding key share signature.
In a possible implementation manner, each data write request further includes access admission condition information, and 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; alternatively, the first and second electrodes may be,
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.
In a possible implementation manner, the access admission 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, 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.
According to a fourth aspect of embodiments of the present application, there is provided a blockchain data access apparatus, where the apparatus is configured in each consensus node, and the apparatus includes:
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 configured to determine target ciphertext data and a key share corresponding to the target data identifier from a local storage, where the key shares locally stored by the respective consensus nodes are different from each other, each key share is obtained by splitting a target key by a data owner through a secret sharing mechanism, and the target ciphertext data is obtained by encrypting plaintext data by the data owner with the target key;
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.
In one possible implementation, 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.
In a possible implementation manner, the data access request further includes to-be-verified authority information and an authority signature of the data accessing party, and the apparatus further includes an authority verification 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.
In one possible implementation, the permission 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.
In a possible implementation manner, the access admission condition information includes condition information that allows the data owner to access the target ciphertext data.
In one possible implementation, the permission 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; alternatively, the first and second electrodes may be,
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.
According to a fifth aspect of embodiments of the present application, there is provided a blockchain system, including at least two consensus nodes, wherein:
each consensus node is used for respectively obtaining data writing requests sent by a data owner, wherein each data writing request comprises same target ciphertext data and different key shares, 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 saving the obtained target ciphertext data and the key share after determining that the target ciphertext data is agreed.
According to a sixth aspect of the embodiments of the present application, there is provided a blockchain system, including 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 the key shares locally stored by the common identification nodes are different from each other, each key share is obtained by splitting a target key through a secret sharing mechanism by a data owner, and the target ciphertext data is obtained by encrypting plaintext data by the data owner through the target key; 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.
According to a seventh aspect of embodiments of the present application, there is provided a computer storage medium having a computer readable program stored therein, the computer readable program being for executing the method according to the first aspect described above.
According to an eighth aspect of embodiments of the present application, there is provided a computer storage medium having a computer readable program stored therein for executing the method according to the second aspect described above.
According to a ninth aspect of embodiments herein, there is provided a computer program product encoding instructions for performing a process, the process comprising the method described in the first aspect above.
According to a tenth aspect of embodiments herein there is provided a computer program product encoding instructions for performing a process, the process comprising the method described in the second aspect above.
According to the block chain data writing and accessing method and device, when the target ciphertext data are chained and stored by a data owner, the target key used for encrypting the target ciphertext data is split into a plurality of key shares, the split key shares are stored in all the common nodes in the block chain system in a distributed mode, and the secret sharing cryptographic technology is adopted to store all the key shares separately, so that even if individual key shares are stolen or tampered maliciously, accurate recovery of the target key is not influenced, the safety of the target key in the block chain system is improved, and the safety of the target ciphertext data is improved. 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 a plurality of scattered key shares, the data access party can also be ensured to recover a correct target key through a certain number of key shares, so that the target ciphertext data can be effectively and safely accessed, and the security of accessing the data stored on the block chain is improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic diagram of an application scenario applicable to the embodiment of the present application;
FIG. 2 is a flowchart illustrating a method for writing blockchain data according to an embodiment of the present invention;
fig. 3 is a flowchart illustrating a method for accessing blockchain data according to an embodiment of the present disclosure;
FIG. 4 is a diagram illustrating a process of requesting data to be written to a blockchain system from all directions of data according to an embodiment of the present invention;
FIG. 5 is a diagram illustrating a process of requesting data to be read by the blockchain system according to an embodiment of the present invention;
FIG. 6 is a block diagram of a device for writing blockchain data according to an embodiment of the present invention;
fig. 7 is a block diagram of a block chain data access device in the embodiment of the present application.
Detailed Description
In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following further detailed description of the exemplary embodiments of the present application with reference to the accompanying drawings makes it clear that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
The technical scheme of the embodiment of the application can be applied to a block chain system, and through the technical scheme, certain degree of safety control can be performed when data are written into the block chain system and the data on the block chain are accessed, so that the safety of the data on the block chain can be improved.
In order to better understand the technical solution provided by the embodiment of the present application, some brief descriptions are provided below for application scenarios to which the technical solution provided by the embodiment of the present application is applicable, and it should be noted that the application scenarios described below are only used for illustrating the embodiment of the present application and are not limited. In specific implementation, the technical scheme provided by the embodiment of the application can be flexibly applied according to actual needs.
Referring to fig. 1, fig. 1 is an application scenario to which the technical solution of the embodiment of the present application is applied, where the application scenario includes a data owner, a blockchain system, and a data access party, where the data owner and the data access party may be a client, a terminal device, or a trusted authentication center or a consensus protocol upper layer program. The data access party can request the blockchain system to read the desired data, for example, the data access party wants to read the data stored in the uplink of the data access party or wants to read the data stored in the uplink of the data access party, so as to achieve the purpose of sharing the data.
The blockchain system in fig. 1 may be understood as a blockchain network, where the blockchain network is a peer-to-peer communication network, and the blockchain system includes a plurality of block chain nodes that can communicate with each other, where the block chain nodes may be physical nodes such as servers, or may be logical nodes, and the embodiments of the present application are not limited thereto. A plurality of blockchain nodes in the blockchain system may form a consensus network, and each blockchain node forming the consensus network may also be referred to as a consensus node, and the consensus network may perform consensus processing on information by using a specific consensus algorithm to achieve consensus. The block chain system has the characteristics of decentralization, no tampering, whole-course trace retention, collective maintenance, openness and transparency and the like, and along with the development of the block chain technology, the block chain system is more and more widely applied to various fields. In practical applications, data related to some service scenarios need to be protected to ensure the benefits of users.
Each node in the block chain system in fig. 1 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, a middleware service, a domain name service, a security service, a Content Delivery Network (CDN), a big data and an artificial intelligence platform, which is not limited in the embodiment of the present application.
The technical solution of the embodiment of the present application is described in terms of data writing (i.e. data uplink storage) and data access, respectively, where the data access scheme is implemented based on a data writing scheme, and specifically, when a data owner writes data into a blockchain system, a key used for encrypting the data is split into a plurality of key shares by using a secret sharing technique, and then the encrypted data and the key shares are respectively uplink-stored in each blockchain node in the blockchain system, in this way, a key for encrypting the data is distributively stored in the blockchain system, according to the principle of the secret sharing technique, even if some blockchain nodes in the blockchain system fail (for example, have been controlled by an adversary or have a hardware failure, etc.), if there are not enough key shares, a target key cannot be recovered, thereby implementing effective protection of the target key, and the data access party can also be ensured to take a certain number of key shares (the number is related to the secret sharing technology) to recover the correct encryption key so as to decrypt the encrypted data, thereby obtaining the correct plaintext data and completing the safe access to the data on the chain.
For ease of understanding, the process of data uplink is described with reference to fig. 2, wherein the process of data uplink is a process in which a data owner writes data to be stored into the block chain system for storage. Fig. 2 is a flowchart illustrating a block chain data writing method according to an embodiment of the present application, where the flowchart illustrated in fig. 2 is described as follows.
S201: and encrypting the plaintext data by the data owner by adopting the target key to obtain corresponding target ciphertext data.
For example, a data owner needs to store a certain piece of transaction data in uplink, in order to ensure the security of the transaction data, the transaction data may be encrypted before uplink, for example, a general symmetric encryption algorithm may be used to encrypt the transaction data, the transaction data may be understood as plaintext data in the embodiment of the present application, a key for encryption may be understood as a target key in the embodiment of the present application, and encrypted data obtained by encryption may be understood as target ciphertext data in the embodiment of the present application.
The data owner may be any authorized client, a trusted authentication center, or a consensus protocol upper layer program, which is not limited in the embodiments of the present application.
S202: the data owner adopts a secret sharing mechanism to split the target key into at least two key shares.
That is, the target key may be split into a plurality of key shares, that is, the target key is split according to a specific algorithm, and each split key share is different.
In the embodiment of the present application, a secret sharing technique is used to split the target key, and the secret sharing technique is briefly described below.
The idea of the secret sharing technology is to split the secret in a proper way, each share obtained after splitting can be managed by different participants, a single participant cannot recover the secret information, and only a plurality of participants cooperate together can the secret information be recovered. More importantly, the secrets can still be fully recovered when a problem occurs with any participant within their respective range. Secret sharing is a cryptographic technology for storing secrets in a split mode, aims to prevent the secrets from being too concentrated to achieve the purposes of dispersing risks and tolerating intrusion, and is an important means in information security and data confidentiality. Two parameters in the secret sharing, for example, t, n represents the two parameters, which may be referred to as (t, n) secret sharing, where n represents the number of shares into which the secret is split, t represents that at least t shares are obtained before the secret can be recovered, and any shares less than t shares are any relevant information that the secret cannot be obtained. The specific understanding is as follows:
assuming that the secret is split into secret shares of n shares, the secret can be recovered by any t (2 ≦ t ≦ n) or more secret shares, while any secret share or shares less than t are unable to obtain any useful information about the secret.
In practice, security and reliability may be traded off according to the choice of t and n. Generally, the larger the value of t, the higher the safety and the lower reliability can be provided; the lower the value of t, the lower the security and the higher reliability can be provided.
According to the secret sharing technique described 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 split n key shares are, for example: k1, K2, K3, … …, Kn.
In the embodiment of the present application, the number of the target key split into the key shares by the data owner using the secret sharing mechanism may be determined according to the number of the consensus nodes included in the consensus network in the blockchain system, for example, the number of the key shares may be made the same as the number of the consensus nodes, i.e., how many consensus nodes there are, the target key is split into how many key shares, and, for example, the number of key shares may be made slightly larger than the number of consensus nodes, here, "slightly more" means a set value that is more than the number of common nodes, the set value is a small integer such as 1 or 2 or 3, the set value here is also related to the value of t in the secret sharing technique, which ensures that each consensus node obtains a key share and that the obtained key shares are different from each other, but it is ensured that a sufficient number of mutually different key shares are obtained from the consensus node to accurately recover the target key.
For example, the consensus network in the blockchain system includes 20 consensus nodes, and then the data owner can split the target key into 20 key shares, so that the 20 key shares can be respectively and correspondingly sent to the respective consensus nodes, and then the 20 key shares can be obtained from the respective consensus nodes as much as possible, and even if some of the respective consensus nodes fail, enough key shares can be obtained to recover the target key, so as to achieve accurate decryption of the target ciphertext data.
For another example, if the consensus network in the blockchain system includes 20 consensus nodes, the data owner may split the target key into 21 key shares, so that 20 keys in the obtained key shares may be respectively sent to the respective consensus nodes, and then the 20 key shares may be obtained from the respective consensus nodes, even if all keys (all keys are 21) are not obtained, and even if some of the consensus nodes fail to correctly obtain the key shares kept by the consensus nodes, enough key shares may be obtained to recover the target key, so as to achieve accurate decryption of the target ciphertext data.
S203: and the data owner carries out signature processing on each key share to obtain a key share signature corresponding to each key share.
The method of signing the key share may adopt some general signature methods, for example, a hash algorithm may be first used to calculate a digital digest for the key share, and then the digital digest is encrypted by using a private key in the asymmetric key, where the encrypted digital digest is a signature of the key share, and is called a key share signature. For example, key share signatures corresponding to key shares K1, K2, K3, … …, Kn are denoted by Sig1, Sig2, Sig3, … …, Sign, respectively.
S204: and the data owner determines access admission condition information corresponding to the target ciphertext data.
In a specific implementation process, the Access admission condition information may be an Access Control List (ACL), for example, a blacklist or a whitelist such as a user identifier, a client identifier, and a device identifier that are specified by a data owner and allow or disallow Access to the target ciphertext data, or the Access admission condition information may also be a specific Access Control condition, which may be understood as a restriction condition set by the data owner and allow or disallow Access to the target ciphertext data, for example: and allowing the women aged 35 to 50 to access the target ciphertext data, wherein the women aged 35 to 50 can be understood as the access control condition, or not allowing the crowd aged less than 20 or aged more than 65 to access the target ciphertext data, and the crowd aged less than 20 or aged more than 65 can be understood as the access control condition.
In practice, a user may lose encrypted data obtained by encrypting the user or forget an encryption key of the user's own encrypted data, for example, the target ciphertext data, after a data owner encrypts target plaintext data locally by using the target key to obtain the target ciphertext data, the target ciphertext data may be lost (for example, mistakenly deleted or stolen) or the target key is forgotten, for example, after the target ciphertext data is lost, the user wants to obtain corresponding target plaintext data again, at this time, the user cannot know the target key and perform a decryption operation, for example, when the user forgets the target key and wants to obtain the target plaintext data or wants to reset the key for the target ciphertext data, the user cannot perform the operations due to the absence of the target key for encryption, which is obviously inconvenient for the user to manage the encrypted data. In view of this, in the embodiment of the present application, the data owner may allow the data owner to access itself when setting access admission condition information for the target ciphertext data, and for this purpose, condition information that allows the data owner to access the target ciphertext data may be set in the access admission condition information, for example, identity information such as a user identifier of the data owner may be added to the access admission condition information, so that, after the target ciphertext data is linked and stored in the block chain system, the data owner may serve as an accessor to request the block chain system to read the target ciphertext data to obtain the target ciphertext data and a plurality of corresponding key shares, that is, the target ciphertext data and the plurality of key shares may be obtained from the block chain system again, and then the target ciphertext data is decrypted by using the target key recovered from the plurality of key shares to obtain the corresponding target plaintext data, or the target ciphertext data can be subjected to the key resetting processing according to the recovered target key, so that the data owner can conveniently perform linked access, secondary management and the like on the target ciphertext data.
S205: and generating a data write request by the data owner according to the number of the common nodes.
Specifically, the same number of data write requests can be generated by how many common nodes, that is, the number of data write requests is the same as the number of common nodes. As introduced above, the number of key shares may be equal to or greater than the total number of common nodes, and in consideration of the actual situation, when the number of key shares is the same as the total number of common nodes, for example, 20 key shares, all key shares may be used to generate data write requests corresponding to the same number, and 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; 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 partial key shares (i.e., random 20 key shares thereof) may be used to generate 20 data write requests correspondingly, such that each of the generated 20 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, the data owner may generate data write requests with the same total number of common nodes, and the key shares carried in the respective data write requests are different from each other.
Each data write request may include target ciphertext data in addition to the key shares mentioned above, and may further include access admission condition information and/or a key share signature, where the key shares included in each data write request and the corresponding key share signatures are different. That is, the same portion included in each data write request is the target ciphertext data and the access admission condition information, and the different portions included are the key shares and the corresponding key share signatures.
It should be noted that S203 and S204 may be optional steps, and are shown by dashed lines in fig. 2. That is, S203 and/or S204 may or may not be executed in the specific implementation process. 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 does not include the access admission condition information, and the implementation of S203 and S204 can be flexibly selected during implementation, so that the information included in the data write request is flexibly configured to implement different verification functions, which is not limited in the embodiment of the present application.
S206: and the data owner sends each data writing request to each consensus node, and correspondingly, each consensus node respectively obtains the data writing request sent by the data owner.
As mentioned above, the number of data write requests generated by the data owner is the same as the total number of the consensus nodes, so that the data owner can send each data write request to a different consensus node, and thus each consensus node obtains a different key share, so that the key shares corresponding to the target key can be distributively stored in different nodes in the blockchain system to achieve distributed storage of the key shares, and thus, even if an individual consensus node is already under control of an adversary (e.g., attacked by a malicious person), the consensus node cannot recover the target key because a sufficient number (e.g., the aforementioned t number) of key shares cannot be obtained, so that the security of the target key can be greatly ensured.
Continuing with the previous example, since there are n key shares K1, K2, K3, … …, Kn, as shown in fig. 2, for example, the corresponding data write requests generated are data write request 1, data write request 2, data write request 3, … …, data write request n, and the n data write requests are sent to consensus node 1, consensus node 2, consensus node 3, … …, consensus node n, respectively. It should be noted that, for simplicity of illustration, only the consensus node 1 and the consensus node n are shown in fig. 2, and the other consensus nodes are represented by "… …" instead.
Continuing with fig. 2, the step of sending, by the data owner, each data write request to each consensus node may specifically include steps S206a, S206n, and the like. S206a is that the data owner sends a data write request 1 carrying target ciphertext data and a key share 1 to the consensus node 1, and S206n is that the data owner sends a data write request n carrying target ciphertext data and a key share n to the consensus node n. It should be noted that, for simplicity of illustration, only the consensus node 1 and the consensus node n are illustrated in fig. 2, so only the consensus node 1 and the consensus node n are shown in fig. 2, and other consensus nodes are represented by "… …" instead, in a specific implementation process, other more consensus nodes may be further included, and correspondingly, the data owner may further send different data write requests carrying other key shares and target ciphertext data to other consensus nodes.
S207: and each consensus node performs consensus processing on the target ciphertext data and achieves consensus.
After each consensus node in the block chain system obtains a data write-in request sent by a data owner, each consensus node obtains the same target ciphertext data, and based on the de-centralization characteristic of the block chain system, consensus processing can be performed on the target ciphertext data to ensure that the target ciphertext data finally stored by each consensus node is accurate, unique and effective, namely that the target ciphertext data finally stored by each target block chain node is the same correct data.
In a specific implementation process, the consensus network can perform consensus processing on target ciphertext data by adopting a predetermined consensus algorithm to achieve consensus on the target ciphertext data, and it should be noted that the consensus network performs consensus processing on the target ciphertext data, that is, each consensus node performs consensus processing on the target ciphertext data in a combined manner. The predetermined consensus algorithm may adopt a currently common consensus algorithm, such as Proof of Work (Pow) algorithm, Proof of stock (PoS) algorithm, Delegated Proof of stock (DPoS) algorithm, and Practical Byzantine Fault Tolerance (PBFT) algorithm.
The obtaining of the consensus on the target ciphertext data may include obtaining the consensus on the target ciphertext data itself, and may also include obtaining the consensus on the ordering information of the target ciphertext data, where the ordering information is used to indicate an order of the target ciphertext data in the block chain system, and may be, for example, information such as a number or a sequence number. In this way, each consensus node in the consensus system can achieve consensus on the data of the target ciphertext data and the arrangement sequence, that is, the target ciphertext data and the corresponding arrangement sequence are determined to be unique and accurate.
In a possible implementation manner, the consensus network may further perform consensus processing on the access admission condition information in each data write request and achieve consensus, so as to ensure that the access admission condition information finally determined and stored by each consensus node is accurate and unique information, and ensure that the access admission condition information is valid.
S208: and each consensus node respectively stores the obtained target ciphertext data and the obtained key share.
That is, after the consensus system agrees on the target ciphertext data, each consensus node stores the same target ciphertext data received from each data owner locally, and stores different key shares received from each data owner locally, so that uplink storage of the target ciphertext data and the key shares is realized, and separate storage of the key shares is realized because each key share is stored in a different consensus node, so that even if a certain consensus node fails, for example, an adversary attacks the key share stored in the failed consensus node to be leaked out, but an adversary cannot obtain a sufficient number of key shares to recover the target key because the adversary cannot obtain other key shares, so that the security of the target key can be improved by storing the key shares separately, thereby ensuring the safety of storage on the target ciphertext data chain.
In addition, if the data write request further includes a key share signature and/or access admission condition information, each consensus node may also store the received key share signature and/or access admission condition information together with the target ciphertext data and the key share locally at each consensus node.
For example, if the data write request further includes a key share signature, after determining that the target ciphertext data is agreed, each consensus node may store the obtained target ciphertext data, the key share, and the corresponding key share signature locally at each consensus node.
For another example, if the data write request further includes access admission condition information, after determining that the target ciphertext data is agreed, or after determining that both the target ciphertext data and the access admission condition information are agreed, each consensus node may store the obtained target ciphertext data, the obtained key share, and the obtained access admission condition information locally at each consensus node.
For another example, if the data write request further includes a key share signature and access admission condition information at the same time, after determining that the target ciphertext data is agreed, or after determining that the target ciphertext data and the access admission condition information are agreed, each consensus node may store the obtained target ciphertext data, the access admission condition information, the key share, and the corresponding key share signature locally in each consensus node, that is, locally store these data.
S209: and each consensus node respectively sends successful writing indication information to the data owner, and correspondingly, the data owner receives the successful writing indication information sent by each consensus node.
After storing the information in the data write request sent by the data owner locally, each consensus node may send successful write indication information to the data owner, where the successful write indication information is used to indicate that the data to be written in the corresponding data write request has been successfully stored in each consensus node, for example, to indicate that the target ciphertext data and the key share in the data write request have been successfully stored in the consensus node.
In implementation, the successful writing indication information sent by each consensus node to the data owner may be the same, that is, the format and content of the sending may be the same, or may be different, and fig. 2 illustrates the same successful writing indication information as an example.
S210: and when the data owner determines that the successful writing indication information exceeds the preset number, determining that the target ciphertext data has been successfully written.
In practice, since individual common nodes in the blockchain system may have been attacked or failed, the common nodes may not be able to successfully send the successful write indication information to the data owner, but generally, the number of the common nodes that operate normally is the majority, that is, the number of the successful write indication information received by the data owner may be equal to or less than the number of the common 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 be determined that the target ciphertext data and the target key (corresponding to the dispersedly stored plurality of key shares) have been successfully written into the blockchain system through a predetermined number (e.g., referred to as a first predetermined number) of successful write indication information, that is, the target ciphertext data and the target key can be considered to have been successfully stored into the blockchain system when the received successful write indication information exceeds the first predetermined number. The first predetermined number here relates to the value of t in the (t, n) secret sharing mechanism described above, and may be any integer equal to or greater than t and less than or equal to n, so as to ensure that the number of key shares that have been accurately stored is sufficient for subsequent use in recovering the target key. Or, for example, n consensus nodes are included in the entire consensus system, and assuming that the number of nodes that have been controlled by an adversary in the entire consensus system is at most f, the value of t may be f +1 ≦ t ≦ n-f, that is, the value of t may be determined according to the number of failed nodes assumed in the consensus system.
In a specific implementation process, when the common node stores the key share, the key share may be stored in a Trusted Execution Environment (TEE) of each common node, so as to improve security of the key share as much as possible.
Specifically, in order to secure the target ciphertext data and the key share as much as possible, for this reason, each consensus node may store the target ciphertext data and the key share in a trusted execution environment of the consensus node when storing the target ciphertext data and the key share, taking a consensus node (for example, a consensus node a) as an example, the consensus node a may store the target ciphertext data, the key share, and a corresponding key share signature in a first storage area, and store the access admission condition information in a second storage area, where the second storage area is a conventional memory area, and the first storage area is located in the TEE, so that the security of the target ciphertext data and the key share may be further ensured. In another possible embodiment, since the trusted execution environment needs to be maintained additionally, in order to reduce the storage occupancy of the TEE, in view of the requirement that the target ciphertext data be secured as much as possible, it is desirable to maintain the security of the key share, for which purpose only the key share may be stored in the trusted execution environment, while the target ciphertext data, the access admission condition information, and the key share signature are stored in a conventional storage area, or only the key share and the key share signature may be stored in the TEE, while the target ciphertext data and the access admission condition information are stored in a conventional storage area, so as to ensure the security of the key share as much as possible.
The TEE is a trusted execution environment which is based on the safety extension of CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. With the high-speed development of the internet, the security requirement is higher and higher, more requirements are provided for the TEE by mobile equipment, cloud equipment and a data center, and the concept of the TEE is also developed and expanded at a high speed. The concept of TEE is now more generalized than that originally proposed, for example, server chip manufacturers Intel, AMD, etc. have introduced hardware-assisted TEE in turn and enriched the concept and characteristics of TEE, which has gained wide acceptance in the industry.
Taking the Intel SGX technology as an example, SGX provides an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking the above-mentioned common node a using a CPU supporting SGX as an example, with a newly added processor instruction, a part of area may be allocated in the memory of the common node a as an enclosure Page Cache or an Enclave Page Cache (EPC), data of the EPC is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU, and encrypted content in the EPC is decrypted only after entering the CPU, so that a key share may be stored in the area. In the SGX, a user may not trust an operating System, a Virtual Machine Monitor (VMM), or even a Basic Input Output System (BIOS), and only need to trust the CPU to ensure that private data is not leaked, so that sufficient security of the key share can be ensured by storing the key share in the EPC, and the possibility of the key share being leaked is low.
In the block chain data writing scheme in the embodiment of the application, a secret sharing mechanism is adopted to split the target key and store the split target key in a distributed manner in a plurality of common nodes in a block chain system, so that the security of the target key can be improved, and even if some block chain nodes are invalid or unsafe due to malicious attack or hardware failure, an attacker cannot obtain a certain number of key shares (for example, the t introduced above) to recover the target key, so that the security of target ciphertext data is further ensured, and the security of data uplink storage is improved.
The process of the data owner for uplink storage of the target ciphertext data and each key share to the blockchain system is described above with reference to fig. 2, and the process of uplink storage of data is described below with reference to fig. 3 for a process of the data access party for requesting access to the target ciphertext data to the blockchain system. Fig. 3 is a flowchart illustrating a method for accessing blockchain data according to an embodiment of the present disclosure, where the flowchart illustrated in fig. 3 is described as follows.
S301: the data access direction initiates data access requests to all the consensus nodes, and correspondingly, all the consensus nodes acquire the data access requests initiated by the data access party.
When the data accessing party wishes to read the data on the blockchain, a request may be sent to the blockchain system, for example, when the data accessing party wishes to read the target ciphertext data stored on the blockchain, a data access request including a target data identifier may be sent to the blockchain system, where the target data identifier is identification information for uniquely identifying the target ciphertext data, and may be, for example, sorting information such as a number or a sequence number of the target ciphertext data, or may be related indication information indicating when all parties of the data of the target ciphertext data uplink store, or the like.
Based on the introduction of the block chain data writing method, it can be known that each consensus node in the block chain system stores a key share corresponding to target ciphertext data and a target key used for encrypting the target ciphertext data, and the key shares stored in each consensus node are different from each other, where the key shares stored in each consensus node are obtained by splitting the target key by a secret sharing mechanism by a data owner. In order to obtain target ciphertext data and enough key shares, a data access direction initiates a data access request to a block chain system, which may be to initiate a data access request to each consensus node, and in a specific implementation process, each consensus node may obtain the data access request initiated by the data access direction in any one of the following manners.
In the mode 1, the data access party generates a data access request carrying a target data identifier, and the data access request is respectively sent to each consensus node, so that each consensus node can directly receive the data access request from the data access party.
In the method 2, the data access party generates a data access request carrying a target data identifier, and sends the data access request to a certain consensus node in the consensus network, for example, the consensus node is called a target consensus node, and then the target consensus node spreads (for example, broadcasts) the data access request to other consensus nodes in the consensus network, so that each consensus node can also obtain the data access request. The target consensus node directly receiving the data access party from the data access party may be any one of the consensus nodes in the consensus network, and the target consensus node may be pre-designated or randomly selected by the data access party, for example, for a consensus network using a consensus algorithm competing for accounting rights such as POW, POS, DPOS, the data access party may randomly select one of the consensus nodes as the target consensus node, and for a consensus network using a consensus algorithm not competing for accounting rights such as PBFT, the data access party may determine the accounting node (which is pre-agreed) as the target consensus node.
The data access request carries a target data identifier, and in addition, the data access request can also include to-be-verified authority information of a data access party, or can also include to-be-verified authority information of the data access party and an authority signature corresponding to the to-be-verified authority information. The authority information to be verified is information used for verifying whether a data access party has the authority for reading the target ciphertext data, and the authority signature is signature information used for verifying the validity of the authority information to be verified.
The data access party may be any authorized client, a trusted authentication center, or a consensus protocol upper layer program, which is not limited in the embodiments of the present application.
S302: and each consensus node determines target ciphertext data and a key share corresponding to the target data identifier from the local storage.
Please refer to fig. 2, which is a description of contents stored in the respective common nodes, that is, the same target ciphertext data is stored in different common nodes, but the key shares stored in the respective common nodes are different from each other, and the key shares stored in all the common nodes are obtained by splitting a target key used for obtaining the target ciphertext data through encryption by a data owner through a 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 key share corresponding to the target ciphertext data.
S303: and each consensus node determines 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.
In a specific implementation process, each common identification node can independently verify the access authority of the data access party according to the information of the authority to be verified and the authority signature so as to obtain an access authority verification result of the data access party. Specifically, each common identification node firstly verifies the validity of the permission information to be verified according to the permission signature, and then verifies the access permission of the data access party according to the permission information to be verified when the validity of the permission information to be verified passes the verification, for example, the permission information to be verified and the access admission condition information stored in the block chain system in advance by the data owner can be matched and compared, and when the matching result is a set matching result, the access permission of the data access party can be determined to pass the verification. As mentioned above, the access admission condition information may be a blacklist or a whitelist, such as a user identifier, a client identifier, and a device identifier, which are specified by a data owner and allow or disallow access to the target ciphertext data, or the access admission condition information may also be a restriction condition that allows or disallows access to the target ciphertext data. The access right verification of each consensus node on the data access party can be carried out locally and independently, and the access right verification of each consensus node on the data access party can be carried out in parallel, so that the right verification process of the whole block chain system on the data access party can be accelerated to a certain extent, and the occupation of public resources on the chain can be reduced as much as possible by the independent verification mode of each consensus node.
In another embodiment, each consensus node can also perform consensus processing on the information of the right to be verified and the right signature jointly, and determine that the access right of the data access party passes verification when consensus is achieved. Specifically, the consensus network can determine the consensus node with the accounting right by running a consensus algorithm, and then the consensus node with the accounting right determines whether the data access party has the access right by adopting the mode that the consensus node independently verifies the access right of the data access party according to the information of the right to be verified and the right signature, and then the determination result is diffused to other consensus nodes. All the consensus nodes verify the access authority in a consensus mode, and the consensus characteristic of the block chain network is fully utilized, so that the consistency of each consensus node on the final verification result cognition can be ensured, one round of consensus processing can be performed in the specific implementation process, or different consensus algorithms can be adopted for performing at least two rounds of consensus verification to improve the accuracy of the verification result, and the embodiment of the application is not limited.
As mentioned above, the access admission condition information may be a blacklist or a whitelist, such as a user identifier, a client identifier, and a device identifier, which are specified by a data owner and allow or disallow access to the target ciphertext data, or the access admission condition information may also be a restriction condition that allows or disallows access to the target ciphertext data.
In the embodiment of the application, the access authority of the data access party is verified through the authority signature and the authority information to be verified, so that the access control of an accessor can be realized, the safety and the effectiveness of data access can be improved to the greatest extent, and the safety of data on a chain is also ensured.
In practice, the data accessing party may be the data owner described in the embodiment corresponding to fig. 2, that is, the data accessing party may request access to the encrypted data that has been previously uplink stored in the blockchain system, for example, when the data accessing party forgets the key of the encrypted data that has been previously uplink stored, the data accessing party may obtain the target ciphertext data and the target key again in this way, so as to obtain the plaintext data corresponding to the encrypted data again, and further may implement the data re-management. In this case, the access admission condition information pre-uplinked and stored by the data owner (in this case, the data accessing party) may include related information that allows the data accessing party to access the target ciphertext data, such as a user identifier of the data accessing party, so that when performing the matching comparison, it is ensured that the data accessing party can obtain the target ciphertext data and the plurality of key shares from the blockchain through the authority authentication.
In particular implementation, S303 is an optional step, and is therefore indicated by a dashed box in fig. 3.
S304: and each consensus node respectively sends the local target ciphertext data and the key share to the data access party, and correspondingly, the data access party receives the target ciphertext data and the key share sent by each consensus node.
When the access authority verification of the data access party passes, the data access party is indicated to have the target ciphertext data on the authority access chain, each common identification node can send the target ciphertext data to the data access party, and meanwhile, a decryption key needs to be sent to the data access party so that the data access party can complete decryption of the target ciphertext data, but as the target key for encryption is already split into a plurality of key shares, each common identification node also sends the respectively stored key shares to the data access party, so that the data access party can recover the target key according to the received plurality of key shares, and then the target ciphertext data is decrypted by adopting the target key.
Referring to fig. 3, S304 may include steps of S304a and S304n, where S304a is that the consensus node 1 transmits the target ciphertext data and the key share 1 to the data accessing party, and S304n is that the consensus node n transmits the target ciphertext data and the key share n to the data accessing party. It should be noted that fig. 3 is only illustrated by the consensus node 1 and the consensus node n, and in the implementation process, other consensus nodes may be further included, and correspondingly, the other consensus nodes may further send target ciphertext data and other key shares to the data access party.
S305: and the data access party determines a target key according to the predetermined number of different key shares and decrypts the target ciphertext data according to the target key.
In practice, the target ciphertext data and the corresponding key share cannot be returned to the data access party or the correct target ciphertext data and the corresponding key share cannot be sent to the data access party due to the fact that some common nodes in the blockchain system may have been attacked maliciously or have a hardware failure. Therefore, according to the principle of the (t, n) secret sharing technology, the data access party can recover the target key as long as the data access party receives a predetermined number (for example, referred to as a second predetermined number, which is an integer greater than or equal to t and less than or equal to n) of mutually different key shares at least, and then decrypt the target ciphertext data according to the target key, thereby realizing the effective access of the data on the chain.
As described above, each consensus node may further include a key share signature corresponding to the key share in addition to the stored target ciphertext data and the different key shares, based on which, each consensus node may also send the key share signature corresponding to the key share to the data access party while sending the target ciphertext data and the key share to the data access party, so that the data access party may first perform validity verification on the key share itself according to the key share signature, and when the validity verification of the key share passes, use the key share as a valid key share, and further use a second predetermined number of different valid key shares to recover the target key. After the target key is obtained, the target ciphertext data can be decrypted by operating a decryption algorithm corresponding to a symmetric encryption algorithm adopted by all parties of the data, so that plaintext data corresponding to the target ciphertext data can be obtained, and effective access to the data on the link can be realized.
In the embodiment of the application, a data owner splits a target key used for encrypting to obtain target ciphertext data into a plurality of key shares while chaining the target ciphertext data to store, distributively stores the split key shares in each node in a block chain system, and adopts a secret sharing cryptographic technology, so that even if an individual key share is maliciously stolen or tampered, the accurate recovery of the target key is not influenced, the security of the target key in the block chain system is improved, the security of the target ciphertext data is improved, and further, when a data access party accesses the target ciphertext data on the chain, the data access party can be ensured to recover the correct target key through a certain number of key shares on the basis of effectively protecting the target ciphertext data through the dispersed keys, so that the target ciphertext data can be effectively protected, And the safety access improves the safety of the access to the data stored on the block chain.
For convenience of understanding, the technical solutions in the embodiments of the present application are described below with reference to fig. 4 and 5.
Referring to fig. 4, it is assumed that the target ciphertext data that the data owner needs to uplink store is C, the data owner determines that the access admission condition information that can access the target ciphertext data is represented by ACL, the target key used for obtaining the target ciphertext data C through encryption in a symmetric encryption manner is K, the data owner splits the target key K into four key shares, namely K1, K2, K3 and K4, by using a secret sharing technique, and the key share signatures corresponding to K1, K2, K3 and K4 are represented by Sig1, Sig2, Sig3 and Sig4, respectively. In a specific implementation, the number of how many key shares the data owner splits the target key K into may be the same as the number of common nodes included in the common network in the blockchain system, for example, 4 common nodes are shown in fig. 4.
Further, the data owner generates 4 data Write requests, such as Write1, Write2, Write3, Write4 in fig. 4, depending on the key shares. Target ciphertext data C and access admission condition information ACL are carried in Write1, Write2, Write3 and Write4, and key shares and corresponding key share signatures carried in the 4 data Write requests are different, as shown in fig. 4, Write1, Write2, Write3 and Write4 carry key share K1 and key share signature 1, key share K2 and key share signature Sig2, key share K3 and key share signature 3, key share K4 and key share signature Sig4, respectively. After each consensus node receives the corresponding data Write request, if the consensus node 1 receives Write1, the consensus node 2 receives Write2, the consensus node 3 receives Write3, and the consensus node 4 receives Write4, the information carried in the received data Write request is respectively stored locally, as shown in the lower graph of fig. 4. Then, each consensus node sends successful write indication information to the data owner, in fig. 4, Success1, Success2, Success3, and Success4 represent successful write indication information sent by each consensus node, respectively, and the data owner can determine that the target ciphertext data has been successfully written into the block chain system according to a sufficient amount of successful write indication information, thereby realizing uplink storage of the encrypted data.
Referring to fig. 5 again, when the data access party wishes to Read the target ciphertext data from the blockchain system, a corresponding Read command may be sent to each consensus node, in fig. 5, Read1, Read2, Read3, and Read4 respectively represent data access requests sent by the data access party to each consensus node, and information carried by each data access request is the same, it is assumed that ts represents a number of the target ciphertext data (corresponding to the target data identifier), IDc represents an identity of the data access party (corresponding to the information about the right to be verified), and Sigc is an identity signature corresponding to the identity of the data access party (corresponding to the right signature). Fig. 5 shows a manner of sending a data access request to each consensus node, and in another possible implementation, a data access party may also send a data access request to only one of the consensus nodes, and then the data access request is broadcast to the remaining nodes by the node.
Furthermore, each consensus node can verify the validity of the identity IDc of the data access party according to the Sigc in the data write request, verify the access authority according to the IDc, and determine target ciphertext data, a key share and a key share signature corresponding to ts from a local storage after the verification is passed. Further, the consensus node 1, the consensus node 2, the consensus node 3, and the consensus node 4 respectively send the target ciphertext data, the key share, and the corresponding key share signature stored therein to the data access side, as shown in fig. 5, the consensus node 1 sends C, K1, Sig1 to the data access side, the consensus node 2 sends C, K2, Sig2 to the data access side, the consensus node 3 sends C, K3, Sig3 to the data access side, and the consensus node 4 sends C, K4, Sig4 to the data access side. After receiving the data returned by each node, the data owner can recover and obtain the target key K through enough number of mutually different key shares according to a secret sharing mechanism, and then decrypt the target ciphertext data C by using the target key K to finish effective access to the chained data.
In the embodiment of the application, the data owner, the data access party and the block chain system can exchange data by using the encryption channel, so that the data can be transmitted safely as much as possible. In addition, the data owner, the data access party and the blockchain system can use Trusted hardware, TEE, Trusted Platform Module (TPM), crypto card, crypto machine and the like, so as to ensure that data can be processed and stored safely and reliably.
Based on the same inventive concept, an embodiment of the present application provides a blockchain system, for example, the blockchain system in fig. 1, where the blockchain system includes at least two common nodes, and the at least two common nodes form a common network, where:
each consensus node is used for respectively obtaining data writing requests sent by a data owner, wherein each data writing request comprises the same target ciphertext data and different key shares, 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; and performing consensus processing on the target ciphertext data; and respectively saving the obtained target ciphertext data and the key share after determining that the consensus on the target ciphertext data is achieved.
Based on the block chain system in the embodiment of the present application, the processes described in fig. 2 and fig. 4 may be implemented, a target key corresponding to target ciphertext data is split into a plurality of key shares based on a secret sharing technique, and each key share is dispersedly stored in each target block chain node, so that the security of the target key may 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, an embodiment of the present application provides a blockchain system, for example, the blockchain system in fig. 1, where the blockchain system includes at least two common nodes, and the at least two common nodes form a common network, where:
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 identification from a local storage, wherein the key shares locally stored by the common identification nodes are different from each other, each key share is obtained by splitting a target key through a secret sharing mechanism by a data owner, and the target ciphertext data is obtained by encrypting plaintext data by the data owner through the target key; and respectively sending the locally stored target ciphertext data and the key shares to a data access party, so that the data access party determines a target key according to a predetermined number of different key shares and decrypts the target ciphertext data according to the target key.
Based on the foregoing processes described in fig. 3 and fig. 5, when accessing data on a blockchain, even if some nodes in the blockchain system may have been maliciously attacked and insecure, for example, target ciphertext data and key shares stored on the nodes have been tampered with, since a secret sharing technique is used, a sufficient number of key shares need to be obtained to recover the target key, so that the security of the target key can be ensured, and a data accessing party can recover the correct target key when receiving a sufficient number of correct key shares, which can ensure the validity of the recovered target key even if some key shares are no longer trustworthy, thereby improving security control over data access.
Based on the same inventive concept, embodiments of the present application provide a base blockchain data writing apparatus, which may be a hardware structure, a software module, or a hardware structure plus a software module, and which may be configured in each common node in a blockchain system. Referring to fig. 6, the apparatus for writing blockchain data in the embodiment of the present application includes an obtaining module 601, a consensus module 602, and a storage module 603, where:
an obtaining module 601, configured to obtain a data write request sent by a data owner; the data writing requests comprise same target ciphertext data and different key shares, the target ciphertext data are obtained by encrypting plaintext data by a target key by a data owner, and the key shares are 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, after determining that the target ciphertext data is agreed, store the obtained target ciphertext data and the key share.
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 configured to:
and storing the obtained target ciphertext data, the key share and the corresponding key share signature.
In a possible implementation manner, each data write request further includes access admission condition information, and the storage module 603 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; alternatively, the first and second electrodes may be,
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.
In one possible implementation, the access admission condition information includes condition information that allows the data owner to access the target ciphertext data.
In a possible implementation manner, the block chain data writing apparatus in this 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 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 predetermined number.
In particular, the sending module 604 is an optional module, i.e. the sending module 604 is not a necessary module and is therefore indicated by a dashed box in fig. 6.
All relevant contents of each step involved in the embodiment of the block chain data writing method may be referred to in the description of the function module corresponding to the block chain data writing device in the embodiment of the present application, and are not described herein again.
Based on the same inventive concept, the embodiments of the present application provide a blockchain data access apparatus, which may be a hardware structure, a software module, or a hardware structure plus a software module, and which may be configured in each consensus node in a blockchain system. Referring to fig. 7, the device for accessing blockchain data in the embodiment of the present application includes an obtaining module 701, a determining module 702, and a sending module 703, where:
an obtaining module 701, configured to obtain a data access request initiated by a data accessing party, where the data access request includes a target data identifier;
a determining module 702, configured to determine, from a local storage, target ciphertext data and a key share corresponding to a target data identifier, where the key shares locally stored by the consensus nodes are different from each other, each key share is obtained by splitting a target key by a data owner through a secret sharing mechanism, and the target ciphertext data is obtained by encrypting plaintext data by the data owner with the target key;
the sending module 703 is configured to 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 a predetermined number of different key shares, and decrypts the target ciphertext data according to the target key.
In one possible implementation, the determining module 702 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 703 is configured to:
and sending the target ciphertext data, the key share and the corresponding key share signature which are locally stored to the data access party.
In a possible implementation manner, the data access request further includes to-be-verified authority information and an authority signature of the data accessing party, and the blockchain data access apparatus in this embodiment further includes an authority verification module 704, configured to:
before the sending module 703 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 right information 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.
In one possible implementation, the rights verification module 704 is configured to:
matching the authority information to be verified with access admission condition information, wherein the access admission condition information is determined by a 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.
In one possible implementation, the access admission condition information includes condition information that allows the data owner to access the target ciphertext data.
In one possible implementation, the rights verification module 704 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, performing consensus processing on the information of the right to be verified and the right signature, and determining that the access right of the data access party passes verification after consensus is achieved.
In particular embodiments, the rights verification module 704 is an optional module, i.e., the rights verification module 704 is not required and is therefore shown in FIG. 7 as a dashed box.
All relevant contents of each step involved in the embodiments of the block chain data access method may be referred to the functional description of the functional module corresponding to the block chain data access device in the embodiments of the present application, and are not described herein again.
The division of the modules in the embodiments of the present application is schematic, and only one logical function division is provided, and in actual implementation, there may be another division manner, and in addition, each functional module in each embodiment of the present application may be integrated in one processor, may also exist alone physically, or may also be integrated in one module by two or more modules. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.
Based on the same inventive concept, the present application also provides a computer storage medium, which may be a computer readable storage medium, and the computer storage medium stores computer instructions or a computer readable program, and when the computer instructions or the computer readable program are executed on a computer, the computer executes the steps of the block chain data writing method as described above.
Based on the same inventive concept, the present application also provides a computer storage medium, which may be a computer readable storage medium, and the computer storage medium stores computer instructions or a computer readable program, and when the computer instructions or the computer readable program are executed on a computer, the computer executes the steps of the block chain data access method as described above.
In some possible implementations, the aspects of the blockchain data writing method provided in the embodiments of the present application can also be implemented in the form of a program product, which includes program code for causing a computer to perform the steps of the blockchain data writing method according to the various exemplary embodiments of the present application described above when the program product is run on the computer.
In some possible implementations, the aspects of the blockchain data access method provided in the embodiments of the present application may also be implemented in the form of a program product including program code for causing a computer to perform the steps of the blockchain data access method according to the various exemplary embodiments of the present application described above when the program product is run on the computer.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or 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, and the like) 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 application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such 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 intended to include such modifications and variations as well.

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; alternatively, the first and second electrodes may be,
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; alternatively, the first and second electrodes may be,
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; alternatively, the first and second electrodes may be,
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; alternatively, the first and second electrodes may be,
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.
CN202110634791.3A 2021-06-08 2021-06-08 Block chain data writing and accessing method and device Active CN113098697B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110634791.3A CN113098697B (en) 2021-06-08 2021-06-08 Block chain data writing and accessing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110634791.3A CN113098697B (en) 2021-06-08 2021-06-08 Block chain data writing and accessing method and device

Publications (2)

Publication Number Publication Date
CN113098697A CN113098697A (en) 2021-07-09
CN113098697B true CN113098697B (en) 2022-03-18

Family

ID=76664466

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110634791.3A Active CN113098697B (en) 2021-06-08 2021-06-08 Block chain data writing and accessing method and device

Country Status (1)

Country Link
CN (1) CN113098697B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114331430B (en) * 2021-12-24 2023-03-31 杭州钛度科技有限公司 Block chain consensus method, apparatus, device and medium
CN115277052A (en) * 2022-06-07 2022-11-01 国网北京市电力公司 Data encryption method and device based on block chain and electronic equipment
CN116090020B (en) * 2023-04-13 2023-06-30 中国人民解放军海军潜艇学院 Block chain-based information storage method and device, electronic equipment and storage medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106850654A (en) * 2017-02-23 2017-06-13 布比（北京）网络技术有限公司 The mandate access method and system of a kind of distributed information

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106548345B (en) * 2016-12-07 2020-08-21 北京信任度科技有限公司 Method and system for realizing block chain private key protection based on key partitioning
US10735183B1 (en) * 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
CN107623569A (en) * 2017-09-30 2018-01-23 矩阵元技术（深圳）有限公司 Block chain key escrow and restoration methods, device based on Secret sharing techniques
CN108683509B (en) * 2018-05-15 2021-12-28 北京创世智链信息技术研究院 Block chain-based secure transaction method, device and system
CN108809652B (en) * 2018-05-21 2021-07-23 安徽航天信息有限公司 Block chain encrypted account book based on secret sharing
CN109150968B (en) * 2018-07-13 2021-09-14 上海大学 Block chain distributed storage method based on secret sharing
CN109672529A (en) * 2019-01-07 2019-04-23 苏宁易购集团股份有限公司 A kind of method and system for going anonymization of combination block chain and privacy sharing
CN109902494A (en) * 2019-01-24 2019-06-18 北京融链科技有限公司 Data encryption storage method, device and document storage system
CN110297831A (en) * 2019-07-01 2019-10-01 电子科技大学 A kind of block chain fragment storage method based on threshold secret sharing

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106850654A (en) * 2017-02-23 2017-06-13 布比（北京）网络技术有限公司 The mandate access method and system of a kind of distributed information

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
区块链系统下的多方密钥协商协议;唐春明等;《信息网络安全》;20171210(第12期);全文 *

Also Published As

Publication number Publication date
CN113098697A (en) 2021-07-09

Similar Documents

Publication Publication Date Title
CN110875821B (en) Cryptography blockchain interoperation
CN113098697B (en) Block chain data writing and accessing method and device
CN111327643B (en) Multi-party data sharing method and device
CN113259123B (en) Block chain data writing and accessing method and device
CN112651037B (en) Out-of-chain data access method and system for block chain system
US20140096213A1 (en) Method and system for distributed credential usage for android based and other restricted environment devices
US20040098591A1 (en) Secure hardware device authentication method
US10771467B1 (en) External accessibility for computing devices
US20210359847A1 (en) Exchanging Cryptographic Key Information
KR20170019308A (en) Method for providing trusted right information, method for issuing user credential including trusted right information, and method for obtaining user credential
US11288381B2 (en) Calculation device, calculation method, calculation program and calculation system
CN111932261A (en) Asset data management method and device based on verifiable statement
US20150047001A1 (en) Application program execution device
CN115277168A (en) Method, device and system for accessing server
US11640480B2 (en) Data message sharing
CN113726733B (en) Encryption intelligent contract privacy protection method based on trusted execution environment
EP3455763B1 (en) Digital rights management for anonymous digital content sharing
CN113259124A (en) Block chain data writing and accessing method and device
EP3836478A1 (en) Method and system of data encryption using cryptographic keys
CN109302442B (en) Data storage proving method and related equipment
CN116881936A (en) Trusted computing method and related equipment
US11784804B2 (en) Distributed anonymized compliant encryption management system
CN114117471A (en) Confidential data management method, electronic device, storage medium, and program product
CN113098696A (en) Block chain data writing and accessing method and device
CN106411826A (en) Data access method and equipment thereof

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant