CN115189882B - Block chain-based distributed identity authentication method in crowd sensing - Google Patents

Abstract

The present invention discloses a distributed identity authentication method based on blockchain in crowd sensing. In the crowd sensing system, participants are divided into ordinary nodes and cluster head nodes, ordinary nodes are arranged on a private blockchain for authentication, and cluster head nodes are deployed on a public blockchain for authentication; wherein zero-knowledge proof is used to authenticate the participants. The advantages of the present invention are that after the crowd sensing network is divided into a private blockchain and a public blockchain and ordinary users and cluster head node users are registered on them respectively, the authentication of ordinary users and cluster head node users is realized by zero-knowledge proof, thereby realizing privacy protection and reliable authentication of device identity authentication in crowd sensing.

Description

A distributed identity authentication method based on blockchain in crowd sensing

Technical Field

The present invention relates to the field of blockchain technology (a combination of private chain and public chain) and crowd perception, and in particular to an identity authentication method based on zero-knowledge proof of blockchain in crowd perception.

Background technique

Crowd-sensing mainly collects data from sensors in a universal way through various smart devices (such as smartphones, music players, tablets, wearable devices, and vehicle-mounted sensors) and directs the data to specific MCS servers, thereby contributing to the Internet of Things (IoT) ecosystem. At present, MCS has been applied to many fields of smart cities. For example, various sensors in smartphones (such as satellite navigation, microphones, cameras, light sensors, accelerometers, compasses, and gyroscopes) are used to sense urban temperature, noise environment monitoring, social group behavior analysis, and health status monitoring. Vehicles in intelligent transportation systems are also equipped with many sensors and wireless devices, including cameras, GPS, lateral acceleration sensors, and vehicle-mounted devices, which are used to sense urban congestion, car arrival time, available parking spaces, etc., bringing great convenience to people's lives. From a broad application perspective, the application scenarios of MCS mainly include environmental monitoring, provision of public basic services, and social perception.

Crowd perception has brought great convenience to people's lives. However, due to the reliance on centralized servers for task release and perception data collection, traditional crowd perception systems are subject to threats such as single point failure. Blockchain, as a new type of distributed system technology, conforms to the distributed characteristics of crowd perception and provides a new method for solving security issues in crowd perception. However, crowd perception security and blockchain are still in the exploratory stage, and existing blockchain-based methods still have many problems.

In the current research on crowd-sensing security, the relevant work of blockchain mainly includes crowd-sensing system architecture, incentive mechanism and privacy protection. The research on the crowd-sensing system architecture based on blockchain mainly focuses on the distribution characteristics of participants in crowd-sensing and how they can better adapt to the topological structure of blockchain, so as to achieve the unification of the logical structure of the two and enable blockchain to better serve the security of crowd-sensing. The research on the incentive mechanism based on blockchain mainly considers how to use the distributed characteristics to mobilize the enthusiasm of participants, and how to use smart contracts to design better task allocation and reward and punishment systems. Privacy protection based on blockchain mainly achieves the protection of user privacy information during the uploading of perception data through task allocation mode and incentive mechanism design.

However, these crowd sensing solutions do not consider the identity authentication and privacy protection of participants before performing sensing tasks.

Summary of the invention

The purpose of the present invention is to overcome the shortcomings of the prior art and provide a distributed identity authentication method based on blockchain in crowd sensing, which realizes privacy protection of identity authentication by adopting zero-knowledge proof to authenticate the identities of crowd sensing participants.

In order to achieve the above-mentioned purpose, the technical solution adopted by the present invention is: a distributed identity authentication method based on blockchain in crowd sensing, in which participants are divided into ordinary nodes and cluster head nodes in the crowd sensing system, ordinary nodes are arranged on a private blockchain for authentication, and cluster head nodes are deployed on a public blockchain for authentication; wherein zero-knowledge proof is used to authenticate participants.

In group-aware sensing, participants also include task requesters. Task requesters and cluster head nodes are registered on the public blockchain, and ordinary nodes are registered on the private blockchain;

The task requester establishes a perception task on the blockchain and randomly selects a group of validators on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. After the cluster head node is successfully authenticated, it downloads the perception task from the public blockchain and assigns the perception task to ordinary nodes on the blockchain. Ordinary nodes that want to participate in the perception task send a request to participate in the perception task message, which triggers the perception task smart contract to share the generated secret function with ordinary nodes registered on the private chain and authenticate them.

