CN111737340B - Method for encrypting storage on blockchain based on attribute encryption - Google Patents

Abstract

The invention provides a storage encryption method on a blockchain 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 accords with access conditions or not through a medical record identifier and a medical record object set by an attribute encryption algorithm; step 3, refusing access if the access is not met; if so, the purpose of accessing the data on the chain is achieved through a consensus algorithm SCA. The method combines attribute encryption by using a blockchain technology to protect the data on the chain, namely the doctor-patient data of the patient, so that safe sharing of the electronic medical record is realized; the block chain has natural advantages for privacy protection, and the invention combines the technologies of cryptography, computer networks, asynchronous Bayesian fault tolerance and the like, optimizes a consensus mechanism in the chain, and designs and realizes a alliance chain with low delay and certain throughput.

Description

Method for encrypting storage on blockchain based on attribute encryption

Technical Field

The invention belongs to the technical field of data encryption, and particularly relates to a storage encryption method on a blockchain based on attribute encryption.

Background

The importance of medical data of patients is self-evident nowadays. However, medical data of different hospitals cannot be shared, resulting in some medical lag. Therefore, people realize the sharing of medical data through the sharing of the electronic medical records, but the sharing of the electronic medical records has the problems of safety, privacy protection and the like to a certain extent, and the encryption of the data can solve the problems to a certain extent.

The blockchain has great advantages in protecting the privacy information of patients because of high redundancy, distributed storage, incapability of tampering and management of multiple signature complex authorities, and can greatly simplify the storage of records and improve the safety. The blockchain consists of invariable data records (data blocks), medical data are stored on the blocks, and the data are connected in a cryptography mode, so that the safety of the data is ensured. At the same time, the data on the blockchain is public, and the non-falsification of the data is ensured through the time stamp.

Attribute encryption (ABE) is a new one-to-many encryption mode, the essence of which is that access control to encrypted data is achieved by attribute defining the identity of a user and thus introducing an access control structure defined by the attribute. The algorithm core of attribute encryption is to embed the attributes/policies into the key/secret. The ABE scheme is classified into key policy based attribute encryption (KP-ABE) and ciphertext policy based attribute encryption (CP-ABE) according to embedded objects.

In the prior art, xueshifei et al propose an electronic medical information sharing model based on block chains, so that the problem that medical information of each unit is not shared timely is solved to a certain extent; azaria Z proposed to build a medical system through a blockchain that sets permissions for the acquisition of medical data; the Xia Q addresses privacy leakage issues that may occur when medical data is shared through blockchain in a weakly trusted hosting environment.

In the case of encrypting an electronic medical record using attribute encryption, ibrami proposes a patient-centric approach, where a Trusted Authority (TA) is responsible for managing attributes in the public domain, and the owner of the medical record itself acts as a TA in the personal domain to publish attributes associated with the personal domain. Thus, the medical record owner can encrypt the key, allowing only users with attributes that satisfy the relevant access structure to successfully decrypt.

Most of the prior art schemes are working modes of workload mechanisms of public chains in block chains, data are transmitted on the public chains, the situation that the data cannot be updated in time exists, and the time of one transaction is far longer than that of a alliance chain 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 to conduct transactions. 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, considering the fact that the TA has access to all encrypted files, and at the same time may lead to key escrow problems.

In the existing common-link consensus algorithm, such as the consensus algorithm (POW) based on workload demonstration, only ten-thousand-level full-node data synchronization is realized and efficiency problems exist due to the fact that a large amount of resources are wasted and a high-amount excitation mechanism is relied on. The efficiency of the Bayesian and the busy-tolerant algorithm (BFT) based on message passing used by the existing alliance chain is higher than that of the POW, but the fault tolerance can only be realized between the nodes with the order of hundreds, and the defect of small number of fault-tolerant nodes is overcome.

Accordingly, the present application provides a method of encryption of storage on a blockchain based on attribute encryption.

Disclosure of Invention

In order to overcome the defects in the prior art, the invention provides a block chain on-storage encryption method based on attribute encryption.

In order to achieve the above object, the present invention provides the following technical solutions:

