Hardware equipment verification method for distributed verification system

Abstract

The invention discloses a hardware equipment verification method for a distributed verification system. According to the Hash XOR response HS-xor-CRPs, a vector related to a block chain verification node is used as a mask, and differentiated verification information is generated with CRPs of the PUF through XOR operation. The differentiated CRPs solves the problem of PUF verification information leakage caused by a single-point fault, can tolerate the challenge of modeling attack to system availability, ensures that response errors caused by instability of a physical unclonable function are not diffused, does not need to use an error correction circuit, and reduces the cost. According to the method and the system, security authentication and traceability of the physical equipment in a decentralized environment are realized without intervention of a third-party credible mechanism.

Description

Technical Field

[0001] The invention relates to a hardware device verification method, and in particular to a hardware device verification method for a distributed verification system. Background Art

[0002] Traditional centralized systems concentrate decision-making and control in the hands of a single central entity, which has the disadvantages of single point failure and limited computing and storage resources. A successful network attack can paralyze the entire system. Decentralized systems have higher security and anti-attack capabilities by dispersing power. The emergence of blockchain technology has greatly promoted the development of decentralized systems. It realizes multi-party participation and multi-party verification through consensus algorithms, uses hash lists to ensure the immutability and authenticity of transaction records, and introduces smart contracts to enhance the flexibility of transactions. Blockchain has broad application prospects in trust management and data integrity, and has been applied to digital currency, smart agriculture, cloud computing, etc. However, the trust management and traceability mechanism of blockchain is currently mainly limited to the digital space and has a weak connection with physical entities. In areas such as supply chain or the Internet of Things where real devices need to be verified and traced, the threat of device forgery and counterfeiting is difficult to eliminate. For example, the situation of selling refurbished mobile phones or graphics cards as new devices still exists. How to ensure the authenticity of devices and establish a true correspondence between off-chain entities and on-chain data is a challenging problem that needs to be solved urgently.

[0003] Currently, the technologies used to associate physical entities with data include digital signatures, hardware tags, and physical trusted roots (such as physical unclonable functions). Digital signature technology based on the public key system can effectively verify the identity information of the message sender, but it has high requirements for computing resources. At the same time, the distribution and management of keys are complex, and there is a risk of key leakage. Once the private key is stolen by an attacker, it may lead to the forgery of legal signatures, resulting in irreparable losses. Hardware tags usually identify devices based on internal information of the device, which is low-cost but easy to be cloned and forged. Devices based on non-physical trusted roots are at risk of verification information being stolen.

[0004] Using a root of trust with a physical unclonable function (PUF) as the core has lower costs and higher security. PUF has the characteristic of "no key", which reduces the risk of key leakage caused by fault injection and side channel attacks, and does not require complex encryption and secure storage modules. At the same time, PUF has lightweight advantages such as low cost, low power consumption and small footprint, and cannot be cloned, so it can be used for device authentication and data encryption.

[0005] The application of PUF in decentralized systems requires registration on the verification node before verification. The verification information is registered as confidential information on all nodes in the system, and all verification nodes share it at the same time and are not public. However, this method has the risk that the verification information may be leaked once a malicious or attacked person is found. The attacker can easily pass the verification of all nodes and make the entire system invalid. There is still a single point leakage problem similar to that in centralized systems. In addition, attackers may also use machine learning and deep learning methods to use the leaked verification information as training data to model the PUF. How to protect PUF from modeling attacks in distributed scenarios is a challenge. On the other hand, since the output of PUF is easily affected by the environment (such as temperature and power supply), the response results obtained by inputting the same challenge multiple times are not exactly the same, which brings difficulties to PUF verification. Error correction circuits are usually required to handle these errors, increasing the cost of PUF.

[0006] Li et al. proposed to prevent the leakage of PUF verification information (CRPs, Challenge-Response, Pairs) by distributing PUF models, but the intervention of a third-party trusted organization is still required and the model itself is also at risk of leakage.

[0007] In summary, the application of PUF in blockchain has the problem of single-point leakage of verification information. At the same time, attackers may also use machine learning and deep learning methods to use the leaked verification information as training data to model PUF, which seriously threatens the security and credibility of device authentication services. Summary of the invention

