CN111737340A - Block chain storage encryption method based on attribute encryption - Google Patents
Block chain storage encryption method based on attribute encryption Download PDFInfo
- Publication number
- CN111737340A CN111737340A CN202010167045.3A CN202010167045A CN111737340A CN 111737340 A CN111737340 A CN 111737340A CN 202010167045 A CN202010167045 A CN 202010167045A CN 111737340 A CN111737340 A CN 111737340A
- Authority
- CN
- China
- Prior art keywords
- stage
- node
- nodes
- request
- consensus
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- 230000007246 mechanism Effects 0.000 claims abstract description 7
- 230000004044 response Effects 0.000 claims description 45
- 230000008569 process Effects 0.000 claims description 13
- 238000012545 processing Methods 0.000 claims description 12
- 238000005206 flow analysis Methods 0.000 claims description 7
- 238000005516 engineering process Methods 0.000 abstract description 4
- 230000000875 corresponding effect Effects 0.000 description 7
- 230000007547 defect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- HDRXZJPWHTXQRI-BHDTVMLSSA-N diltiazem hydrochloride Chemical compound [Cl-].C1=CC(OC)=CC=C1[C@H]1[C@@H](OC(C)=O)C(=O)N(CC[NH+](C)C)C2=CC=CC=C2S1 HDRXZJPWHTXQRI-BHDTVMLSSA-N 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- 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/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
Abstract
The invention provides a block chain storage encryption method based on attribute encryption, which belongs to the technical field of data encryption and comprises the following steps: step 1, an external user requests to access data on a chain; step 2, checking whether an external user meets the access condition or not through a medical record identifier and a medical record object set by an attribute encryption algorithm; step 3, if not, access is refused; if the data are matched, the goal of accessing the data on the chain is achieved through the consensus algorithm SCA. The method combines the block chain technology with the attribute encryption to protect the data on the chain, namely the doctor-patient data of the patient, so as to realize the safe sharing of the electronic medical record; the block chain has natural advantages for privacy protection, and the invention combines the technologies of cryptography, computer network, asynchronous Byzantine fault tolerance and the like, optimizes the consensus mechanism in the chain, and designs and realizes a alliance chain with low delay and certain throughput.
Description
Technical Field
The invention belongs to the technical field of data encryption, and particularly relates to a block chain storage encryption method based on attribute encryption.
Background
Today, the importance of medical data of patients is self-evident. However, medical data of different hospitals cannot be shared, which results in medical delay to some extent. Therefore, people realize sharing of medical data through sharing of electronic medical records, but the electronic medical records sharing has the problems of safety, privacy protection and the like to a certain extent, and the problems can be solved to a certain extent by encrypting the data.
The block chain has great advantages in protecting the privacy information of the patient due to high redundancy, distributed storage, incapability of tampering and management of multiple signature complex authorities, and the record can be greatly simplified and the safety can be improved through the block chain. The block chain is composed of invariable data records (data blocks), medical data are stored on the blocks, and the data are connected in a cryptographic mode, so that the safety of the data is ensured. Meanwhile, the data on the blockchain is public, and the data is guaranteed to be not falsified through the time stamp.
Attribute encryption (ABE) is a new one-to-many encryption scheme, which essentially implements access control to encrypted data by defining the identity of a user through attributes, thereby introducing an access control structure defined by the attributes. The core of the algorithm of attribute encryption is to embed the attribute/policy into the key/ciphertext. The ABE scheme is classified into key policy-based attribute encryption (KP-ABE) and ciphertext policy-based attribute encryption (CP-ABE) according to an embedded object.
In the prior art, Scher Tengfei and the like propose an electronic medical information sharing model based on a block chain, and solve the problem that medical information of each unit is not shared timely to a certain extent; azaria Z proposes that a medical system is established through a block chain, and the system sets authority for acquiring medical data; xia Q has proposed a privacy disclosure problem that may occur when medical data is shared, in a weak trust hosting environment, through a blockchain.
Among the schemes for encrypting electronic medical records using attribute encryption, ibrimi proposes a patient-centric scheme, where a Trusted Authority (TA) is responsible for managing attributes in the public domain and the medical record owner himself acts as a TA in the personal domain to publish attributes related to the personal domain. Thus, the medical record owner can encrypt the key, allowing only users with attributes that satisfy the associated access structure to successfully decrypt.
The prior art scheme is mostly a working mode of a workload mechanism of a public link in a block chain, data is transmitted on the public link, a situation that the data cannot be updated in time exists, and the time of one transaction is far longer than that of a alliance link mode. Moreover, as the number of users increases, the cost of the users and the energy consumption of the whole system increase, and finally the system may not support the users to continue the transaction. At the same time, a single TA is used in attribute encryption to manage the user attributes of the public domain, which may lead to a single point of failure and at the same time to key escrow problems, considering the fact that the TA can access all encrypted files.
In the existing public chain consensus algorithm, such as a workload certification-based consensus algorithm (POW), a large amount of resource waste and a high-volume incentive mechanism are relied on, and ten-thousand-level full-node data synchronization is only realized, and the efficiency problem exists. The efficiency of a Byzantine fault-tolerant algorithm (BFT) based on message transmission used by the existing alliance chain is higher than that of POW, but fault tolerance can be realized only among hundreds of nodes, and the existing alliance chain has the defect of small number of fault-tolerant nodes.
Therefore, the application provides an encryption method for block chain storage based on attribute encryption.
Disclosure of Invention
In order to overcome the defects in the prior art, the invention provides a block chain storage encryption method based on attribute encryption.
In order to achieve the above purpose, the invention provides the following technical scheme:
a block chain storage encryption method based on attribute encryption comprises the following steps:
step 1, an external user requests to access data on a chain;
step 2, checking whether an external user meets the access condition or not through a medical record identifier and a medical record object set by an attribute encryption algorithm;
step 3, if not, access is refused; if the data are matched, the goal of accessing the data on the chain is achieved through the consensus algorithm SCA.
Preferably, in the step 3, the process of executing the consensus algorithm SCA is as follows:
step 3.1, judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, executing step 3.2;
step 3.2, executing a practical Byzantine fault-tolerant algorithm;
step 3.3, continuously judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, the master node is replaced and the step 3.2 is returned.
Preferably, the consensus algorithm SCA of step 2 comprises two phases in total.
Preferably, the successful flow of the consensus algorithm SCA of the first stage is as follows:
(1) a Request stage: the client sends the request to a leader node in the service node, and the next stage is entered after the leader node passes the check request;
(2) and a Commit stage: the leader node numbers the request and forwards the numbered request to all the replica nodes, after receiving the request, the replica nodes directly carry out local processing on the request and obtain a processing result, then directly return the response signature to the client, and enter the next stage;
(3) a Reply stage: the client independently receives responses from all the service nodes, and if all the responses are the same, the consensus is considered to be achieved;
(4) the Response phase: the client needs to return the received responses with the signatures of the representative nodes to all the representative nodes, and the server checks that the responses are the same, so that the consensus at this stage is successful.
Preferably, the fault-tolerant flow analysis of the consensus algorithm SCA of the first stage is as follows:
(1) a Request stage: the leader node and the Reqlica nodes 1,2 and 3 are still the same as the successful process (1) and enter the next stage; at the moment, a Byzantine error occurs in the Replica4 node;
(2) and a Commit stage: the leader node and the Replica 1,2 and 3 have the same successful flow and enter the next stage; at this time, the order of processing the requests by the Replica4 node may not be consistent with Replica 1,2 and 3 due to Byzantine errors;
(3) a Reply stage: the client independently receives the consistent responses from the leader node and the Replica nodes 1,2 and 3, but receives the inconsistent responses from the Replica4 node or receives no response from the Replica4 at all; therefore, the system cannot enter a Response stage in a successful flow, and after the timeout waiting, the client judges that the request is unsuccessful and tries to reinitiate the request;
(4) a sonic stage: if the client receives different response results from the server copy, the client sends the received different responses with the signatures of the representative nodes to all the representative nodes, and the representative nodes enter an Abort stage immediately after verifying that the responses are really inconsistent; or the server cannot receive error feedback of the client, so as to trigger a server overtime check mechanism;
(5) abort stage: all the representative nodes enter a rollback state, rollback the previous commit to the local processing result, and judge that the system in the current asynchronous network has a Byzantine error node; triggering the switching of the consensus algorithm, and switching the system to use a two-stage PBFT algorithm.
Preferably, when the consensus algorithm SCA used in the first stage fails to achieve consensus, the system determines that a byzantine node exists in the asynchronous network, so the system switches to the second stage consensus, the PBFT practical byzantine fault-tolerant algorithm used in the second stage consensus, and the flow analysis of the second stage PBFT consensus algorithm is as follows:
(1) the Reuqest phase: the client sends the request to a Leader node in the server;
(2) Pre-Prepare stage: the Leader node forwards the request to all the replica nodes; in this stage, the replica node ensures that the master node Leader does not send two messages with the same number but different contents;
(3) stage Prepare: all nodes sign the message and broadcast the prefix message to other nodes, and if the same node receives at least 2f +1 prefix messages from different nodes, the node enters a Commit stage; this stage is to get a consensus on a series of messages sent by the leader; determining which message of the leader is being agreed upon;
(4) and a Commit stage: all nodes broadcast commit messages, when 2f +1 commit messages including the nodes are received, enough nodes count the commit stage, namely, consensus is achieved;
(5) a Reply stage: the node returns the response of the request to the user, and when the user receives more than f +1 different responses, the request is confirmed to be successful.
Preferably, the attribute encryption algorithm is divided into four steps, namely system initialization, key distribution, data encryption and data decryption.
The block chain storage encryption method based on attribute encryption provided by the invention has the following beneficial effects:
(1) the invention protects the data on the chain, namely the doctor-patient data of the patient by applying the block chain technology and combining the attribute encryption, thereby realizing the safe sharing of the electronic medical record;
(2) the block chain has natural advantages for privacy protection, the invention combines the technologies of cryptography, computer network, asynchronous Byzantine fault tolerance and the like, optimizes the consensus mechanism in the chain, and designs and realizes a alliance chain with low delay and certain throughput;
(3) the invention provides a new layered consensus algorithm dsBFT, which can have higher throughput and lower delay than the existing consensus algorithm when the network robustness is better, and can realize that when the number of Byzantine nodes in a system is less than one third of the total number of the nodes of the system, the system can obtain the actual asynchronous Byzantine fault-tolerant capability by reducing the throughput and increasing the delay;
(4) according to the invention, an effective attribute encryption algorithm is developed by applying attribute encryption on the block chain, so that the access condition of the data on the chain is limited, fine-grained access control is achieved, and irrelevant visitors are prevented for the patient medical record data, thereby protecting the privacy of patients.
Drawings
Fig. 1 is a flowchart of an encryption method for storing on a block chain based on attribute encryption according to embodiment 1 of the present invention;
FIG. 2 is a flow chart of an implementation of the consensus algorithm SCA;
FIG. 3 is a diagram of a successful flow analysis of the consensus algorithm SCA at the first stage;
FIG. 4 is a fault-tolerant flow analysis diagram of the consensus algorithm SCA at the first stage;
FIG. 5 is a flow chart of a two-stage PBFT consensus algorithm.
Detailed Description
In order that those skilled in the art will better understand the technical solutions of the present invention and can practice the same, the present invention will be described in detail with reference to the accompanying drawings and specific examples. The following examples are only for illustrating the technical solutions of the present invention more clearly, and the protection scope of the present invention is not limited thereby.
Example 1
The invention provides a block chain storage encryption method based on attribute encryption, which specifically comprises the following steps as shown in figure 1:
step 1, an external user requests to access data on a chain;
step 2, checking whether an external user meets the access condition or not through a medical record identifier and a medical record object set by an attribute encryption algorithm;
step 3, if not, access is refused; if the data are matched, the goal of accessing the data on the chain is achieved through the consensus algorithm SCA.
Further, as shown in fig. 2, in step 3, the process of executing the consensus algorithm SCA is as follows:
step 3.1, judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, executing step 3.2;
step 3.2, executing a practical Byzantine fault-tolerant algorithm;
step 3.3, continuously judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, the master node is replaced and the step 3.2 is returned.
Further, the consensus algorithm selection process of this embodiment is as follows:
the SCA algorithm in the first stage is used in a scenario that the robustness of the network is assumed to be good, no Byzantine node exists in the system, consensus can be successfully and rapidly achieved when the assumption is met, and when the consensus is not achieved, the consensus can be found to fail.
The successful flow of the first-stage SCA consensus algorithm is as follows, fig. 3, and the flow analysis is as follows:
(1) a Request stage: the client sends the request to the leader node in the service node, and the leader node enters the next stage after the verification request of the leader node passes.
(2) And a Commit stage: the leader node numbers the request and forwards the numbered request to all the replica nodes, after receiving the request, the replica nodes directly carry out local processing on the request and obtain a processing result, and then directly return the response signature to the client. The next stage is entered.
(3) A Reply stage: the client independently receives responses from all the service nodes, and if all the responses are the same, the consensus is considered to be achieved.
(4) The Response phase: the client needs to return the received responses with the signatures of the representative nodes to all the representative nodes, and the server checks that the responses are the same, so that the consensus at this stage is successful.
The fault-tolerant process analysis of the SCA consensus algorithm in the first stage is as follows, the Replica0 in fig. 4 is the leader node of the current round of consensus, and the Replica3 node has a byzantine error.
(1) A Request stage: the leader node and the Replica nodes 1,2 and 3 are still the same as the successful process (1) and enter the next stage. At this point, the Replica4 node has a Byzantine error.
(2) And a Commit stage: the leader node and the Replica 1,2 and 3 have the same successful process and enter the next stage. At this time, the order of processing the requests by the Replica4 node may not be consistent with Replica 1,2 and 3 due to Byzantine errors.
(3) A Reply stage: the client independently receives a consistent response from the leader node and the Replica nodes 1,2, 3, but receives a response from the Replica4 node that is inconsistent or does not receive a response from the Replica4 at all. Therefore, the system cannot enter a Response stage in a successful flow, and after the timeout waiting, the client judges that the request is unsuccessful and tries to reinitiate the request.
(4) A sonic stage: if the client receives different response results from the server copy, the client sends the received different responses with the signatures of the representative nodes to all the representative nodes, and the representative nodes enter an Abort stage immediately after verifying that the responses are really inconsistent. Or the server cannot receive error feedback of the client, so that a server timeout checking mechanism is triggered.
(5) Abort stage: and all the representative nodes enter a rollback state, rollback the previous commit to the local processing result, and judging that the system in the current asynchronous network has a Byzantine error node. Triggering the switching of the consensus algorithm, and switching the system to use a two-stage PBFT algorithm.
When the high-efficiency consensus algorithm cannot achieve the consensus in one stage, the system judges that the Byzantine node exists in the asynchronous network, so that the system is switched to the two-stage consensus. The PBFT utility byzantine fault-tolerant algorithm is used in the two-stage consensus. The main flow of the two-stage PBFT consensus algorithm is as follows:
the Replica0 in fig. 5 is the leader node in the current round of consensus, and the rcplica3 node has a byzantine error.
(1) The Reuqest phase: the client sends the request to a Leader node in the server.
(2) Pre-Prepare stage: the leader node forwards the request to all replica nodes. In this phase, the replica node ensures that the master node leader does not send two messages with the same number but different contents.
(3) Stage Prepare: all nodes sign the message and broadcast the prefix message to other nodes, and if the same node receives at least 2f +1 prefix messages from different nodes, the Commit stage is entered. This phase is intended to agree on a series of messages issued by the leader. A determination is made as to which message of the leader is being agreed upon.
(4) And a Commit stage: all nodes broadcast commit messages, and when a total of 2f +1 commit messages including the nodes are received, enough nodes count the commit stage, that is, the consensus is achieved.
(5) A Reply stage: the node returns the response of the request to the user, and when the user receives more than f +1 different responses, the request is confirmed to be successful.
In this embodiment, the attribute encryption algorithm includes four steps, which are respectively system initialization, key distribution, data encryption, and data decryption.
Safety requirements are as follows: 1. confidentiality of user data: the patient's medical data must be kept secret to prevent unauthorized parties. 2. Patient-centric access control: the patient user should have full control over the outsourced health data so that they determine who is entitled to access them. 3. Resisting attribute collusion: multiple users should not be able to share their attributes and decrypt medical data.
Scheme overview: the system consists of a plurality of distributed common Attribute Authorities (AA). Each attribute authority manages a set of disjoint attributes and publishes the attributes for users belonging to the public domain. In addition, the patient acts as a private property right to provide properties specifying personal relationships, such as the family of the personal domain user. During system initialization, each AA first defines a set of secret indices and public indices in such a way that: each managed attribute is associated with a different secret attribute index and a corresponding public attribute index. The initialization of the AA can run independently without any global coordination. The PHR user may obtain attributes from the relevant AA by providing evidence of the attributes being eligible for use in the request. If the AA responsible for the requested attribute is satisfied in that the user requesting the attribute qualifies for the requested attribute, the AA will issue the relevant key for the user.
The method comprises the following specific implementation steps:
initializing a system: to initialize the system, a set of global common parameters is first set, shared among all the AAs.
Two multiplicative cyclic groups G0, G1 of prime number p, where G is the generator of G0 and the bilinear map e G0 × G0 → G1 and the secure hash function H:
mapping each subscriber identification string to
Is determined. The user identity should be a unique identifier for a given user, such as an email address. The AA then publishes the global common parameter sets (G0, G1, H, e, G, p). Thus, any new AA can be globally initialized by obtaining the global parameter set shared by existing AAs. Each AA (including the patient) is then initialized locally, and the initialization process is described below. Suppose the kth AA uses AAkIs represented by AAkAT for managed attribute setkAnd (4) showing.
1、AAkTwo random indices α were selectedk,
And calculate Xk＝gβk,Yk＝e(g,g)akThen ATkEach element i in (a) selects a unique random identifier Tk，
Furthermore, from AAkEach attribute managed is also associated with a common attribute index Tk,lRelated, wherein Tk,i＝gtk,i。
2、AAkWill remain αk,βk,Tk,i},i＝1,2...ATkAs Master Key (MK)k) And issues { Xk,Yk,Tk,i},i＝1,2...ATkAs a result of PKkThe public key of the indicated authority.
Key distribution
Suppose user UmTo obtain attribute ATmAggregated attribute keys. In addition, suppose
Indicating that it should be AAkAT acquired inmA subset of attributes in (1). Suppose AAkHas authenticated the user's resourcesTo determine the requested attribute. The process of attribute key distribution is as follows:
AAkfirst use the secure hash function H to hash UmIs mapped to a unique identifier (using an email address as the user's identity)
Then, a key is generated for each request attribute, the key set for use
It is shown that,
wherein
Wherein t iskI is AAkIs defined by
The MK component of the ith attribute. Note that the Key component
Associating a user identity with an issuing authority AAkAre associated with each other, and the key component
The user identity is associated with the attribute itself, and thus the generated key set has been securely transmitted to the Um；
Data encryption
Suppose a patient wants to encrypt medical record data M ∈ G1, which includes information about his allergiesk}kQ, so the ciphertext of M encoded with T is given by e (M), e (M) T,
wherein EkAccess son for representationStructure TkThe ciphertext of the encoded M. The calculation E will be described belowkThe process of (1).
Suppose a kth substructure TkM attributes are contained and they are managed by l AA's, such that 1 ≦ n, where n is the total number of AAs in the system. Any AA can manage multiple ones of the m attributes under consideration. Using ciphertext components C0Representing ciphertext Ek，{C′i}i＝1,2...lFurthermore, { Ci}i＝1,2...mSo that Ek＝(Tk,C0,{C′i}i＝1,2...l,{C″i}i＝1,2...m)，EkThe ciphertext components are calculated as follows. The owner of the medical record first generates a random index
And using the public key of 1 AAs, he calculates the ciphertext component C0And { C'i}i＝1,2...lSo that
To calculate C ″)iAccording to the following steps ofkEach attribute in (a) assigns a secret share of s. For TkEach attribute except the last one of them, has
And the last element is assigned a value of
The medical record owner then calculates { C ″ "i}i＝1,2...mIn this way it is possible to obtain,
wherein T isiCorresponds to TkThe common attribute index of the ith attribute.
Likewise, the medical record owner generates a substructure of all T's. Finally, the medical record owner sends the ciphertext M, E (M), the medical record identifier (Rid) and the medical record information (Obj) to be stored on the electronic medical record.
Data decryption
Assume that an external user wants to access a particular PHRobj stored in the HC. Um should first send an access request to the HC indicating PHRid and PHRobj corresponding to the PHR information required for access. The HC then extracts the corresponding T associated with the requested PHRobj and sends it back to Um.
Suppose that an external user (Um) wants to access specific medical record data stored in the chain. Um should first send an access request to the patient user on the chain indicating the medical record identification (Rid) and the medical record object (Obj) corresponding to the medical record information needed for access. The on-chain node then extracts the corresponding T associated with the requested Obj and sends it back to Um. AT for attribute set assumed to be owned by UmmAnd (4) showing. Um determines the attributes AT he owns to satisfy the received TmA minimal subset of. AT-basedm', Um generates the substructure T' and sends it to the patient user on the chain. The patient retrieves the corresponding ciphertext E 'from the received T' and sends it back to Um, causing Um to decrypt the encrypted data using the associated attribute secret key.
The decryption process is as follows: assume that the received ciphertext E' is composed of m attributes managed by 1 AAs. E ═ C (T', C)0,{C′i}i＝1,2...l,{C″i}i＝1,2...m)，C0,C′i,C″iThe definitions have been given before.
Further assume { Ski}i＝1,2...mIndicating Um for attribute subset ATm' owned dependent Attribute Key set, and
then refers to a set of keys that associate the identity of Um with 1 AA that publishes m attributes.
According to
And
wherein t isiRepresents the MK component defined by the AA managing the corresponding property. In order to decrypt the Um, the user may,
first of all, calculate
Then calculate
From the above two equations, we can derive:
therefore, M can be calculated by Um
The above-mentioned embodiments are only preferred embodiments of the present invention, and the scope of the present invention is not limited thereto, and any simple modifications or equivalent substitutions of the technical solutions that can be obviously obtained by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention.
Claims (7)
1. A block chain storage encryption method based on attribute encryption is characterized by comprising the following steps:
step 1, an external user requests to access data on a chain;
step 2, checking whether an external user meets the access condition or not through a medical record identifier and a medical record object set by an attribute encryption algorithm;
step 3, if not, access is refused; if the data are matched, the goal of accessing the data on the chain is achieved through the consensus algorithm SCA.
2. The method for encrypting the storage on the block chain based on the attribute encryption as claimed in claim 1, wherein the step 3 is executed by the process of executing the consensus algorithm SCA as follows:
step 3.1, judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, executing step 3.2;
step 3.2, executing a practical Byzantine fault-tolerant algorithm;
step 3.3, continuously judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, the master node is replaced and the step 3.2 is returned.
3. The method for encryption of storage on a blockchain based on attribute encryption according to claim 2, wherein the consensus algorithm SCA of step 2 comprises two stages in total.
4. The method for encryption of block chain storage based on attribute encryption according to claim 3, wherein the successful flow of the consensus algorithm SCA in the first stage is as follows:
(1) a Request stage: the client sends the request to a leader node in the service node, and the next stage is entered after the leader node passes the check request;
(2) and a Commit stage: the leader node numbers the request and forwards the numbered request to all the replica nodes, after receiving the request, the replica nodes directly carry out local processing on the request and obtain a processing result, then directly return the response signature to the client, and enter the next stage;
(3) a Reply stage: the client independently receives responses from all the service nodes, and if all the responses are the same, the consensus is considered to be achieved;
(4) the Response phase: the client needs to return the received responses with the signatures of the representative nodes to all the representative nodes, and the server checks that the responses are the same, so that the consensus at this stage is successful.
5. The method for encryption of storage on a blockchain based on attribute encryption according to claim 4, wherein the fault-tolerant flow analysis of the consensus algorithm SCA of the first stage is as follows:
(1) a Request stage: the leader node and the Replica nodes 1,2 and 3 are still the same as the successful process (1) and enter the next stage; at the moment, a Byzantine error occurs in the Replica4 node;
(2) and a Commit stage: the leader node and the Replica 1,2 and 3 have the same successful flow and enter the next stage; at this time, due to byzantine error, the order of processing requests by the Replica4 node may not coincide with that of Replica 1,2, 3:
(3) a Reply stage: the client independently receives the consistent responses from the leader node and the Replica nodes 1,2 and 3, but receives the inconsistent responses from the Replica4 node or receives no response from the Replica4 at all; therefore, the system cannot enter a Response stage in a successful flow, and after the timeout waiting, the client judges that the request is unsuccessful and tries to reinitiate the request;
(4) a sonic stage: if the client receives different response results from the server copy, the client sends the received different responses with the signatures of the representative nodes to all the representative nodes, and the representative nodes enter an Abort stage immediately after verifying that the responses are really inconsistent; or the server cannot receive error feedback of the client, so as to trigger a server overtime check mechanism;
(5) abort stage: all the representative nodes enter a rollback state, rollback the previous commit to the local processing result, and judge that the system in the current asynchronous network has a Byzantine error node; triggering the switching of the consensus algorithm, and switching the system to use a two-stage PBFT algorithm.
6. The method according to claim 5, wherein when the consensus algorithm SCA is not used in one stage, the system determines that Byzantine nodes exist in the asynchronous network, so the system switches to the two-stage consensus, which uses the PBFT practical Byzantine fault-tolerant algorithm, and the flow analysis of the two-stage PBFT consensus algorithm is as follows:
(1) the Reuqest phase: the client sends the request to a Leader node in the server;
(2) Pre-Prepare stage: the leader node forwards the request to all the replica nodes; in this stage, the replica node ensures that the master node leader does not send two messages with the same number but different contents;
(3) stage Prepare: all nodes sign the message and broadcast the prefix message to other nodes, and if the same node receives at least 2f +1 prefix messages from different nodes, the node enters a Commit stage; this stage is to get a consensus on a series of messages sent by the leader; determining which message of the leader is being agreed upon;
(4) and a Commit stage: all nodes broadcast commit messages, when 2f +1 commit messages including the nodes are received, enough nodes count the commit stage, namely, consensus is achieved;
(5) a Reply stage: the node returns the response of the request to the user, and when the user receives more than f +1 different responses, the request is confirmed to be successful.
7. The method of claim 1, wherein the attribute-based encryption algorithm comprises four steps, namely system initialization, key distribution, data encryption and data decryption.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010167045.3A CN111737340B (en) | 2020-03-11 | 2020-03-11 | Method for encrypting storage on blockchain based on attribute encryption |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010167045.3A CN111737340B (en) | 2020-03-11 | 2020-03-11 | Method for encrypting storage on blockchain based on attribute encryption |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111737340A true CN111737340A (en) | 2020-10-02 |
| CN111737340B CN111737340B (en) | 2024-04-02 |
Family
ID=72646376
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010167045.3A Active CN111737340B (en) | 2020-03-11 | 2020-03-11 | Method for encrypting storage on blockchain based on attribute encryption |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111737340B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112380179A (en) * | 2020-12-14 | 2021-02-19 | 河钢数字技术股份有限公司 | Block chain-based steel supply chain information secret sharing method and system |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018229867A1 (en) * | 2017-06-13 | 2018-12-20 | サスメド株式会社 | Personal information protection system |
| CN110569675A (en) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | Multi-Agent transaction information protection method based on block chain technology |
-
2020
- 2020-03-11 CN CN202010167045.3A patent/CN111737340B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018229867A1 (en) * | 2017-06-13 | 2018-12-20 | サスメド株式会社 | Personal information protection system |
| CN110569675A (en) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | Multi-Agent transaction information protection method based on block chain technology |
Non-Patent Citations (1)
| Title |
|---|
| 陈希凯;马来宾;程志刚;孔颖;: "基于联盟链的电子病历访问控制系统", 电子制作, no. 1 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112380179A (en) * | 2020-12-14 | 2021-02-19 | 河钢数字技术股份有限公司 | Block chain-based steel supply chain information secret sharing method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111737340B (en) | 2024-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Castiglione et al. | Hierarchical and shared access control | |
| CN103270516B (en) | System and method for securing virtual machine computing environments | |
| Kokoris Kogias et al. | Calypso: Private data management for decentralized ledgers | |
| CN109525570B (en) | Group client-oriented data layered security access control method | |
| CN109818757A (en) | Cloud storage data access control method, Attribute certificate awarding method and system | |
| Fan et al. | TraceChain: A blockchain‐based scheme to protect data confidentiality and traceability | |
| CN106452737A (en) | Systems and methods for secure multi-tenant data storage | |
| CN102907038A (en) | Attribute-based digital signature system | |
| US20040193872A1 (en) | System and method for renewing and extending digitally signed certificates | |
| Ibrahim et al. | A secure framework for sharing electronic health records over clouds | |
| Kan et al. | An identity-based proxy re-encryption for data deduplication in cloud | |
| Su et al. | Decentralized self-auditing scheme with errors localization for multi-cloud storage | |
| Wang et al. | Ciphertext-policy attribute-based encryption supporting policy-hiding and cloud auditing in smart health | |
| Brunner et al. | A Comparison of Blockchain-based PKI Implementations. | |
| Lin et al. | Multiple‐replica integrity auditing schemes for cloud data storage | |
| Xie et al. | A novel blockchain-based and proxy-oriented public audit scheme for low performance terminal devices | |
| Yan et al. | Traceable and weighted attribute-based encryption scheme in the cloud environment | |
| CN111737340B (en) | Method for encrypting storage on blockchain based on attribute encryption | |
| Sang et al. | Provable Multiple-Copy Integrity Auditing Scheme for Cloud-Based IoT | |
| Zhang et al. | Data security in cloud storage | |
| Ford | A public key infrastructure for us government unclassified but sensitive applications | |
| Cao et al. | An integrity verification scheme of completeness and zero‐knowledge for multi‐Cloud storage | |
| Camenisch et al. | (Un) linkable pseudonyms for governmental databases | |
| Mishra et al. | Privacy preserving file auditing schemes for cloud storage using verifiable random function | |
| Kroll et al. | Accountable cryptographic access control |
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 |