a block chain on-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 accords with access conditions or not through a medical record identifier and a medical record object set by an attribute encryption algorithm;

step 3, refusing access if the access is not met; if so, the purpose of accessing the data on the chain is achieved through a consensus algorithm SCA.

Preferably, in the step 3, the process of executing the consensus algorithm SCA is:

step 3.1, judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, executing the step 3.2;

step 3.2, executing a practical Bayesian 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 main 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 success flow of the consensus algorithm SCA of the first stage is as follows:

(1) Request phase: the client sends the request to a leader node in the service nodes, and after the leader node passes the verification request, the next stage is entered;

(2) Commit phase: the leader node numbers the request and forwards the request after the numbering to all the duplicate nodes, the duplicate nodes directly process the request locally and obtain a processing result after receiving the request, and then the response signature is directly returned to the client to enter the next stage;

(3) Stage Reply: the client independently receives the responses from all the service nodes, and if all the responses are the same, the consensus is considered to be achieved;

(4) Response phase: the client needs to return the received responses with the signature of the representative nodes to all the representative nodes together, 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) Request phase: the leader node and the Reqlica nodes 1, 2 and 3 still share the successful flow (1) and enter the next stage; at this time, the Replica4 node generates a Bayesian error;

(2) Commit phase: the leader node and the Replica1, 2 and 3 succeed in the same flow, and enter the next stage; at this time, the Replica4 node may not be consistent with Replica1, 2, 3 in the order of processing the requests due to the bartholinitis error;

(3) Stage Reply: the client independently receives the consistent responses from the leader node and Replica nodes 1, 2, 3, but receives the inconsistent responses from Replica4 node or does not receive the response from Replica4 at all; the system cannot enter a Response stage in a success flow, and after timeout waiting, the client judges that the request is unsuccessful and tries to reinitiate the request;

(4) Panic stage: if the client receives different response results from the server copies, the client sends the received different responses with the signature of the representative node to all the representative nodes, and the representative nodes immediately enter an Abort stage after verifying that the responses are inconsistent; or the server cannot receive error feedback of the client, so that a timeout checking mechanism of the server is triggered;

(5) Abort stage: all representative nodes enter a rollback state, rollback the processing results from the previous commit to the local, and judging that a Bayesian error node exists in the system in the current asynchronous network; triggering the switching of the consensus algorithm, and switching the system to a two-stage PBFT algorithm.

Preferably, when the SCA is unable to reach a consensus in one stage, the system judges that a Bayesian node exists in the asynchronous network, so the system switches to a two-stage consensus, wherein the two-stage consensus uses a PBFT practical Bayesian 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-preparation stage: the Leader node forwards the request to all the duplicate nodes; in this stage, the duplicate node ensures that the master node Leader will not send two messages with the same number but different contents;

(3) Preparation stage: all nodes sign messages and broadcast preparation messages to other nodes, and if the same node receives at least 2f+1 preparation messages from different nodes, the common stage is entered; this stage is to agree on a series of messages sent by the leader; determining which message of the leader is agreed upon;

(4) Commit phase: all nodes broadcast a commit message, and when a total 2f+1 commit messages including themselves are received, it is represented that enough nodes count into the commit phase, i.e. consensus has been achieved;

(5) Stage Reply: the node returns the requested response to the user, and when the user receives more than f+1 different responses, the success of the request is confirmed.

Preferably, the attribute encryption algorithm is divided into four steps, namely system initialization, key distribution, data encryption and data decryption.

The block chain on-storage encryption method based on attribute encryption has the following beneficial effects:

(1) According to the invention, the block chain technology is combined with attribute encryption to protect the data on the chain, namely the doctor-patient data of the patient, so that the safe sharing of the electronic medical record is realized;

(2) The block chain has natural advantages for privacy protection, and the invention combines the technologies of cryptography, computer networks, asynchronous Bayesian fault tolerance and the like, optimizes a consensus mechanism in the chain, and designs and realizes a alliance chain with low delay and certain throughput;

(3) The invention provides a new hierarchical consensus algorithm dsBFT, which can have larger throughput and lower delay than the existing consensus algorithm when the network robustness is better, and can realize that when the number of Bayesian nodes in a system is less than one third of the total number of nodes in the system, the system can obtain the actual asynchronous Bayesian fault tolerance capability by reducing the throughput and increasing the delay;