When any node fails to authenticate, the authentication failure information will be sent to the blockchain, and then the node that failed the authentication will be deregistered from the blockchain.

The registration of crowd-sensing devices on the blockchain includes:

Step S1.1: First, the node applies for an account on Ethereum, and then obtains the public key and private key of this account to perform a sha256 signature operation, which is used as the user registration ID;

Step: S1.2 The node submits a registration request message, triggering the registration smart contract on the public chain;

Step S1.3: query the node ID stored in the public blockchain according to the registration request message;

Step S1.4: If the node ID already exists, a False will be returned to the node, telling the node that the user ID already exists and the registration fails; otherwise, registration is performed, the ID of the task requester is stored in the blockchain, and the user type is changed to the corresponding node type. The registration success status needs to be changed to True, and True is returned to the node, indicating that the node is successfully registered on the blockchain and the registration information has been stored in the blockchain.

Cluster head node authentication is that once the task requester establishes a perception task on the blockchain, a group of validators will be randomly selected on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. The cluster head node that fails the authentication will modify its status value, revoke the node, and modify the status values of all ordinary nodes belonging to the cluster head node.

The task requester publishes the perception task smart contract when establishing the perception task. The task information includes the perception task type, completion time, task status, and generates a secret function H _σ for node identity authentication. The secret function is shared with the cluster head node that has been successfully registered on the public blockchain. The cluster head node proves itself by generating witness and proof.

In the setup phase before cluster head node authentication, the task requester creates a Proving key and a Verifying key from the public reference string CRS to create and verify the proof. When the Proving key is sent to the registered cluster head node, the Verfier key is sent to the blockchain smart contract created for cluster head node authentication;

After the cluster head node is registered and receives the authentication element, the proof generation phase starts. In this phase, the cluster head node generates a proof. The cluster head node has a valid proof. The cluster head node will prove it through a pseudonymous address/> When sending to the authentication smart contract on the public chain, it is verified from the selected j validators.

After the cluster head node is successfully authenticated, it downloads the perception task from the public blockchain and assigns the perception task to the ordinary nodes on the blockchain. The ordinary nodes that want to participate in the perception task send a request to participate in the perception task message, triggering the perception task smart contract to share the generated secret function with the ordinary nodes registered on the private chain, starting the process of authenticating the identity of the ordinary nodes using zero-knowledge proof.

Ordinary node authentication includes: the secret function H _τ generated by the task requester is shared with the registered participants so that the participants can generate witnesses and proofs to prove themselves. The task requester also creates a proving key and a verification key from the public reference string CRS to create and verify proofs. When the proving key is sent to the participant, the verfier key is sent to the blockchain authentication smart contract; when the participant registers and receives the authentication element, it will start the evidence generation phase, during which the participant generates proofs; the proof σ of the participant node is sent to the authentication smart contract on the private chain through a pseudonymous address. If the verification is successful, the verification smart contract will store the belonging information locally. If the verification fails, it is regarded as a malicious user and the exist field is modified to false.

The advantages of the present invention are that the crowd sensing network is divided into a private blockchain and a public blockchain, and ordinary users and cluster head node users are respectively registered on them, and then the authentication of ordinary users and cluster head node users is realized through zero-knowledge proof, thereby realizing privacy protection and reliable authentication of device identity authentication in crowd sensing.

BRIEF DESCRIPTION OF THE DRAWINGS

The following is a brief description of the contents expressed in the drawings of the present invention and the marks in the drawings:

Figure 1 Hybrid blockchain network model

Figure 2 Flowchart of the solution

Figure 3 Node registration process

Figure 4. Authentication setup process between public blockchain and cluster head node

Figure 5. Proof of generation process between public blockchain and cluster head node

Figure 6 Verification process diagram of the authentication process between the public blockchain and the cluster head node

Figure 7 Authentication flow chart between common nodes and cluster head nodes

Figure 8 Node deregistration flow chart

Detailed ways

The specific implementation of the present invention will be further explained in detail below by describing the optimal embodiment with reference to the accompanying drawings.

As shown in Figure 1, a distributed identity authentication method based on blockchain in crowd sensing first divides the blockchain into a public blockchain and a private blockchain in a hierarchical manner to implement hierarchical authentication, divides the participant devices of crowd sensing into ordinary nodes and cluster head nodes, arranges the ordinary nodes on the private blockchain for authentication, and deploys the cluster head nodes on the public blockchain for authentication; wherein zero-knowledge proof is used to authenticate the participants.