[0008] In order to solve the problems and needs in the background technology, the present invention combines PUF and blockchain technology to trace the real device, and provides a hardware device verification method for a distributed verification system. The present invention proposes a hash XOR response HS-xor-CRPs, which uses a vector related to the blockchain verification node as a mask, and generates differentiated verification information through XOR operation with the CRPs of the PUF. Differentiated CRPs solve the problem of PUF verification information leakage caused by single point failures, and can tolerate the challenges of modeling attacks on system availability, while ensuring that response errors caused by the instability of physical unclonable functions do not spread, without the need to use error correction circuits, and reducing costs. The present invention realizes the security authentication and traceability of physical devices in a decentralized environment without the intervention of a third-party trusted organization.

[0009] The technical solution adopted by the present invention is:

[0010] Each of the hardware devices carries a hash XOR PUF module;

[0011] During the registration phase, the registration node distributes the registration information containing the verification information corresponding to each hardware device to all verification nodes;

[0012] During the transaction phase, the user generates an actual hash XOR response through the hash XOR PUF module carried by the hardware device and sends it to the verification node. Each verification node verifies the hardware device based on the actual hash XOR response received, and then generates the final verification result and returns it to the user.

[0013] The hash XOR PUF module of each of the hardware devices includes an original PUF module, a hash calculation module and an XOR gate circuit, the original PUF module is connected to the XOR gate circuit, and the hash calculation module is connected to the XOR gate circuit; each challenge signal of the current device serves as the input of the original PUF module and the input of the hash calculation module, the device verification vector of each verification node is also used as the input of the hash calculation module, and the XOR gate circuit outputs the corresponding hash XOR response.

[0014] During the registration phase, the registration node distributes the registration information containing the verification information corresponding to each hardware device to all verification nodes, including:

[0015] S1: Randomly generate n challenge signals corresponding to each hardware device and assign a device verification vector corresponding to the hardware device to each verification node;

[0016] S2: Take each challenge signal and the device verification vector of each verification node as the input of the Hash XOR PUF module to obtain the corresponding real Hash XOR response Rm. Each challenge signal and the corresponding real Hash XOR response form a verification information of the current verification node. After traversing and processing n challenge signals, all verification information {C, Rm} between the hardware device and the current verification node is obtained. 1～n ;

[0017] S3: Repeat S2, traverse and process all verification nodes, and obtain all verification information corresponding to the hardware device and each verification node;

[0018] S4: Repeat S1-S3 to register different hardware devices, and generate all verification information corresponding to several hardware devices and each verification node;

[0019] S5: The registration node submits a registration request to all verification nodes and distributes corresponding registration information to each verification node. The registration information of verification node i includes device ID, registration node ID, and device verification vector Vector of verification node i. i , the verification information {C,Rm} between each hardware device and verification node i 1～n .

[0020] The registration information is sent to each verification node in a P2P manner through a secure channel.

[0021] In the transaction phase, the user generates a hash XOR response through the hash XOR PUF module carried by the hardware device and sends it to the verification node. Each verification node verifies the hardware device based on the actual hash XOR response received, and then generates the final verification result and returns it to the user, including:

[0022] STEP 1: After receiving the transaction request sent by the user, each verification node generates a challenge signal of the hardware device requested by the user through the smart contract on the chain and returns it to the user;

[0023] STEP2: After receiving the challenge signals returned by several verification nodes, the user inputs the challenge signals returned by each verification node and the corresponding device verification vector into the hash XOR PUF module of the hardware device, and obtains the actual hash XOR response corresponding to each verification node. The challenge signal returned by each verification node and the corresponding actual hash XOR response form a transaction information; then, the user distributes the verification transaction request containing the transaction information of each verification node to the verification node respectively;

[0024] STEP 3: Each verification node verifies the correctness of the received transaction information through the smart contract on the chain, generates the final verification result of the user's hardware device based on the verification results of each verification node, and returns it to the user.

[0025] The STEP 1 is specifically as follows:

[0026] STEP11: After receiving the transaction request sent by the user, each verification node checks the registration status of the hardware device according to the device ID; if it has been registered, it retrieves the historical request information corresponding to the hardware device, otherwise it rejects the transaction request;

[0027] STEP 12: Check the time when the current user last sent a request based on the historical request information of the hardware device; if the time difference between the last and current request times is shorter than the preset request time difference, refuse to return the challenge signal, otherwise execute STEP 13;