(4) According to the invention, by applying attribute encryption on the blockchain, an effective attribute encryption algorithm is developed, access conditions to the data on the chain are limited, fine-granularity access control is achieved, and irrelevant visitors are prevented for patient medical record data, so that patient privacy is protected.

Drawings

FIG. 1 is a flow chart of a method for encryption of storage on a blockchain based on attribute encryption in accordance with embodiment 1 of the present invention;

FIG. 2 is a flow chart of an implementation of the consensus algorithm SCA;

FIG. 3 is a flowchart of a successful flow analysis of the consensus algorithm SCA of the first stage;

FIG. 4 is a fault-tolerant flow analysis chart of the consensus algorithm SCA of the first stage;

FIG. 5 is a flow chart of a two-stage PBFT consensus algorithm.

Detailed Description

The present invention will be described in detail below with reference to the drawings and the embodiments, so that those skilled in the art can better understand the technical scheme of the present invention and can implement the same. The following examples are only for more clearly illustrating the technical aspects of the present invention, and are not intended to limit the scope of the present invention.

Example 1

The invention provides a storage encryption method based on attribute encryption on a blockchain, which is specifically shown in fig. 1 and comprises the following steps:

step 1, an external user requests to access data on a chain;

step 2, checking whether an external user accords with access conditions or not through a medical record identifier and a medical record object set by an attribute encryption algorithm;

step 3, refusing access if the access is not met; if so, the purpose of accessing the data on the chain is achieved through a consensus algorithm SCA.

Further, as shown in fig. 2, in step 3, the process of executing the consensus algorithm SCA is:

step 3.1, judging whether consensus is achieved; if yes, returning to the main node to wait for a user request; otherwise, executing the step 3.2;

step 3.2, executing a practical Bayesian 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 main node is replaced, and the step 3.2 is returned.

Further, the consensus algorithm selection process of the present embodiment is as follows:

the SCA algorithm in the first stage is used in the scene that the network robustness is assumed to be good, the Bayesian node does not appear in the system, the consensus can be successfully and rapidly achieved when the assumption is satisfied, and the failure of the consensus can be found when the consensus is not achieved.

The successful flow of the first stage SCA consensus algorithm is as follows in FIG. 3, with the flow analysis as follows:

(1) Request phase: the client sends the request to a leader node in the service nodes, and after the leader node passes the verification request, the next stage is entered.

(2) Commit phase: the leader node numbers the request and forwards the request after the numbering to all the duplicate nodes, the duplicate nodes directly process the request locally and obtain a processing result after receiving the request, and then the response signature is directly returned to the client. The next stage is entered.

(3) Stage Reply: the client receives responses from all the service nodes independently, and considers consensus to be achieved if all the responses are the same.

(4) Response phase: the client needs to return the received responses with the signature of the representative nodes to all the representative nodes together, and the server checks that the responses are the same, so that the consensus at this stage is successful.

The fault-tolerant flow analysis of the SCA consensus algorithm in the first stage is as follows, and Replica0 in fig. 4 is a leader node of the round of consensus, and a duplex 3 node has a bayer error.

(1) Request phase: the leader node and Replica nodes 1, 2, 3 still go to the next stage as in the successful flow (1) above. At this point the Replica4 node is in a bayer error.

(2) Commit phase: the leader node and the Replica1, 2 and 3 have the same successful flow and enter the next stage. At this time, the Replica4 node may not process the requests in the same order as Replica1, 2, 3 due to the bartholinitis.

(3) Stage Reply: the client receives the consistent responses from the leader node and Replica nodes 1, 2, 3 independently, but receives the inconsistent responses from Replica4 node or does not receive the response from Replica4 at all. Therefore, the system cannot enter a Response stage in a success flow, and after timeout waiting, the client judges that the request is unsuccessful and tries to reinitiate the request.

(4) Panic stage: if the client receives different response results from the server copies, the client sends the received different responses with the signature of the representative node to all the representative nodes, and the representative nodes immediately enter the Abort stage after verifying that the responses do not coincide. Or the server cannot receive error feedback of the client, so that a timeout checking mechanism of the server is triggered.