In crowd sensing, the participants include task requesters, ordinary nodes, and cluster head nodes. Task requesters and cluster head nodes are registered on the public blockchain, and ordinary nodes are registered on the private blockchain. After the crowd sensing task is released, zero-knowledge proof is required to authenticate the identity of the participant devices of the cluster head node and ordinary node respectively.

In this application, task requester: The task requester needs to complete data collection tasks, such as indoor positioning, smart transportation, environmental monitoring, behavior perception, etc. But they do not have sufficient capabilities to complete the task themselves. The form and requirements of the required perception data are defined as perception tasks and published on the blockchain through smart contracts. Ordinary workers: Ordinary workers are nodes that are willing to contribute weaker computing power to perceive various data. Each ordinary node belongs to only one cluster head network. Ordinary nodes can usually only perceive and transmit simple data, have weak computing and storage capabilities, limited energy, and cannot perform complex operations and data processing. The cluster head node should be a device with strong computing power, which needs to process the data uploaded by ordinary nodes.

After the user's sensing device is registered in the public blockchain or private blockchain, the authentication step is entered after the registration is completed. First, the setting needs to be made. The task requester sets and publishes the sensing task smart contract. The task information includes the sensing task type, completion time, task status, and generates a secret function H _σ for node identity authentication. The secret function H _σ is then shared with the cluster head node and ordinary nodes. Then, by calculating the witness and proof, the generated proof is sent to the node's smart contract for verification. If the verification is passed, the identity authentication is successful and the sensing task is received; otherwise, the authentication fails and the node is deregistered.

The task requester establishes a perception task on the blockchain and randomly selects a group of validators on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. After the cluster head node is successfully authenticated, it downloads the perception task from the public blockchain and assigns the perception task to ordinary nodes on the blockchain. Ordinary nodes that want to participate in the perception task send a request to participate in the perception task message, which triggers the perception task smart contract to share the generated secret function with ordinary nodes registered on the private chain and authenticate them.

When any node fails to authenticate, the authentication failure information will be sent to the blockchain, and then the node that failed the authentication will be deregistered from the blockchain.

The registration of crowd-sensing devices on the blockchain includes:

Step S1.1: First, the node applies for an account on Ethereum, and then obtains the public key and private key of this account to perform a sha256 signature operation, which is used as the user registration ID;

Step: S1.2 The node submits a registration request message, triggering the registration smart contract on the public chain;

Step S1.3: query the node ID stored in the public blockchain according to the registration request message;

Step S1.4: If the node ID already exists, a False will be returned to the node, telling the node that the user ID already exists and the registration fails; otherwise, registration is performed, the ID of the task requester is stored in the blockchain, and the user type is changed to the corresponding node type. The registration success status needs to be changed to True, and True is returned to the node, indicating that the node is successfully registered on the blockchain and the registration information has been stored in the blockchain.

Cluster head node authentication is that once the task requester establishes a perception task on the blockchain, a group of validators will be randomly selected on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. The cluster head node that fails the authentication will modify its status value, revoke the node, and modify the status values of all ordinary nodes belonging to the cluster head node.

The present invention proposes a participant hierarchical authentication model based on a hybrid blockchain, which can solve the identity authentication problem of participants before performing tasks, and can also protect some privacy data of participants such as location.

First, a multi-participant model is designed. There are many kinds of sensing devices in crowd sensing. According to their willingness to participate, participants are divided into ordinary nodes, and cluster head nodes are hierarchically authenticated to facilitate collaboration between nodes. A hybrid blockchain model is proposed. In order to better adapt to the multi-participant hierarchical authentication model, the authentication of ordinary nodes is deployed on the local blockchain, and the cluster head nodes are deployed on the public blockchain for authentication, forming a hybrid blockchain model. Finally, zero-knowledge proof is used to authenticate participants at different levels. Ordinary nodes are authenticated by cluster head nodes on the local blockchain, and cluster head nodes are authenticated by public blockchain validators. The zokrates model is used to implement off-chain computing and on-chain authentication, which greatly reduces the workload of the blockchain.

Optionally, the public blockchain may be Ethereum or Hyperledger.