[0028] STEP 13: The current verification node generates a challenge ID for the current user, retrieves the challenge signal corresponding to the challenge ID from its node database, and returns it to the user.

[0029] In STEP 3, each verification node verifies the correctness of the received transaction information through the smart contract on the chain, specifically:

[0030] Each verification node retrieves the historical request information of the hardware device according to the device ID in the transaction information, and checks the status of the user obtaining the challenge signal according to the historical request information of the hardware device. After the check is passed, each verification node retrieves the real hash XOR response corresponding to the current challenge signal from its own node database and compares it with the actual hash XOR response received to obtain the corresponding comparison result; finally, the verification result corresponding to the verification node is generated according to the comparison result.

[0031] The checking of the user's status of obtaining the challenge signal includes checking whether the user has obtained the challenge signal and whether the difference between the time of obtaining the challenge signal and the time of the current verification response does not exceed a preset time threshold. If both are yes, the check passes.

[0032] Generating the final verification result of the hardware device owned by the user according to the verification results of each verification node includes:

[0033] When most of the verification nodes pass the verification, the hardware device passes the verification.

[0034] The beneficial effects of the present invention are:

[0035] 1. Since the PUF verification information in the present invention is distributed to all verification nodes on the chain in a differentiated manner, even if the PUF information of a few nodes is leaked, it will not cause the distributed verification service to be unavailable, thus solving the problem of single point leakage.

[0036] 2. The HS-xor-CRPs design proposed in the present invention breaks the intrinsic connection between the PUF input C and the output R, thereby increasing the difficulty of modeling attacks on the PUF to the difficulty of modeling hash algorithms. For a well-designed hash function (such as the Sha256 algorithm), it has one-way and collision-resistant properties in cryptography. It is almost impossible to reverse the original input from the hash value, and there is no effective modeling attack on it. Therefore, the verification information can effectively resist the threat of modeling attacks.

[0037] 3. The method proposed in the present invention does not require a third-party trusted organization or error correction circuit, thus reducing management and production costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 Schematic diagram of the structure of the hash XOR PUF module.

[0039] Figure 2 Schematic diagram of the verification method of the present invention.

[0040] Figure 3 This is a flowchart of the registration phase.

[0041] Figure 4 The flowchart of the transaction phase is shown in Figure 2. DETAILED DESCRIPTION

[0042] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0043] The definitions of some terms in the present invention are as follows:

[0044] Verification Nodes: Only enterprises, government departments or industry associations recognized by the alliance chain network can serve as verification nodes. Each verification node should have workstation-level hardware configuration, including server-level computing and storage resources and large-capacity communication bandwidth.

[0045] Registered node User0: Usually the manufacturer or assembler of the device. As a trusted party, it has the right to register new devices and usually plays the role of Nodes at the same time, with the same computing resources as Nodes.

[0046] User UserA / B: The transaction interface is open to the public. Anyone with Internet access and mobile phone-level resources can initiate and participate in transactions. In each transaction, the previous device owner, the seller, is called UserA, the next device owner, the buyer, is called UserB, and the nodes that verify the transaction are called verification nodes. Since the buyer (UserB) will pay a price to obtain the device from the seller (UserA) and bear the responsibility for the device after the transaction, the buyer (UserB) is considered to be trustworthy, while the seller (UserA) is not necessarily trustworthy. It is assumed that users have lightweight general-purpose computing resources and limited data storage and bandwidth, such as mobile phones and personal computers.

[0047] Hardware device: It is assumed that the hash XOR PUF module carried by the hardware device is cryptographically secure, cannot be cloned, and cannot be completely reverse attacked at a reasonable cost (i.e., all CRPs cannot be obtained).

[0048] Participants who hold devices in a certain period of time, such as manufacturers, distributors, wholesalers, consumers, etc., are called users, and the device manufacturer is called User0.

[0049] like Figure 2 As shown, the present invention proposes a hardware device verification method for a distributed verification system, comprising:

[0050] Each hardware device carries a hash XOR PUF module;