(5) Abort stage: all representative nodes enter a rollback state, rollback the processing results from the previous commit to the local, and determine that a system in the current asynchronous network has a Bayesian error node. Triggering the switching of the consensus algorithm, and switching the system to a two-stage PBFT algorithm.

When the consensus algorithm cannot be achieved by using the efficient consensus algorithm at one stage, the system judges that the Bayesian node exists in the asynchronous network, so the system is switched to the two-stage consensus. The PBFT practical Bayesian fault tolerance algorithm is used in the two-stage consensus. The main flow of the two-stage PBFT consensus algorithm is as follows in fig. 5:

replica0 in fig. 5 is a leader node commonly known in the art, and rcplica3 node has a bartholinitis error.

(1) The Reuqest phase: the client sends the request to the Leader node in the server.

(2) Pre-preparation stage: the leader node forwards the request to all of the replica nodes. In this stage, the duplicate node ensures that the master node leader does not send two messages with the same number, but different content.

(3) Preparation stage: all nodes sign messages and broadcast the preparation message to other nodes, and if the same node receives at least 2f+1 preparation messages from different nodes, the common stage is entered. This stage is to agree on a series of messages sent by the leader. The determination is made as to which message of the leader is agreed upon.

(4) Commit phase: all nodes broadcast a commit message, and when a total of 2f+1 commit messages including themselves are received, it is representative that enough nodes have counted into the commit phase, i.e. consensus has been reached.

(5) Stage Reply: the node returns the requested response to the user, and when the user receives more than f+1 different responses, the success of the request is confirmed.

In this embodiment, the attribute encryption algorithm includes four steps, namely system initialization, key distribution, data encryption and data decryption.

Safety requirements: 1. confidentiality of user data: the patient's medical data must be kept secret from unauthorized parties. 2. Patient-centric access control: patient users should have full control of the outsourced health data so that they determine who is eligible to access them. 3. Rejection of attribute collusion: multiple users should not be able to share their attributes and decrypt medical data.

Scheme overview: the system is composed of a plurality of distributed public Attribute Authorities (AA). Each attribute authority manages a set of disjoint attributes and publishes attributes for users belonging to a public domain. In addition, the patient acts as a private attribute authority to provide attributes specifying personal relationships, such as the family of personal domain users. During system initialization, each AA first defines a set of secret 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 AA can run independently without any global coordination. The PHR user may obtain attributes from the relevant AA by providing evidence that the requested attributes are eligible for use. If the AA responsible for the requested attribute is satisfied in terms of its qualification as determined by the user requesting the attribute, the AA will issue the relevant key for the user.

The specific implementation is as follows:

initializing a system: to initialize the system, a set of global common parameters is first set, shared among all the AA.

Two multiplicative cyclic groups G0, G1 of prime numbers p, where G is the generator of G0 and bilinear map e: g0×g0→g1 and secure hash function H:mapping each user identification string to +.>Is a unique value of (a). The user identity should be a unique identifier for a given user, such as an email address. The AA then issues a global common parameter set (G0, G1, H, e, G, p). Thus, any new AA can be globally initialized by taking a global set of parameters shared by existing AA. Each AA (including the patient) is then locally initialized, and the initialization process is described below. Suppose the kth AA is AA _k Represented by AA _k Managed attribute set AT ^k And (3) representing.

1、AA _k Selecting two random indicesAnd calculate +.>Then is AT ^k Each element i in (a) selects a unique random identifier T _k ，/>Furthermore, by AA _k Each attribute managed is also associated with a common attribute index T _k，i Related, wherein->

2、AA _k Will keep { a } _k ，β _k ，T _k ，i}，i＝1，2...AT ^k As Master Key (MK) _k ) And issue { X ] _k ，Y _k ，T _k ，i}，i＝1，2...AT ^k As a result of PK ^k The public key of the representative authority.

Key distribution