Optionally, the private blockchain may also select Ethereum or Hyperledger.

Ordinary nodes are users’ own devices, which can be mobile phones, computers, sensors, etc.

The cluster head node should be a device with strong computing power, which needs to process the data uploaded by ordinary nodes.

Using the Zokrates model, you can use some API interfaces provided by the official website or write your own code in a language, and then generate a zero-knowledge proof smart contract, which is written in the solidity language.

Optionally, the node is deployed to the blockchain by registering it to the blockchain using a smart contract, and the smart contract can be written in solidity language or chaincode language.

The multi-participant model is not just a one-to-many model where only one common node is deployed on a private chain network. A private chain network can manage multiple common nodes. There can also be multiple private chain networks forming a cluster. Each cluster head node manages a private chain network.

Identity authentication, based on the zero-knowledge verification smart contract, verifies whether the participant's identity meets the requirements. If it meets the requirements, the participant can receive the task. If it is found that it does not meet the requirements, it can be determined that the participant is an attacker and the participant will be deregistered.

As shown in Figure 1, we designed a hierarchical authentication model for participant nodes based on the different willingness of participants in the crowd-sensing network, and deployed a hybrid blockchain based on the model, introducing the Zokrates process in non-interactive zero-knowledge proof zkSNARKs to achieve hierarchical authentication. The model mainly includes three entities: blockchain, task requester, and participant. As shown in Figure 2, the distributed identity authentication scheme based on blockchain in crowd-sensing includes the following steps:

Step S1: First, select the sensing devices, which are divided into three types of node devices: task requesters, agents, and ordinary workers. Register these sensing devices on the blockchain. Task requesters and agents are registered on the public blockchain. Ordinary workers are registered on the private blockchain.

Step S2: When the task requester establishes a perception task on the blockchain, a group of validators will be randomly selected on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. After the cluster head node is successfully authenticated, it will download the perception task from the public blockchain and assign the perception task to ordinary nodes on the blockchain. Ordinary nodes that want to participate in the perception task send a request to participate in the perception task message, which triggers the perception task smart contract to share the generated secret function with ordinary nodes registered on the private chain.

Step S3: Once one of the nodes fails to authenticate, the authentication failure information will be sent to the blockchain, and then the node that failed the authentication will be deregistered in the blockchain.

Furthermore, the method of selecting a sensing device in step S1 includes:

Task requester: Task requesters need to complete data collection tasks, such as indoor positioning, smart transportation, environmental monitoring, behavior perception, etc. However, they do not have sufficient capabilities to complete the tasks themselves. The form and requirements of the required perception data are defined as perception tasks and published on the blockchain through smart contracts.

Proxy: The proxy is mainly used to simply process and forward the perception data from ordinary nodes in the network. It is a node that is willing to contribute strong computing and storage capabilities.

Ordinary workers: Ordinary workers are nodes that are willing to contribute weak computing power to sense various data. Each ordinary node belongs to only one cluster head network. Ordinary nodes can usually only sense and transmit simple data, have weak computing and storage capabilities, limited energy, and cannot perform complex operations and data processing.

Further, the registration of the sensing device in step S1, as shown in FIG3 , is described as follows:

Step S1.1: First, the node applies for an account on Ethereum, and then obtains the public key and private key of this account to perform a sha256 signature operation, which is used as the user registration id.

Step: S1.2 Node submits a registration request message, triggering the registration smart contract on the public chain

Step S1.3: Query the node ID stored in the public blockchain according to the registration request message.

Step S1.4: If it is found that the node ID already exists, a False will be returned to the node, telling the node that the user ID already exists and cannot be used again, and the registration fails.

Step S1.5: If the task requester's id does not exist, it means that the node has not been registered and used on the blockchain, and can be registered. The task requester's id needs to be stored in the blockchain, and the user type (True: indicates the task requester type, False means not the task requester type) needs to be changed to the corresponding node type, and the registration success status needs to be changed to True (False: indicates that the registration is not successful, True: indicates that the registration is successful). Finally, True is returned to the node, indicating that the node is successfully registered on the blockchain and the registration information has been stored in the blockchain.

The cluster head node authentication described in step S2 is that once the task requester establishes a perception task on the blockchain, a group of validators will be randomly selected on the public blockchain according to the encryption sorting algorithm (the probability is proportional to their funds on the blockchain) to authenticate the cluster head node. The cluster head node that fails the authentication will modify its status value, revoke the node, and modify the status values of all ordinary nodes belonging to the cluster head node.