[0051] like Figure 1As shown in the figure, the hash XOR PUF module of each hardware device includes the original PUF module, the hash calculation module and the XOR gate circuit. The original PUF module is connected to the XOR gate circuit, and the hash calculation module is connected to the XOR gate circuit. Each challenge signal (Challenge, denoted as C) of the current device is used as the input of the original PUF module and the input of the hash calculation module. The device verification vector of each verification node is also used as the input of the hash calculation module. The XOR gate circuit outputs the corresponding hash XOR response. Among them, the device verification vector Vector of verification node i is i It is a unique vector corresponding to the current device assigned by the registration node to the verification node i. The device verification vector of each verification node is public information, and users can obtain this information from the chain (the verification vectors of all verification nodes are put on the chain during the registration phase); or it is made public on the Internet, and users can find it on the Internet. Specifically:

[0052] Each hardware device is embedded with a hidden secret seed. The secret seed is embedded in the device as secret information and is not disclosed. The input challenge signal, the device verification vector of the verification node and the secret seed are concatenated as the input of the hash function in the hash calculation module, and then the generated hash value is XORed with the output response Response of the PUF, and the result of the XOR operation is used as the hash XOR response, satisfying the formula: Rm i C = {PUF(C)⊕Hash(Vector i ,C,Seed)},Rm i C is the hash XOR response between the challenge signal C and the device verification vector of the verification node i, PUF() is the PUF function, ⊕ is the XOR operation, and Hash() is the hash function.

[0053] Through HS-xor-CRPs, different nodes receive different verification information. Even if the verification information of a small number of nodes is leaked, since the attacker cannot obtain the original PUF Response, the CRPs of other nodes cannot be cracked, allowing the entire system to resist modeling attacks. In addition, the XOR operation of the hash value and the output of the PUF breaks the inherent connection between the PUF input C and the output R, thereby raising the difficulty of modeling attacks on the PUF to the difficulty of modeling hash algorithms. For well-designed hash functions (such as Sha256, etc.), this operation can effectively resist modeling attacks. At the same time, the XOR operation will not spread bit errors caused by PUF instability. At the same time, the XOR operation will not spread bit errors caused by PUF instability.

[0054] In the registration phase, the registration node in the blockchain distributes the registration information containing the verification information corresponding to each hardware device to all verification nodes in the blockchain (the number of verification nodes is recorded as N); Figure 3 As shown, specifically including:

[0055] S1: Randomly generate n challenge signals corresponding to each hardware device (usually 50,000 to 100,000) and assign a unique device verification vector corresponding to the hardware device to each verification node, denoted as Vector i ;

[0056] S2: Take each challenge signal and the device verification vector of each verification node as the input of the Hash XOR PUF module to obtain the corresponding real Hash XOR response Rm (Hash-xor-Response). Each challenge signal and the corresponding real Hash XOR response form a verification information of the current verification node. After traversing and processing n challenge signals, all verification information {C, Rm} between the hardware device and the current verification node is obtained. 1～n ;

[0057] S3: Repeat S2, traverse and process all verification nodes, and obtain all verification information corresponding to the hardware device and each verification node;

[0058] S4: Repeat S1-S3 to register different hardware devices, and generate all verification information corresponding to several hardware devices and each verification node;

[0059] S5: The registration node submits a registration request to all verification nodes and distributes the corresponding registration information to each verification node. The registration information of verification node i includes device ID, registration node ID, and device verification vector Vector of verification node i i , the verification information {C,Rm} between each hardware device and verification node i 1～n and other public information.

[0060] The registration information is sent to each verification node in a P2P manner through a secure channel. Specifically, the registration node User0 first negotiates a key with each verification node, then uses the key to perform AES symmetric encryption on the registration information before transmitting it to each node.

[0061] Although the challenge signal data and order received by each verification node are the same, due to the different device verification vectors Vector of each verification node, different verification nodes receive different true hash XOR responses Rm for the same challenge signal. After receiving the registration information, each verification node saves the verification information in the registration information in its own private database and is responsible for protecting its privacy and security. After completing the registration, the hardware device can be circulated and traded in the market, and the entire transaction cycle of the product will be tracked to ensure its authenticity and security.

[0062] During the transaction phase, the verification node verifies the authenticity of the hardware device by verifying the hash XOR response submitted by the user. UserA, as the seller, may sell counterfeit devices and is therefore untrustworthy; while UserB, as the buyer, will pay a price to become the device owner and is responsible for the device, making him a trusted party.

[0063] During the transaction phase, the user generates an actual hash XOR response through the hash XOR PUF module carried by the hardware device and sends it to the verification node. Each verification node verifies the hardware device based on the actual hash XOR response received, and then generates the final verification result and returns it to the user. Figure 4 As shown, specifically including:

[0064] STEP 1: User UserB, as the Client, submits a transaction request (the request contains the device ID of the required transaction hardware device) and sends it to all verification nodes in the blockchain. After receiving the transaction request sent by the user, each verification node generates a challenge signal for the hardware device requested by the user through the smart contract on the chain and returns it to the verification node;

[0065] STEP 1 is as follows:

[0066] STEP11: After receiving the transaction request sent by the user, each verification node checks the registration status of the hardware device according to the device ID; if it has been registered, it retrieves the historical request information corresponding to the hardware device, otherwise it rejects the transaction request;

[0067] STEP 12: Check the time when the current user last sent a request based on the historical request information of the hardware device; if the time difference between the last and current request times is shorter than the preset request time difference (such as 5 minutes), refuse to return the challenge signal, otherwise execute STEP 13;

[0068] STEP13: The current verification node generates the challenge ID of the current user, takes out the challenge signal corresponding to the challenge ID from its node database and returns it to the user. Since each verification node stores the same verification information in the same order, the generated challenge signal C is also the same. Subsequently, the challenge signal C is stored in the device information and returned to the user.

[0069] This ensures that the challenge signal in each transaction is unique and secure, effectively preventing malicious attackers from guessing and exploiting the challenge signal of the verification node through repeated requests.

[0070] STEP2: After receiving the challenge signals returned by several verification nodes, the user inputs the challenge signals returned by each verification node and the corresponding device verification vector into the hash XOR PUF module of the hardware device, and obtains the actual hash XOR response corresponding to each verification node. The challenge signal returned by each verification node and the corresponding actual hash XOR response form a transaction information; then, the user distributes the verification transaction request containing the transaction information of each verification node to the verification node respectively. The verification transaction request contains the device ID, the transaction information of each verification node {C, Rm 1～N} and device info, which is additional information about the device, such as the device owner, remaining lifespan, and other device-related information that will change during use and transactions;

[0071] STEP3: Each verification node verifies the correctness of the received transaction information through the smart contract on the chain. When most verification nodes pass the verification, the hardware device passes the verification and returns the final verification result to the user. The transaction is completed and written into the blockchain. At the same time, the device's historical request information and the device's additional information will also be updated. Through this process, the system ensures the authenticity verification of the device.

[0072] In STEP3, each verification node verifies the correctness of the received transaction information through the smart contract on the chain, specifically:

[0073] Each verification node retrieves the historical request information of the hardware device according to the device ID in the transaction information, and checks the status of the user obtaining the challenge signal according to the historical request information of the hardware device.

[0074] Checking the status of the user obtaining the challenge signal includes checking whether the user has obtained the challenge signal and whether the time of obtaining the challenge signal is less than the preset time threshold (such as 5 minutes) with the current verification response time. If both are yes, the check passes.

[0075] After the check is passed, each verification node takes out the real hash XOR response corresponding to the current challenge signal from its own node database and compares it with the actual hash XOR response received to obtain the corresponding comparison result; finally, the verification result corresponding to the verification node is generated based on the comparison result. For example, if the number of identical bits between the real hash XOR response and the actual hash XOR response received exceeds 90%, the verification is successful.

[0076] Finally, it should be noted that the above embodiments and explanations are only used to illustrate the technical solution of the present invention rather than to limit it. It should be understood by those skilled in the art that the technical solution of the present invention can be modified or replaced by equivalents without departing from the spirit and scope disclosed in the technical solution of the present invention, which should be included in the scope of protection of the claims of the present invention.

Claims

1. A hardware device verification method for a distributed verification system, characterized in that: include: Each of the hardware devices carries a hash XOR PUF module; During the registration phase, the registration node distributes the registration information containing the verification information corresponding to each hardware device to all verification nodes; During the transaction phase, the user generates an actual hash XOR response through the hash XOR PUF module carried by the hardware device and sends it to the verification node. Each verification node verifies the hardware device based on the actual hash XOR response received, and then generates the final verification result and returns it to the user.

2. A hardware device verification method for a distributed verification system according to claim 1, characterized in that: The hash XOR PUF module of each of the hardware devices includes an original PUF module, a hash calculation module and an XOR gate circuit, the original PUF module is connected to the XOR gate circuit, and the hash calculation module is connected to the XOR gate circuit; each challenge signal of the current device serves as the input of the original PUF module and the input of the hash calculation module, the device verification vector of each verification node is also used as the input of the hash calculation module, and the XOR gate circuit outputs the corresponding hash XOR response.