Suppose user U _m To obtain the attribute AT _m Attribute keys of a collection. In addition, assume thatIndicating that the reaction should be from AA _k AT acquired in (a) _m Is a subset of the attributes of the (b). Suppose AA _k The user's credentials have been verified to determine the requested attributes. The process of attribute key distribution is as follows:

AA _k first U is first set using a secure hash function H _m Mapping identity of (using email address as user identity) to unique identifierThen, a key is generated for each request attribute, and the key set is used +.>The representation is made of a combination of a first and a second color,wherein->Wherein t is _k I is AA _k Defined by/>MK component of the i-th attribute of (a). Note that the key component +.>User identity and issuer AA _k Is associated with the identity of the key componentAssociating the user identity with the attribute itself so that the generated keyset has been securely transmitted to the U _m 。

Data encryption

Suppose that the patient wants to encrypt medical record data M εG1, which includes information about his allergies. First, he generates an access structure T and derives a set of access substructures { T ] _k } _{k＝1，2...q} Thus, the ciphertext of M encoded with T is given by E (M), E (M) = (T, { E) _k } _{k＝1，2...q} Wherein E is _k Access substructures T for representation _k Ciphertext of the encoded M. Calculation E will be described below _k Is a process of (2).

Let k-th substructure T _k Contains m attributes and they are managed by 1 AA, 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 component C ₀ Representing ciphertext E _k ，{C′ _i } _{i＝1，2...l} In addition, { C } " _i } _{i＝1，2...m} So that E _k ＝(T _k ，C ₀ ，{C′ _i } _{i＝1，2...l} ，{C″ _i } _{i＝1，2...m} )，E _k The ciphertext component is calculated as follows. The medical record owner first generates a random indexAnd using the public key of the/AAs he calculates the ciphertext component C ₀ And { C' _i } _{i＝1，2...l} Make->

To calculate C _i According to the following steps of T _k Each attribute of (a) allocates a secret share of s. For T _k Each attribute except the last one hasAnd the last element is assigned a value +.>Then, the medical record owner calculates { C } " _i } _{i＝1，2...m} Thus, a->Wherein T is _i Corresponding to T _k Common attribute index of the i-th attribute of (a).

Likewise, the medical record owner generates all T substructures. Finally, the medical record owner sends the ciphertext M, E (M) and the medical record identification (Rid) and medical record information (Obj) to be stored on his electronic medical record.

Data decryption

Suppose an external user is to access a particular PHRobj stored in the HC. Um should first send an access request to HC indicating PHR id and PHR obj corresponding to PHR information required for access. The HC then extracts the corresponding T associated with the requested PHRobj and sends it back to Um.

It is assumed that an external user (Um) is to access specific medical record data stored in the chain. Um should first send an access request to the in-chain patient user indicating a medical record identifier (Rid) and a medical record object (Obj) corresponding to the medical record information required for access. The on-chain node then extracts the corresponding T associated with the requested Obj and sends it back to Um. Suppose Um owns the AT for the attribute set _m And (3) representing. Um determines the attribute AT 'he has to satisfy the received T' _m Is a minimum subset of (a). Based on AT' _m Um generates a substructure T' and sends it to the on-chain patient user. The patient retrieves the corresponding ciphertext E 'from the received T' and sends it back to Um, thereby causing Um to decrypt the encrypted data using the associated attribute secret key。

The decryption process is as follows: suppose that the received ciphertext E' consists of m attributes managed by 1 AAs. E '= (T', C ₀ ，{C′ _i } _i＝1，2..l ′{C″ _i } _{i＝1，2...m} }，C ₀ ，C′ _i ，C″ _i The definition has been given before.

Further assume { sk } _i } _{i＝1，2...m} Representing Um for attribute subset AT' _m Owned set of related attribute keysThen it refers to a set of keys that associate Um's identity with 1 AA issuing m attributes.

According toAnd->Wherein t is _i Represents the MK component defined by the AA that manages the corresponding attribute. In order to decrypt the Um,

first calculate

Then calculate

From the two formulas above, it can be derived:

thus, M can be calculated from Um

The above embodiments are merely preferred embodiments of the present invention, the protection scope of the present invention is not limited thereto, and any simple changes or equivalent substitutions of technical solutions that can be obviously obtained by those skilled in the art within the technical scope of the present invention disclosed in the present invention belong to the protection scope of the present invention.