Step S2.1 The setup phase of the authentication process, as shown in Figures 2 and 4, is as follows:

Step S2.1.1 The task requester publishes the perception task smart contract. The task information includes the perception task type, completion time, task status, and generates a secret function H _σ for node identity authentication, H _σ = sha256 (prk _c || timestamp), where prk _C refers to the private key of the node, and timeStamp represents the timestamp of generating the secret function; the secret function is shared with the cluster head node that has been successfully registered on the public blockchain, and the cluster head node proves itself by generating witnesses and proofs. Finding a variable that meets the conditions of the secret function is called a witness, which occurs in the proof generation stage.

Step S2.1.2 During the setup phase, the task requester also creates a Proving key and a Verifying key from the Public Reference String (CRS) to create and verify the Proof. The Proving key is sent to the registered cluster head node, and the Verfier key is sent to the blockchain smart contract created for cluster head node identity authentication.

Step S2.2 The cluster head node generates a certification process, as shown in Figure 5, and the steps are as follows:

Step S2.2.1: Once the cluster head node is registered and receives the authentication elements (the authentication elements are the secret function and the attestation key), it starts the attestation generation phase, in which the cluster head node generates a proof to prove its knowledge of the secret function H _τ . The constraint set cst for generating the proof has been compiled locally.

Step S2.2.2: The cluster head node starts the process by assigning a set of variables that satisfy the parameters of the secret function. It is assumed that the cluster head node knows H _τ and can therefore provide a satisfactory value. This variable assignment is called generating a witness. The cluster head node provides a public input PubInp = (timestamp) and a private input PriInp (prk _c ) (here it is mainly the input method provided by the zero-knowledge proof. The input methods include public input and private input. The public input can be changed, and the private input cannot be changed. It is mainly used for verification input. The public input here represents the timestamp of the input, and the private input represents the public key of the input node). Get witnessψ1 = witnessGen (cst, PubInp, PriInp) (witness), followed by a variable that also represents the witness, wintnessGen represents the function for generating the witness, cst: represents the constraint set for generating the proof). Next, using the witness and the proof key P (P is abbreviated as the proving key (provingkey)), the cluster head node generates a zk-snarks proof (zk-snarks means zero-knowledge proof, proofGen means the function to generate proof, and the variable before the equal sign means the generated proof) Step S2.3 The verification process of the authentication process is described as follows as shown in Figure 6:

Step S2.3.1: At this point, the cluster head node has a valid proof (σ and /> They all represent proofs, but they are used for different nodes. Proof: a general term, the other two are variables). The cluster head node sends the proof through a pseudonymous address. When the authentication smart contract (Authentication smart contract: represents the smart contract used for node authentication. Perception task smart contract: represents the smart contract for nodes to receive tasks) is sent to the public chain, it is verified from the selected j validators.

Step S2.3.2: We need to ensure that the selected validators must have sufficient balance in their blockchain accounts to prepare for subsequent penalties. In the process of selecting validators with sufficient balance, we utilize the cryptographic sorting algorithm VRF to randomly select a group of validators based on their balances. This allows the validator selection process to be securely performed on the public blockchain in a non-interactive and random manner, preventing Denial of Service (DoS) attacks because the attacker cannot know in advance which validator will be selected later.

Step S2.3.3: Specifically, the currency in each validator node blockchain account is quantified into the number of currency units, denoted as w. The probability that exactly j are selected from w currency units is binomial distribution:

P is the systematic probability of choosing a currency unit w represents the number of units of currency owned by the validator. To determine the exact number of units of currency chosen by the validator, the probability is used/> Construct a set of continuous intervals in the range [0,1)/> Here, mapping a random value t∈[0,1) to a specific interval ^Ij still has the same probability as B(j;w,p), and the value j corresponding to the interval to which t belongs can then be used to represent the number of selected currency units.