3. A hardware device verification method for a distributed verification system according to claim 1, characterized in that: During the registration phase, the registration node distributes the registration information containing the verification information corresponding to each hardware device to all verification nodes, including: S1: Randomly generate n challenge signals corresponding to each hardware device and assign a device verification vector corresponding to the hardware device to each verification node; S2: Take each challenge signal and the device verification vector of each verification node as the input of the Hash XOR PUF module to obtain the corresponding real Hash XOR response Rm. Each challenge signal and the corresponding real Hash XOR response form a verification information of the current verification node. After traversing and processing n challenge signals, all verification information {C, Rm} between the hardware device and the current verification node is obtained. 1～n ; S3: Repeat S2, traverse and process all verification nodes, and obtain all verification information corresponding to the hardware device and each verification node; S4: Repeat S1-S3 to register different hardware devices, and generate all verification information corresponding to several hardware devices and each verification node; S5: The registration node submits a registration request to all verification nodes and distributes corresponding registration information to each verification node. The registration information of verification node i includes device ID, registration node ID, and device verification vector Vector of verification node i i , the verification information {C,Rm} between each hardware device and verification node i 1～n .

4. A hardware device verification method for a distributed verification system according to claim 1, characterized in that: The registration information is sent to each verification node in a P2P manner through a secure channel.

5. A hardware device verification method for a distributed verification system according to claim 1, characterized in that: In the transaction phase, the user generates a hash XOR response through the hash XOR PUF module carried by the hardware device and sends it to the verification node. Each verification node verifies the hardware device based on the actual hash XOR response received, and then generates the final verification result and returns it to the user, including: STEP 1: After receiving the transaction request sent by the user, each verification node generates a challenge signal of the hardware device requested by the user through the smart contract on the chain and returns it to the user; STEP2: After receiving the challenge signals returned by several verification nodes, the user inputs the challenge signals returned by each verification node and the corresponding device verification vector into the hash XOR PUF module of the hardware device, and obtains the actual hash XOR response corresponding to each verification node. The challenge signal returned by each verification node and the corresponding actual hash XOR response form a transaction information; then, the user distributes the verification transaction request containing the transaction information of each verification node to the verification node respectively; STEP 3: Each verification node verifies the correctness of the received transaction information through the smart contract on the chain, generates the final verification result of the user's hardware device based on the verification results of each verification node, and returns it to the user.

6. A hardware device verification method for a distributed verification system according to claim 5, characterized in that: The STEP 1 is specifically as follows: STEP11: After receiving the transaction request sent by the user, each verification node checks the registration status of the hardware device according to the device ID; if it has been registered, it retrieves the historical request information corresponding to the hardware device, otherwise it rejects the transaction request; STEP 12: Check the time when the current user last sent a request based on the historical request information of the hardware device; if the time difference between the last and current request times is shorter than the preset request time difference, refuse to return the challenge signal, otherwise execute STEP 13; STEP 13: The current verification node generates a challenge ID for the current user, retrieves the challenge signal corresponding to the challenge ID from its node database, and returns it to the user.

7. A hardware device verification method for a distributed verification system according to claim 5, characterized in that: In STEP 3, each verification node verifies the correctness of the received transaction information through the smart contract on the chain, specifically: Each verification node retrieves the historical request information of the hardware device according to the device ID in the transaction information, and checks the status of the user obtaining the challenge signal according to the historical request information of the hardware device. After the check is passed, each verification node retrieves the real hash XOR response corresponding to the current challenge signal from its own node database and compares it with the actual hash XOR response received to obtain the corresponding comparison result; finally, the verification result corresponding to the verification node is generated according to the comparison result.

8. A hardware device verification method for a distributed verification system according to claim 7, characterized in that: The checking of the user's status of obtaining the challenge signal includes checking whether the user has obtained the challenge signal and whether the difference between the time of obtaining the challenge signal and the time of the current verification response does not exceed a preset time threshold. If both are yes, the check passes.

9. A hardware device verification method for a distributed verification system according to claim 5, characterized in that: Generating the final verification result of the hardware device owned by the user according to the verification results of each verification node includes: When most of the verification nodes pass the verification, the hardware device passes the verification.

Images