Claims (2)

1. The encryption method for the storage on the blockchain based on attribute encryption is characterized by comprising the following steps of:

step 1, an external user requests to access data on a chain;

step 2, checking whether an external user accords with access conditions or not through a medical record identifier and a medical record object set by an attribute encryption algorithm;

step 3, refusing access if the access is not met; if the data is in accordance with the data, the purpose of accessing the data on the chain is achieved through a consensus algorithm SCA;

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 the step 3.2;

step 3.2, executing a practical Bayesian 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, replacing the main node, and returning to the step 3.2;

the consensus algorithm SCA of the step 2 comprises two stages;

the successful flow of the consensus algorithm SCA in the first stage is as follows:

(1) Request phase: the client sends the request to a leader node in the service nodes, and after the leader node passes the verification request, the next stage is entered;

(2) Commit phase: the leader node numbers the request and forwards the request after the numbering to all the duplicate nodes, the duplicate nodes directly process the request locally and obtain a processing result after receiving the request, and then the response signature is directly returned to the client to enter the next stage;

(3) Stage Reply: the client independently receives the responses from all the service nodes, and if all the responses are the same, the consensus is considered to be achieved;

(4) Response phase: the client needs to return the received responses with the signature of the representative nodes to all the representative nodes together, and the server checks that the responses are the same, so that the consensus at this stage is successful;

the fault-tolerant flow analysis of the consensus algorithm SCA in the first stage is as follows:

(1) Request phase: the leader node and the Replica nodes 1, 2 and 3 still share the successful flow (1) and enter the next stage; at this time, the Replica4 node generates a Bayesian error;

(2) Commit phase: the leader node and the Replica1, 2 and 3 succeed in the same flow, and enter the next stage; at this time, the Replica4 node may not be consistent with Replica1, 2, 3 in the order of processing the requests due to the bartholinitis error;

(3) Stage Reply: the client independently receives the consistent responses from the leader node and Replica nodes 1, 2, 3, but receives the inconsistent responses from Replica4 node or does not receive the response from Replica4 at all; the system cannot enter a Response stage in a success flow, and after timeout waiting, the client judges that the request is unsuccessful and tries to reinitiate the request;

(4) Panic stage: if the client receives different response results from the server copies, the client sends the received different responses with the signature of the representative node to all the representative nodes, and the representative nodes immediately enter an Abort stage after verifying that the responses are inconsistent; or the server cannot receive error feedback of the client, so that a timeout checking mechanism of the server is triggered;

(5) Abort stage: all representative nodes enter a rollback state, rollback the processing results from the previous commit to the local, and judging that a Bayesian error node exists in the system in the current asynchronous network; triggering the switching of the consensus algorithm, and switching the system to a two-stage PBFT algorithm;

when the SCA can not reach the consensus in one stage, the system judges that the Bayesian node exists in the asynchronous network, so the system is switched to the two-stage consensus, the PBFT practical Bayesian fault-tolerant algorithm is used in the two-stage consensus, and the flow analysis of the PBFT consensus algorithm in two stages is as follows:

(1) The Reuqest phase: the client sends the request to a Leader node in the server;

(2) Pre-preparation stage: the leader node forwards the request to all the duplicate nodes; in this stage, the duplicate node ensures that the master node leader will not send two messages with the same number but different content;

(3) Preparation stage: all nodes sign messages and broadcast preparation messages to other nodes, and if the same node receives at least 2f+1 preparation messages from different nodes, the common stage is entered; this stage is to agree on a series of messages sent by the leader; determining which message of the leader is agreed upon;

(4) Commit phase: all nodes broadcast a commit message, and when a total 2f+1 commit messages including themselves are received, it is represented that enough nodes count into the commit phase, i.e. consensus has been achieved;

(5) Stage Reply: the node returns the requested response to the user, and when the user receives more than f+1 different responses, the success of the request is confirmed.

2. The method for encrypting the blockchain storage according to claim 1, wherein the attribute encryption algorithm is divided into four steps, namely system initialization, key distribution, data encryption and data decryption.