In order to make the above sorting process verifiable on the blockchain, t is calculated by the verifiable random function VRF[29]. Specifically, where hash is the pseudo-random hash value output from the VRF using sd and the validator’s secret key sk, and len is the bit length of the hash. Note that while the hash is uniformly distributed between 0 and len, t falls randomly in [0,1). Furthermore, the hash given by the validator can be verified by the VRF using its public verification key pk, so t can be regenerated in a verifiable manner on the smart contract. After performing the local cryptographic sorting process, each validator learns a value j representing how many of the currency units it has been selected, and if j>0, the validator sends a proof of sorting (hash,π) to the smart contract to participate in the certification task. (hash,π) will be checked by the VRF, VRF = (Gen,Eval,Prove,Verify) generates a publicly verifiable pseudo-random value. Given a security parameter λ, a probabilistic key generator gen(1λ) generates a secret key sk and a publicly verifiable key pk. With sk and information x, the evaluator Evalsk(x) outputs a pseudo-random value y, and a proving procedure Provesk(x) produces a proof π that proves that y is consistent with pk. Finally, the verifier takes Verifypk(π,x,y) as input and verifies the proof π. After verifying the proof, the sorting process is repeated to obtain the value j. If the regenerated value j>0, the smart contract will record the identity of the verifier and the value j. The selected verifier performs the verification task. If the verification is successful, the relevant information is stored on the public chain and the verifier is rewarded with a certain amount of funds. If the verification fails: the cluster head node is revoked and a new cluster head node is selected based on the account balance. The j value is the amount of currency selected in the selected verifier, which is used as the standard for selecting the verifier. The selected verifier executes the authentication smart contract, and the judgment basis for the success of the verification is the verification result of the zk-SNARKs proof generated above.

Step S2.4: Authentication between common nodes and cluster head nodes. The steps are as shown in Figure 7:

Step S2.4.1: After the cluster head node is successfully authenticated, it downloads the sensing task from the public blockchain and assigns the sensing task to the ordinary nodes on the blockchain. The ordinary nodes that want to participate in the sensing task send a request to participate in the sensing task message to trigger the sensing task smart contract to share the generated secret function with the ordinary nodes registered on the private chain. Start the ordinary node identity authentication process.

Step S2.4.2: Base Setting In this step, we implement a secret function H _τ that is difficult enough to prove, which requires the prover to prove his knowledge of the hash function preimage. Therefore, the difficulty of providing an invalid input to solve the secret function is to generate a τ′, such as τ′≠τ and H _τ′ ＝H _τ . (Here represents the secret function of τ′, an example is listed)

The task requester generates a secret function H _τ = sha256(pu k _u || timestamp) and shares it with the registered participants so that the participants can generate witnesses and proofs to prove themselves. The task requester also creates a proving key and a verification key from the public reference string (CRS) to create and verify proofs. When the proving key is sent to the participant, the verfier key is sent to the blockchain authentication smart contract.

Step S2.4.3: Generate proof Once a participant registers and receives the authentication element, it starts the proof generation phase, in which the participant generates a proof to prove its knowledge of the secret function H _τ . The participant node uses the public input timestamp PubInp(timestamp) to prevent replay attacks. Private input PriInp(prk _n ). Using the function witnessψ2＝witnessGen(PubInp, PriInp), the witness is calculated, the circuit proof key P2, and the user generates a zk-snarks proof σ＝proofGen(P2,Ψ2). (Represents the proof key and witness of an ordinary node, and the above is the witness and proof key of the cluster head node)

Step S2.4.3: At this point, the participant node has a proof σ. The proof σ is sent to the identity verification smart contract on the private chain through a pseudonymous address. If the verification is successful, the smart contract will store the belonging information locally. If the verification fails, it is regarded as a malicious user and the exist field is modified to false.

Finally, the node that fails S3 verification is deregistered in the blockchain as shown in Figure 8. The steps are as follows: Step S3.1: If the identity authentication of the ordinary participant node fails, the smart contract deployed on the cluster head node executes the node deregistration procedure and modifies the node exist field.

Step S3.2: If the validator receives the proof generated by the cluster head node and the identity authentication fails, the user will be regarded as a malicious user, and the smart contract will execute the node deregistration program and modify the node exist field to false.

Obviously, the specific implementation of the present invention is not limited to the above-mentioned methods. As long as various non-substantial improvements are made using the method concept and technical solution of the present invention, they are all within the protection scope of the present invention.

Claims (7)

