CN115118435B - Privacy data protection and authorization framework based on double-layer chain - Google Patents
Privacy data protection and authorization framework based on double-layer chain Download PDFInfo
- Publication number
- CN115118435B CN115118435B CN202210756058.3A CN202210756058A CN115118435B CN 115118435 B CN115118435 B CN 115118435B CN 202210756058 A CN202210756058 A CN 202210756058A CN 115118435 B CN115118435 B CN 115118435B
- Authority
- CN
- China
- Prior art keywords
- data
- node
- chain
- authorization
- leader
- 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
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 86
- 238000012795 verification Methods 0.000 claims abstract description 56
- 230000007246 mechanism Effects 0.000 claims abstract description 18
- 230000008901 benefit Effects 0.000 claims abstract description 10
- 238000003860 storage Methods 0.000 claims abstract description 10
- 238000000034 method Methods 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 18
- 238000011084 recovery Methods 0.000 claims description 13
- 238000012545 processing Methods 0.000 claims description 11
- 238000010200 validation analysis Methods 0.000 claims description 10
- 238000012423 maintenance Methods 0.000 claims description 7
- 230000005540 biological transmission Effects 0.000 claims description 3
- 238000013524 data verification Methods 0.000 claims description 2
- 239000003999 initiator Substances 0.000 claims description 2
- 230000006399 behavior Effects 0.000 claims 1
- 238000013500 data storage Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- 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
-
- 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/3236—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 using cryptographic hash functions
- H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
Abstract
The invention is a privacy data protection and authorization framework based on a double-layer chain, the framework adopts a double-layer chain structure, namely a verification chain and an authorization chain, the verification chain is responsible for verifying the authenticity and the validity of data, and meanwhile, a data possession certificate is generated; the authorization chain is responsible for storing authorization records of users, each user has own data account, and the users can only authorize own data; the nodes in the verification chain are equivalent to 'privileged' nodes in the authorization chain, and can add data to the data account of the user; authentication storage and authorization of data are performed separately. The privacy data protection adopts a double-chain structure, and a service provider can provide services without revealing specific data of the user. A consensus algorithm (PoB) based on proof of benefit is also proposed to adapt the current consensus mechanism to the framework.
Description
Technical Field
The invention belongs to the technical field of blockchains, and particularly relates to a privacy data protection and authorization framework based on a double-layer chain.
Background
With the rapid development of network technology, the protection of private data is receiving more and more attention, and in recent years, information is lost and privacy is revealed all over the world. Privacy data protection is becoming more and more important. At present, the mainstream data storage mode is centralized storage, and then the data is encrypted by an encryption technology, so that the data leakage can be effectively prevented. Thus, only passive disclosure can be avoided, so that many laws are dedicated to information protection, but the disclosure of private data is still serious, so that users are hard to forensic, and many people unscrupulously sell the private data, so that the privacy of the users is infringed.
The problem of centralized storage is solved in the appearance of the blockchain, and the blockchain is originally proposed by the Zhongben, is a novel application mode integrating technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm and the like, has the characteristics of non-falsification, traceability, decrustation and the like, is quite suitable for the field of privacy data protection, and provides safety guarantee for privacy data protection due to the decentric characteristic. However, due to the characteristics of the blockchain, the authenticity and the security of the data cannot be guaranteed by delivering the private data storage and the authorization to the blockchain, and the existing processing mode needs to send the data to a server, so that potential safety hazards exist, and as transactions in the blockchain are continuously increased, the blockchain nodes are also subjected to the storage pressure. In addition, the existing consensus mechanism and blockchain structure are generally used for virtual currency, but the processing speed is low when the existing consensus mechanism and blockchain structure are used in the field of private data storage, the system cannot be optimized, and a safer and faster protection and authorization framework needs to be provided for the private data storage.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a privacy data protection and authorization framework based on a double-layer chain. The privacy data protection adopts a double-chain structure, and a service provider can provide services without revealing specific data of the user. A consensus algorithm (PoB) based on proof of benefit is also proposed to adapt the current consensus mechanism to the framework.
The technical scheme for solving the technical problems is that a privacy data protection and authorization framework based on a double-layer chain is provided, and is characterized in that the framework adopts a double-layer chain structure, namely a verification chain and an authorization chain, wherein the verification chain is responsible for verifying the authenticity and the validity of data and generating a data possession certificate; the authorization chain is responsible for storing authorization records of users, each user has own data account, and the users can only authorize own data; the nodes in the verification chain are equivalent to 'privileged' nodes in the authorization chain, and data can be added to the data account of the user. The structure separates the verification, storage and authorization of the data, and can trace back through the authorization record in the verification chain when problems occur, so that the privacy data safety is ensured, and the rights and interests of both users and data requesters are ensured.
In order to ensure the security and the authenticity of the private data, the nodes in the verification chain are trusted third parties or authorities, so that the verification chain adopts the private chain, namely, only the consistency and the work efficiency and the stability of the system are required to be ensured, each node can verify the data by using an improved raft consensus algorithm, the data is stored in an IPFS, a user can check the data and ensure the traceability, and a data possession certificate is generated and sent to the account of the user in the authorization chain.
Since users on the authorization chain are not all trusted nodes, and the number of data requesters is not fixed, how to maintain the operation of the whole chain is the key of the authorization chain, the authorization chain adopts a public chain, no incentive mechanism is arranged on the public chain, and a block node is determined in N nodes by using a benefit-based consensus mechanism (PoB) and adopting verifiable random numbers (VRFs).
The specific contents of the benefit-based consensus mechanism (PoB) are: the more the number of the nodes with the authorization data is, the more trustable the nodes are, the nodes with the front N of the number of the authorization data are selected to maintain and operate the authorization chain, and the nodes only store the blocks related to the nodes.
The improved raft consensus algorithm comprises: deleting overtime elections and using sequence elections to perform leader elections, supporting a consensus process of simultaneously processing data by multiple nodes and fault processing and recovery;
the leader elects:
(1) Deleting the overtime election process in the Raft algorithm, selecting a leader by the nodes in sequence, and maintaining a node list together, wherein all the nodes are follower nodes except the leader;
(2) When the leader node fails, the current leader node is moved into a failure list, and the next node selects the leader to perform block out;
the consensus process:
(1) Each follower node can independently verify the authenticity of the data, generate a transaction list of the follower node, and send generated transaction information and the latest block number of the follower node to a leader;
(2) The leader receives the transaction information generated by each follower node and generates a new block, and meanwhile, the leader compares the latest block number of the leader with the block number of the new block generated by the leader according to the latest block number of the leader sent by each follower node, and if the latest block number of the leader sent by the follower node is smaller than the block number of the new block generated by the leader, the leader sends the block missing by the node to the corresponding follower node;
(3) The follower node receives the information sent by the leader and checks the transactions in the information, deletes the same transactions in the transaction list, and then continues to send the transaction information in the transaction list and the latest block number of the follower node to the leader so as to keep synchronization;
state maintenance:
(1) The consensus process comprises state maintenance, each message transmission represents a heartbeat signal, and the node automatically resets the timeout time;
(2) When all nodes (including a leader) are idle, the leader sends the latest block number, the follower node returns the latest block number of the follower node, and the leader sends the content of the next heartbeat signal according to the block number of the blockchain;
fault handling and recovery:
(1) When the leader fails, after the timeout time is over, the node updates the node list and sends unprocessed transaction information to the new leader;
(2) When the block number of the follower node is larger than that of the leader, the leader is taken as a standard, and the transaction of the block where the block number is located is resent to the leader;
(3) When the fault node requests to recover, the fault node sends recovery requests to other nodes, the other nodes check whether the fault node is the fault node, if so, the fault node is deleted from a fault list of each node, the fault node requesting to recover is added into the node list, and the node list is sent to the fault node requesting to recover.
The invention also protects a privacy data protection and authorization framework used in real-name authentication, and the framework adopts the privacy data protection and authorization framework based on the double-layer chain.
Compared with the prior art, the invention has the beneficial effects that:
1. better privacy. Because of the traditional private data storage and authorization scheme, original data are required to be presented during authorization, malicious collection cannot be avoided, in some cases, a server does not need to know specific data, and only a user is required to be proved to be a data owner.
2. Traceability. Although there is no specific data in the authorization chain, the authorization record can be traced back through the validation chain as evidence.
3. The verification chain adopts an improved RAFT consensus algorithm, and the algorithm deletes overtime elections and supports simultaneous processing of data by multiple nodes and recovery of fault nodes, so that the data processing speed and the leader election speed are improved.
4. The authorization chain adopts the framework to provide a common knowledge mechanism based on benefit, so that the reliable operation of the layer can be ensured, and in the mechanism, only N can participate in the block before the account authorization quantity, and the mechanism is not beneficial to the nodes when the authorization chain serves as malicious nodes, and the nodes only need to store blocks related to the nodes, so that the storage pressure of the nodes is reduced, and the layer has good safety and expandability.
5. The public chains such as bitcoin adopt a PoW consensus mechanism to determine the block node, so that a large amount of resource waste is caused, the frame authorization chain adopts VRFs (Verifiable Random Functions, verifiable random function) algorithm to select the block node, a large amount of computing resources can be saved, and the transaction processing speed is greatly improved.
Drawings
FIG. 1 is a schematic diagram of an election process of a verification chain leader.
FIG. 2 is a schematic diagram of a validation chain block structure.
FIG. 3 is a schematic diagram of a validation chain block architecture.
FIG. 4 is a block diagram of an authorization chain.
FIG. 5 is a block diagram of an authorization chain.
FIG. 6 is a schematic diagram of the steps of the framework.
Fig. 7 and 8 are schematic diagrams of verification chain state maintenance processes.
Fig. 9 is a schematic diagram of an authorization chain consensus process.
Detailed Description
Specific examples of the present invention are given below. The specific examples are only for further detailed description of the present invention and do not limit the scope of the present application.
The invention provides a privacy data protection and authorization framework (framework for short) based on a double-layer chain, which comprises the following contents:
(1) The framework is composed of two chains, a validation chain and an authorization chain, respectively.
(2) The validation chain is maintained and operated by n trusted nodes to receive and validate the user's authentic data, save the data to an IPFS (interstellar file system), save the address to the user's account in the validation chain and generate a unique data proof of possession to be stored in the user's account of the validation chain.
(3) The authorization chain is maintained and operated by the user and the data demander, where the user can authorize the data attestation to the data demander.
The working process of the privacy data protection and authorization framework based on the double-layer chain is as follows:
verification chain improved raft consensus algorithm:
1. leader election (as shown in fig. 1):
(1) And deleting the overtime election process in the Raft algorithm, wherein the nodes sequentially select the leader, and together maintain a node list, and all the nodes are follower nodes except the leader.
(2) When the leader node fails, the current leader node is moved into the fault list, the next node selects the leader to go out of the block, as shown in part (2) of fig. 1, the node 1 starts to be the leader, and when the node fails, the node 2 serves as a new leader, and the node 1 is moved into the fault list.
2. The consensus process:
(1) Each follower node can independently verify the authenticity of the data, generate a transaction list of the follower node, and send generated transaction information and the latest block number of the follower node to a leader. I.e. the follower node can interact with the user.
(2) The leader receives the transaction information generated by each follower node and generates a new block (the generated new block comprises a block number), meanwhile, the leader compares the latest block number of the leader sent by each follower node with the block number of the new block generated by the leader, and if the latest block number of the leader sent by the follower node is smaller than the block number of the new block generated by the leader, the leader sends the block missing by the node to the corresponding follower node.
(3) The follower node receives the information sent by the leader and checks the transactions therein, deletes the same transactions in the transaction list, and then continues to send the transaction information in the transaction list and the latest block number of the follower node to the leader so as to keep synchronization.
3. State maintenance:
(1) The consensus process involves a state maintenance, each message delivery indicating a "heartbeat" signal, and the node automatically resets the timeout.
(2) When all nodes (including the leader) are idle, the leader sends the latest block number, the follower node returns the latest block number of the follower node, and the leader sends the content of the next heartbeat signal according to the block number of the blockchain.
4. Fault handling and recovery:
(1) When the leader fails, after the timeout period expires, the node updates the node list and sends the unprocessed transaction information to the new leader.
(2) When the block number of the follower node is larger than that of the leader, the leader is used as a standard, and the transaction of the block where the block number is located is resent to the leader.
(3) When the fault node requests to recover, the fault node sends recovery requests to other nodes, the other nodes check whether the fault node is the fault node, if so, the fault node is deleted from a fault list of each node, the fault node requesting to recover is added into the node list, and the node list is sent to the fault node requesting to recover.
The structure of the blocks in the validation chain is shown in FIG. 2:
the block head of the verification chain is formed by PreHash, generateNode, time, tsum, merkleRoot, BNumber, wherein PreHash is the hash value of the previous block, the value in the generated block is 0, and the block is connected into a chain through the value, so that the previous block is prevented from being tampered; the GenerateNode is the address of the output block node; time is a Time stamp, and the block Time is recorded; tsum records data of transactions in the block; merkleRoot is the root node of a merkle tree in which the hash (H) of each transaction (Tx 1, tx 2.) is a leaf node, and the value of merkle root changes whenever there is one transaction; BNumber is a block number, a "heartbeat" signal that is a modified raft consensus algorithm, and the node does not have to query the length of the blockchain every time.
Structure of transactions in the validation chain:
zone block as shown in fig. 3, the transactions are data validation records, all of which constitute a data "ledger". H (PKu) is the address of the user account, binding the data to the user; the verifiation node represents a node for verifying data, and decrypts the data in the IPFS (interstellar file system) when tracing back and a user views the data; address is the data Address returned by IPFS; type is a data Type; h (data) is a hash value of the data, so that the uniqueness of the data is ensured, repeated verification of the data is avoided, and the data is also the balance (own information) in the user data account.
Consensus algorithm of authorization chain:
a benefit-based consensus mechanism (PoB) is proposed: since the authorization chain has no rewarding mechanism, the benefit is judged according to the quantity of the authorization quantity in the data account, and the quantity of the authorization quantity also determines whether the node is trusted. The method comprises the following steps:
(1) The node N before the number of grants is responsible for the blocking, and malicious nodes do not benefit from it because the grant chain has only data proof of possession.
(2) The N nodes use VRFs (verifiable random functions) to determine the block nodes.
The structure of the blocks in the authorization chain:
as shown in fig. 4, the block header of the authorization chain is formed by PreHash, generateNode, time, BNumber, merkleRoot, VRFsProve, and the pre hash is a hash value of the previous block header, and since not all nodes store all blocks, the value is a hash value of the block header, so that verification of the block chain is facilitated; the GenerateNode is the address of the output block node; time is a timestamp; BNumber is the block number; merkleRoot is the root node of the merkle tree; vrfssave is a proof of VRFs algorithm from which other nodes can verify the block node.
Structure of transactions in the authorization chain:
the block structure as shown in fig. 5 includes a plurality of transactions Tx1, …, txi, …, txn, where each transaction includes information Sender, receiver, type, dataProof, bind, validity, and the Sender is a transaction initiator, typically an authorizer or notary; the Receiver is a Receiver, typically a service provider or a user; type is a data Type; dataProof is a data proof, i.e. a proof signed by a notary to bind to a user (SigSKn (H (Address), H (PKu))); bind is an account or service or the like authorized to Bind; BNumber is the block number of the exchange, so that the exchange can be found conveniently and quickly; validity is the Validity of authorization, which is set to True when authorized, false when unauthorized, and valid when the transaction finally occurs.
Example 1
The embodiment is based on a double-layer chain privacy data protection and authorization framework, which is used in real-name authentication and comprises the following steps as shown in fig. 6.
Step 1 and step 2, the user (data owner) signs the data (data) using its own private key (SKu), and sends the signed data (SigSKu (data)) and its own public key (PKu) to the verification chain, if the verification passes, the verification result is returned.
Step 3 and step 4, after the verification chain receives the data, firstly verifying the signature, then verifying the data, verifying the data by adopting a manual or verification interface, if the verification is passed, encrypting the data (EnSKn (data)) by a node public key (PKn), storing the data in an IPFS, hashing a user public key to generate a user account Address (H (PKu)), and taking a storage Address (Address), a data hash value (H (data)), a verification node (verifiation node) and a data type (type) returned by the IPFS as transaction information. Wherein the hash value of the data can avoid repeated verification of the data; since the public key is used for encryption, in steps 10 and 11, the node for verifying the data can be quickly found according to the verification node for tracing, and responsibility can be traced after the data has a problem. If the verification is not passed, returning the failure reason to the user.
Step 5, each node of the verification chain is a notary, they sign the hash value (H (Address)) of the IPFS return Address and the user Address using the private key (SKn) as a data certificate (SigSKn (H (Address), H (PKu)), and use the data certificate and the data type as transaction information of the authorization chain. SigSKn denotes signing with a private key.
And 6, step 7, when the service provider needs the user to provide data certification, the service provider provides an account address, the user sends an authorized transaction to an authorization chain to authorize the data, and after the transaction verification is passed, an authorization result is returned. In this step, the user can only authorize the data which is signed by the notary node and in which the account address matches, otherwise the transaction request cannot be passed.
And 8, step 9, the transaction information comprises account information of a user on a service provider, after the user is authorized, the service provider checks whether the user is authorized by inquiring an authorized account, and if the transaction has a problem, the service provider can refuse to provide service.
And step 10, when the service provider finds that the user has the rule-breaking action, a traceability request is provided for the verification chain, and rule-breaking evidence and an authorization record are submitted.
And 11, checking authorization records and evidences by a verification chain, and manually intervening in follow-up operations such as responsibility tracking and the like.
Verification chain consensus process:
step 1: and the verification chain node receives the data of the user, performs verification and storage, generates corresponding transaction information, and then adds the corresponding transaction information into a transaction list.
Step 2: the follower nodes store the user address, the authentication node information, the data storage address, the data type, the authentication credentials (i.e. hashes of the data) as transaction information in a transaction list, as shown in fig. 7, the follower nodes 2, 3, 4 respectively contain 4, 5, 3 transactions, where Bn represents block numbers, tx represents transactions, and these transactions are sent to the leader node with the latest block number as a "heartbeat" signal.
Step 3: after receiving the transaction sent by the follower node, the leader node integrates the transaction, adds the transaction in the transaction list to the latest generated block (if the transaction is within the quantity limit) to generate a new block, compares the latest block number with the block numbers in the heartbeat signals of all the nodes, and sends corresponding blocks to all the follower nodes respectively.
Step 4: as shown in fig. 8, each follower node looks up the transactions in the blocks sent by the leader node, deletes the same transactions as the own transaction list, then adds the blocks sent by the leader node to the own chain of nodes, and continues to send the transaction information in the transaction list and the own latest block number to the leader, so that the leader and the follower nodes keep synchronous.
Verification of the link node failure recovery process:
case 1: when the leader node is down and the follower node still does not receive the signal of the leader node after the timeout time is set after sending the heartbeat signal, the follower node adds the first one of the node lists to the fault list and removes the current leader node from the node list, and the next node selects the leader.
Case 2: when the follower nodes are down, the leader node sets a timeout time for each follower node, if a certain node heartbeat signal is not received in the timeout time, the leader updates the node list, adds the follower node which does not receive the heartbeat signal to the fault list, then sends the latest node list and the heartbeat signal to other nodes in the node list, and the follower node updates the own node list after receiving the node list and adds the fault node to the fault list.
When the failed node recovers, the failed node broadcasts a recovery signal to all nodes in the node list (since the failed node recovers does not know who is the leader), after the leader receives the recovery signal, the node list is updated, the failed recovered node is added to the end of the node list, the failed recovered node is removed from the node list, and the next heartbeat signal is sent to other nodes and to a new failure list and node list.
The authorization chain consensus process, as shown in fig. 9:
step 1: the nodes with the authority of the front 4 broadcast each other to generate a VRF Hash output R through VRF_hash (SK, M), wherein SK is a private key of the node, M is a Hash value of the last block, and the node with the smallest R is responsible for generating the next block.
Step 2: the block-out node generates VRF Proof P through VRF_proof (SK, M) to be contained in the block head, then sends the newly generated block to other 3 nodes, the node receives the newly generated block, firstly verifies the validity of P through VRF_verify (PK, M, P), wherein PK is the public key of the block-out node, VRF_P2H (P) restores an R ', and verifies whether R and R' are equal to determine the validity of R.
Step 3: if the verification is passed, a hash H (block) of the new block is sent to other nodes, and if one node receives more than half of the hashes sent by the nodes, the block is determined to be legal.
Step 4: after determining that the block is legal, broadcasting a new block to the user node, and checking whether the transaction in the block is relevant to the user node, if so, storing the whole block, otherwise, only storing the block head.
The protection of the privacy data in the real-name authentication is completed through the process.
According to the invention, on the verification layer, an improved RAFT algorithm is adopted, a timeout election strategy is changed into a sequential election, single-node processing data is changed into common processing data of all nodes, and an automatic recovery mechanism of a fault node is increased, so that the data verification and storage are more efficient; and the Verifiable Random Function (VRFS) is used on the authorization layer to select the block-out node, so that fairness is ensured, and a large amount of calculation resource waste is reduced relative to a PoW algorithm.
The invention is applicable to the prior art where it is not described.
Claims (7)
1. A privacy data protection and authorization framework based on a double-layer chain is characterized in that the framework adopts a double-layer chain structure, namely a verification chain and an authorization chain, wherein the verification chain is responsible for verifying the authenticity and validity of data and generating a data possession certificate; the authorization chain is responsible for storing authorization records of users, each user has own data account, and the users can only authorize own data; the nodes in the verification chain are equivalent to 'privileged' nodes in the authorization chain, and can add data to the data account of the user; separate the authentication storage and authorization of the data; the frame comprises the following steps:
step 1 and step 2, the user signs the data by using the private key of the user, the signed data and the public key of the user are sent to a verification chain, and if the verification passes, a verification result is returned;
step 3 and step 4, after the verification chain receives the data, firstly verifying the signature, then verifying the data, verifying the data by adopting a manual or verification interface, if the verification is passed, encrypting the data through a node public key and storing the encrypted data into the IPFS, hashing a user public key to generate a user account address, and taking a storage address returned by the IPFS, a data hash value, a verification node and a data type as transaction information;
step 5, each node of the verification chain is a notary, the node private key is used for signing the hash value of the IPFS return address and the user address as data evidence, and the data evidence and the data type are used as transaction information of the authorization chain;
step 6 and step 7, when the service provider needs the user to provide data evidence, the service provider provides an account address, the user sends an authorized transaction to an authorization chain to authorize the data, and after the transaction verification is passed, an authorization result is returned; in the step, the user can only authorize the data which is signed by the notary node and the account address of the data accords with the account address, otherwise, the data cannot pass the transaction request;
step 8 and step 9, the transaction information contains account information of the user on the service provider, after the user authorizes, the service provider checks whether the user authorizes by inquiring an authorized account of an authorized chain, and if the transaction has a problem, the service provider can refuse to provide service;
step 10, when a service provider finds that a user has illegal behaviors, a tracing request is provided for a verification chain, and illegal evidences and authorization records are submitted;
and 11, checking the authorization record and the evidence by a verification chain, and performing subsequent operations.
2. The privacy data protection and authorization framework based on a double-layer chain according to claim 1, wherein nodes in the verification chain are trusted third parties or authorities, the verification chain adopts the private chain, namely only consistency and work efficiency and stability of a system are required to be ensured, each node can verify data by using an improved raft consensus algorithm, the data is stored in an IPFS, a user can check own data and ensure traceability, and a data possession certificate is generated and sent to an account of the user in the authorization chain;
because the users on the authorization chain are not all trusted nodes and the number of data requesters is not fixed, the authorization chain adopts a public chain, no incentive mechanism is arranged on the public chain, and the block nodes are determined from N nodes by using a benefit-based consensus mechanism PoB and adopting a verifiable random number VRFs.
3. The two-tier-based privacy data protection and authorization framework of claim 1, wherein the specific content of the benefit-based consensus mechanism PoB is: the more the number of the nodes with the authorization data is, the more trustable the nodes are, the nodes with the front N of the number of the authorization data are selected to maintain and operate the authorization chain, and the nodes only store the blocks related to the nodes.
4. The dual-link based privacy data protection and authorization framework of claim 2, wherein the modified raft consensus algorithm comprises: deleting overtime elections and using sequence elections to perform leader elections, supporting a consensus process of simultaneously processing data by multiple nodes and fault processing and recovery;
the leader elects:
(1) Deleting the overtime election process in the Raft algorithm, selecting a leader by the nodes in sequence, and maintaining a node list together, wherein all the nodes are follower nodes except the leader;
(2) When the leader node fails, the current leader node is moved into a failure list, and the next node selects the leader to perform block out;
the consensus process:
(1) Each follower node can independently verify the authenticity of the data, generate a transaction list of the follower node, and send generated transaction information and the latest block number of the follower node to a leader;
(2) The leader receives the transaction information generated by each follower node and generates a new block, and meanwhile, the leader compares the latest block number of the leader with the block number of the new block generated by the leader according to the latest block number of the leader sent by each follower node, and if the latest block number of the leader sent by the follower node is smaller than the block number of the new block generated by the leader, the leader sends the block missing by the node to the corresponding follower node;
(3) The follower node receives the information sent by the leader and checks the transactions in the information, deletes the same transactions in the transaction list, and then continues to send the transaction information in the transaction list and the latest block number of the follower node to the leader so as to keep synchronization;
state maintenance:
(1) The consensus process comprises state maintenance, each message transmission represents a heartbeat signal, and the node automatically resets the timeout time;
(2) When all nodes are idle, the leader sends the latest block number, the follower node returns the latest block number of the leader, and the leader sends the content of the next heartbeat signal according to the block number of the blockchain;
fault handling and recovery:
(1) When the leader fails, after the timeout time is over, the node updates the node list and sends unprocessed transaction information to the new leader;
(2) When the block number of the follower node is larger than that of the leader, the leader is taken as a standard, and the transaction of the block where the block number is located is resent to the leader;
(3) When the fault node requests to recover, the fault node sends recovery requests to other nodes, the other nodes check whether the fault node is the fault node, if so, the fault node is deleted from a fault list of each node, the fault node requesting to recover is added into the node list, and the node list is sent to the fault node requesting to recover.
5. The two-tier based privacy data protection and authorization framework of claim 4, wherein the chunk header of the verification chain consists of PreHash, generateNode, time, tsum, merkleRoot, BNumber, wherein PreHash is the hash value of the previous chunk, creating a value of 0 in the chunk, linking the chunks into a chain by this value, preventing the previous chunk from being tampered with; the GenerateNode is the address of the output block node; time is a Time stamp, and the block Time is recorded; tsum records data of transactions in the block; merkleroot is the root node of the merkle tree, the hash of each transaction in the merkle tree is a leaf node, and the value of the Merkle root is changed only if one transaction is changed; BNumber is the block number, which is the "heartbeat" signal of the improved raft consensus algorithm, and the node does not have to query the length of the blockchain every time;
structure of transactions in the validation chain: the transaction is a data verification record, all transactions form a data 'account book', and H (PKu) is the address of a user account, so that the data and the user are bound; the verifiation node represents a node for verifying the data, and decrypts the data in the IPFS when tracing back and the user views the data; address is the data Address returned by IPFS; type is a data Type; h (data) is a hash value of the data, so that the uniqueness of the data is ensured, repeated verification of the data is avoided, and the data is also the balance in the user data account.
6. The two-tier based privacy data protection and authorization framework of claim 2, wherein the chunk header of the authorization chain consists of PreHash, generateNode, time, BNumber, merkleRoot, VRFsProve, preHash is the hash value of the previous chunk header, and since not all nodes store all chunks, this value is the hash value of the chunk header, facilitating verification of the blockchain; the GenerateNode is the address of the output block node; time is a timestamp; BNumber is the block number; merkleRoot is the root node of the merkle tree; VRFsProve is the proof of VRFs algorithm, other nodes can verify the block node according to the proof;
structure of transactions in the authorization chain: the information of each transaction comprises Sender, receiver, type, dataProof, bind, validity, wherein the Sender is a transaction initiator and is an authorizer or notary; the Receiver is a Receiver and is a service provider or a user; type is a data Type; dateProof is a data proof, i.e., a proof signed by a notary to bind to a user (SigSKn (H (Address), H (PKu))); bind is an account or service that authorizes binding; BNumber is the block number of the exchange, so that the exchange can be found conveniently and quickly; validity is the Validity of authorization, which is set to True when authorized, false when unauthorized, and valid when the transaction finally occurs.
7. A privacy data protection and authorization framework for use in real name authentication, characterized in that the framework employs the privacy data protection and authorization framework based on a double-layer chain as claimed in any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210756058.3A CN115118435B (en) | 2022-06-29 | 2022-06-29 | Privacy data protection and authorization framework based on double-layer chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210756058.3A CN115118435B (en) | 2022-06-29 | 2022-06-29 | Privacy data protection and authorization framework based on double-layer chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115118435A CN115118435A (en) | 2022-09-27 |
| CN115118435B true CN115118435B (en) | 2024-03-22 |
Family
ID=83329819
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210756058.3A Active CN115118435B (en) | 2022-06-29 | 2022-06-29 | Privacy data protection and authorization framework based on double-layer chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115118435B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108875411A (en) * | 2018-07-11 | 2018-11-23 | 成都理工大学 | The storage of Intelligent bracelet data and sharing method based on block chain |
| WO2020016637A1 (en) * | 2018-07-20 | 2020-01-23 | Valencia Renato | Blockchain-enabled double entry recordkeeping system and method of implementing the same |
| WO2020189800A1 (en) * | 2019-03-15 | 2020-09-24 | 라인플러스 주식회사 | Method and system for authenticating data generated in blockchain |
| WO2021120253A1 (en) * | 2019-12-16 | 2021-06-24 | 郑杰骞 | Data storage method and verification method for blockchain structure, blockchain structure implementation method, blockchain-structured system, device, and medium |
| WO2022027531A1 (en) * | 2020-08-03 | 2022-02-10 | 西安电子科技大学 | Blockchain construction method and system, and storage medium, computer device and application |
-
2022
- 2022-06-29 CN CN202210756058.3A patent/CN115118435B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108875411A (en) * | 2018-07-11 | 2018-11-23 | 成都理工大学 | The storage of Intelligent bracelet data and sharing method based on block chain |
| WO2020016637A1 (en) * | 2018-07-20 | 2020-01-23 | Valencia Renato | Blockchain-enabled double entry recordkeeping system and method of implementing the same |
| WO2020189800A1 (en) * | 2019-03-15 | 2020-09-24 | 라인플러스 주식회사 | Method and system for authenticating data generated in blockchain |
| WO2021120253A1 (en) * | 2019-12-16 | 2021-06-24 | 郑杰骞 | Data storage method and verification method for blockchain structure, blockchain structure implementation method, blockchain-structured system, device, and medium |
| WO2022027531A1 (en) * | 2020-08-03 | 2022-02-10 | 西安电子科技大学 | Blockchain construction method and system, and storage medium, computer device and application |
Non-Patent Citations (1)
| Title |
|---|
| 基于区块链的安全通讯与隐私数据共享机制;罗得寸;硕士电子期刊;20220215(第2022年第02期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115118435A (en) | 2022-09-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109766673B (en) | Alliance type audio and video copyright block chain system and audio and video copyright chaining method | |
| CN109360100B (en) | Transaction rapid confirmation method and device based on block chain technology | |
| CN107682308B (en) | Electronic evidence preservation system based on block chain latent channel technology | |
| CN108648084B (en) | Data processing method, device and equipment of block chain network and storage medium | |
| US20180349572A1 (en) | Copyright authorization management method and system | |
| CN106910051B (en) | DNS resource record notarization method and system based on alliance chain | |
| CN102722931B (en) | Voting system and voting method based on intelligent mobile communication devices | |
| CN115210741B (en) | Partially ordered blockchain | |
| WO2021018088A1 (en) | Trusted authentication method, network device, system and storage medium | |
| CN110177124B (en) | Identity authentication method based on block chain and related equipment | |
| CN109547218B (en) | Alliance link node key distribution and backup system for improving BIP (building information processing) protocol | |
| CN112861172B (en) | Symmetric searchable encryption method based on PBFT (public domain representation) consensus mechanism | |
| US20220020008A1 (en) | Smart Contract-Based Electronic Contract Preservation System | |
| CN114139203B (en) | Block chain-based heterogeneous identity alliance risk assessment system and method and terminal | |
| CN111815321A (en) | Transaction proposal processing method, device, system, storage medium and electronic device | |
| CN113255014B (en) | Data processing method based on block chain and related equipment | |
| CN112184442A (en) | Criminal case evidence circulation record management method and system based on block chain | |
| CN111899019A (en) | Method and system for cross validation and sharing of blacklist and multiple parties | |
| CN108923928B (en) | Digital certificate revocation system and method based on block chain | |
| CN112035895A (en) | Electronic contract evidence obtaining method and system based on transaction mode | |
| CN112202809A (en) | Block chain link point checking method | |
| CN109918451B (en) | Database management method and system based on block chain | |
| CN112039837B (en) | Electronic evidence preservation method based on block chain and secret sharing | |
| CN113935065A (en) | Ring signature-based federation chain identity privacy protection and supervision method | |
| CN111768189B (en) | Charging pile operation method, device and system based on block chain |
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 |