1. A distributed identity authentication method based on blockchain in crowd sensing, characterized in that: in the crowd sensing system, participants are divided into ordinary nodes and cluster head nodes, ordinary nodes are arranged on a private blockchain for authentication, and cluster head nodes are deployed on a public blockchain for authentication; zero-knowledge proof is used to authenticate participants; In crowd sensing, participants also include task requesters. Task requesters and cluster head nodes are registered on the public blockchain, and ordinary nodes are registered on the private blockchain. The task requester establishes a perception task on the blockchain and randomly selects a group of validators on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. After the cluster head node is successfully authenticated, it downloads the perception task from the public blockchain and assigns the perception task to ordinary nodes on the blockchain. Ordinary nodes that want to participate in the perception task send a request to participate in the perception task message, which triggers the perception task smart contract to share the generated secret function with ordinary nodes registered on the private chain and authenticate them. When any node fails to authenticate, the authentication failure information will be sent to the blockchain, and then the node that failed the authentication will be deregistered from the blockchain. 2. A distributed identity authentication method based on blockchain in crowd intelligence perception as claimed in claim 1, characterized in that: the crowd intelligence perception device is registered on the blockchain including: Step S1.1: First, the node applies for an account on Ethereum, and then obtains the public key and private key of this account to perform a sha256 signature operation, which is used as the user registration ID; Step: S1.2 The node submits a registration request message, triggering the registration smart contract on the public chain; Step S1.3: query the node ID stored in the public blockchain according to the registration request message; Step S1.4: If the node ID already exists, a False will be returned to the node, telling the node that the user ID already exists and the registration fails; otherwise, registration is performed, the ID of the task requester is stored in the blockchain, and the user type is changed to the corresponding node type. The registration success status needs to be changed to True, and True is returned to the node, indicating that the node is successfully registered on the blockchain and the registration information has been stored in the blockchain. 3. A distributed identity authentication method based on blockchain in crowd intelligence perception as described in claim 1, characterized in that: cluster head node authentication is that once the task requester establishes a perception task on the blockchain, a group of validators will be randomly selected on the public blockchain according to the encryption sorting algorithm to authenticate the cluster head node. The cluster head node that fails the authentication will modify its status value, revoke the node, and modify the status values of all ordinary nodes of the cluster head node. 4. A distributed identity authentication method based on blockchain in crowd intelligence perception as described in any one of claims 1-3, characterized in that: the task requester publishes a perception task smart contract when establishing a perception task, the task information includes the perception task type, completion time, task status, and generates a secret function H _σ for node identity authentication, the secret function is shared with the cluster head node that has been successfully registered on the public blockchain, and the cluster head node proves itself by generating a witness and a proof. 5. A distributed identity authentication method based on blockchain in crowd intelligence perception as claimed in claim 4, characterized in that: in the setup stage before the cluster head node authentication, the task requester creates a proving key and a verification key from the public reference string CRS, which are used to create and verify the proof Proof, and when the Proving key is sent to the registered cluster head node, the Verfier key is sent to the blockchain smart contract created for the cluster head node identity authentication; After the cluster head node is registered and receives the authentication element, the proof generation phase starts. In this phase, the cluster head node generates a proof. The cluster head node has a valid proof. The cluster head node will prove it through a pseudonymous address/> When sending to the authentication smart contract on the public chain, it is verified from the selected j validators. 6. A distributed identity authentication method based on blockchain in group intelligence perception as described in any one of claims 1-3, characterized in that: after the cluster head node is successfully authenticated, it downloads the perception task from the public blockchain, assigns the perception task to the ordinary nodes on the blockchain, and the ordinary nodes that want to participate in the perception task send a request to participate in the perception task message, triggering the perception task smart contract to share the generated secret function with the ordinary nodes registered on the private chain, and starting the process of authenticating the identity of the ordinary nodes using zero-knowledge proof. 7. A distributed identity authentication method based on blockchain in crowd intelligence perception as described in claim 6, characterized in that: ordinary node identity authentication includes: the secret function H _τ generated by the task requester is shared with the registered participants so that the participants can generate witness and proof to prove themselves. The task requester also creates a proving key verfier key and a verification key verfier key from the public reference string CRS to create and verify the proof. When the proving key is sent to the participant, the verfier key is sent to the blockchain authentication smart contract; when the participant registers and receives the identity authentication element, it will start the evidence generation phase, in which the participant generates the proof; the proof σ of the participant node is sent to the identity authentication smart contract on the private chain through a pseudonymous address. If the verification of the verification smart contract is successful, the belonging information will be stored locally, etc. If the verification fails, it is regarded as a malicious user and the exist field is modified to false.