A hardware device verification method for a distributed verification system

Abstract

This invention discloses a hardware device verification method for a distributed verification system. The Hash-Xor-CRPs of this invention use a vector associated with the blockchain verification node as a mask, and generate differentiated verification information by XORing it with the CRPs of the PUF (Publicly Unclonable Function). These differentiated CRPs solve the problem of PUF verification information leakage caused by single points of failure, and can tolerate the challenges to system availability posed by modeling attacks. Simultaneously, they ensure that response errors caused by the instability of physically unclonable functions do not propagate, eliminating the need for error correction circuits and reducing costs. This invention achieves secure authentication and traceability of physical devices in a decentralized environment without the need for intervention from a third-party trusted institution.

Description

Technical Field

[0001] This invention relates to a hardware device verification method, and more specifically to a hardware device verification method for a distributed verification system. Background Technology

[0002] Traditional centralized systems concentrate decision-making and control in the hands of a single central entity, resulting in single points of failure and limitations in computing and storage resources. A single successful cyberattack can paralyze the entire system. Decentralized systems, by distributing power, offer greater security and resilience. The emergence of blockchain technology has greatly promoted the development of decentralized systems. Through consensus algorithms, it enables multi-party participation and verification; hash chains ensure the immutability and authenticity of transaction records; and smart contracts enhance transaction flexibility. Blockchain has broad application prospects in trust management and data integrity, and has been applied in areas such as digital currency, smart agriculture, and cloud computing. However, current blockchain trust management and traceability mechanisms are primarily limited to the digital space, with weak connections to physical entities. In areas such as supply chains or the Internet of Things (IoT) where verification and traceability of physical devices are crucial, the threat of device counterfeiting and spoofing remains. For example, refurbished mobile phones or graphics cards are still sold as brand new devices. Ensuring the authenticity of devices and establishing a true correspondence between off-chain entities and on-chain data remains a challenging problem that urgently needs to be solved.

[0003] Currently, technologies used to associate physical entities with data include digital signatures, hardware tags, and physical roots of trust (such as physically non-cloning functions). Public-key cryptography-based digital signatures can effectively verify the identity of message senders, but they require significant computing resources, and key distribution and management are complex, posing a risk of key leakage. If the private key is stolen by an attacker, it can lead to the forgery of legitimate signatures, causing irreparable damage. Hardware tags typically identify devices based on internal information, offering lower costs, but are easily cloned and forged. Devices based on non-physical roots of trust are at risk of having their verification information stolen.

[0004] Using a trusted root based on a Physically Unclonable Function (PUF) offers lower cost and higher security. PUFs are "keyless," reducing the risk of key leakage due to fault injection and side-channel attacks, and eliminating the need for complex encryption and secure storage modules. Furthermore, PUFs offer lightweight advantages such as low cost, low power consumption, and small footprint, and because they cannot be cloned, they can be used for device authentication and data encryption.

[0005] The application of PUF in decentralized systems requires registration and verification on verification nodes. Verification information is registered as confidential information on all nodes, shared simultaneously but not publicly. However, this method carries the risk of verification information leakage should a malicious actor or be attacked. An attacker could easily bypass verification on all nodes, rendering the entire system inoperable, exhibiting a single point of failure problem similar to that in centralized systems. Furthermore, attackers could utilize machine learning and deep learning techniques, using leaked verification information as training data to model attacks on the PUF. Protecting the PUF from such attacks in a distributed environment is a significant challenge. On the other hand, the PUF's output is susceptible to environmental influences (such as temperature and power supply), leading to inconsistent responses to the same challenge multiple times. This complicates PUF verification, typically requiring error correction circuits to handle these errors, increasing the PUF's cost.

[0006] Li et al. proposed preventing the leakage of PUF verification information (CRPs, Challenge-Response, Pairs) by distributing PUF models, but this still requires the intervention of a trusted third-party organization, 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 of leakage of verification information. Furthermore, attackers may use machine learning and deep learning techniques to use the leaked verification information as training data to model and attack PUF, thereby seriously threatening the security and trustworthiness of device authentication services. Summary of the Invention

[0008] To address the problems and needs existing in the background technology, this invention provides a hardware device verification method for distributed verification systems by combining PUF and blockchain technologies to trace real devices. This invention proposes Hash-Xor-CRPs, which use a vector associated with the blockchain verification node as a mask and XOR it with the PUF CRPs to generate differentiated verification information. The differentiated CRPs solve the problem of PUF verification information leakage caused by single point of failure and can tolerate the challenges to system availability posed by modeling attacks. Simultaneously, it ensures that response errors caused by the instability of physically non-cloning functions do not propagate, eliminating the need for error correction circuits and reducing costs. This invention achieves secure authentication and traceability of physical devices in a decentralized environment without the need for a third-party trusted institution.

[0009] The technical solution adopted in this invention is:

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

[0011] During the registration phase, the registration node distributes registration information containing 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 received actual hash XOR response, and then generates the final verification result and returns it to the user.

[0013] Each of the aforementioned hardware devices has a hash XOR PUF module comprising a raw PUF module, a hash calculation module, and an XOR gate circuit. The raw 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 to the raw PUF module and the input to the hash calculation module. The device verification vector of each verification node also serves as the input to the hash calculation module. The XOR gate circuit outputs the corresponding hash XOR response.

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

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

[0016] S2: Each challenge signal and the device verification vector of each verification node are used as input to the hash XOR PUF module to obtain the corresponding true hash XOR response Rm. Each challenge signal and its corresponding true hash XOR response constitute a verification message for the current verification node. After processing n challenge signals, all verification messages {C, Rm} between the hardware device and the current verification node are obtained. 1～n ;

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

[0018] S4: Repeat S1-S3 to register different hardware devices and generate all the 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 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 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 via a secure channel in a P2P manner.

[0021] During the transaction phase, the user generates a hash XOR response using 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 received actual hash XOR response, thereby generating the final verification result and returning it to the user, including:

[0022] STEP 1: 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 on-chain smart contract and returns it to the user;

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

[0024] STEP3: Each verification node verifies the correctness of the received transaction information through the on-chain smart contract, 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] STEP1 specifically refers to:

[0026] STEP11: After each verification node receives a transaction request from a user, it checks the registration status of the hardware device based on 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] STEP12: Check the time of the last request sent by the current user based on the historical request information of the hardware device; if the time difference between the last and the current request time is shorter than the preset request time difference, then refuse to return the challenge signal; otherwise, proceed to STEP13.

[0028] STEP13: The current verification node generates the 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 STEP3, each verification node verifies the correctness of the received transaction information through an on-chain smart contract, specifically as follows:

[0030] Each verification node retrieves the historical request information of the hardware device based on the device ID in the transaction information. It then checks the user's status in obtaining the challenge signal based on 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 received actual hash XOR response to obtain the corresponding comparison result. Finally, the verification result corresponding to the verification node is generated based on the comparison result.

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

[0032] The step of generating the final verification result for the user's hardware devices based on the verification results of each verification node includes:

[0033] The hardware device is verified when a majority of the verification nodes pass the verification.

[0034] The beneficial effects of this invention are:

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

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

[0037] 3. The method proposed in this invention does not require a trusted third-party institution or error correction circuit, thus reducing management and production costs. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the structure of the hash XOR PUF module.

[0039] Figure 2 This is a schematic diagram of the verification method of the present invention.

[0040] Figure 3 This is a flowchart illustrating the registration process.

[0041] Figure 4 This is a flowchart illustrating the transaction process. Detailed Implementation

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

[0043] The definitions of some terms used in this invention are as follows:

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

[0045] Registered Node User0: This is usually the manufacturer or assembler of the device. As a trusted party, it has the right to register new devices and usually also acts as a Node, possessing the same computing resources as the Node.

[0046] Users (UserA / B): The transaction interface is open to the public; anyone with internet access and mobile-level or higher resources can initiate and participate in transactions. In each transaction, the previous device owner (seller) is called UserA, and the next device owner (buyer) is called UserB. The nodes that verify the transaction are called Verification Nodes. Since the buyer (UserB) pays a price to acquire the device from the seller (UserA) and assumes responsibility for the device after the transaction, the buyer (UserB) is considered trustworthy, while the seller (UserA) is not necessarily trustworthy. Assume users possess 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-engineered at a reasonable cost (i.e., it is impossible to obtain all CRPs).

[0048] Participants who hold the equipment during a certain period of time, such as manufacturers, distributors, wholesalers, and consumers, are called users, while the equipment manufacturer is called user0.

[0049] like Figure 2 As shown, this 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, each hardware device's hash XOR PUF module includes a raw PUF module, a hash calculation module, and an XOR gate circuit. The raw PUF module is connected to the XOR gate circuit, and the hash calculation module is also connected to the XOR gate circuit. Each challenge signal (C) of the current device serves as the input to both the raw PUF module and the hash calculation module. The device verification vector of each verification node also serves as the input to the hash calculation module. The XOR gate circuit outputs the corresponding hash XOR response. Here, the device verification vector Vector of verification node i... i This is a unique vector assigned by the registration node to verification node i, corresponding to the current device. Each verification node's device verification vector is public information, which users can obtain from the blockchain (all verification vectors of all verification nodes are uploaded to the blockchain during the registration phase); or it can be made public on the internet, where users can find it. Specifically:

[0052] Each hardware device contains a hidden secret seed, which is kept secret within the device. The input challenge signal, the device verification vector of the verification node, and the secret seed are concatenated and used as input to the hash function in the hash calculation module. The generated hash value is then XORed with the PUF's output response. The result of this 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 The hash XOR response between the challenge signal C and the device verification vector of verification node i is defined by PUF(), where ⊕ is the XOR operation and Hash() is the hash function.

[0053] Through HS-xor-CRPs, different nodes receive different authentication information. Even if the authentication information of a small number of nodes is leaked, the attacker cannot obtain the original PUF's response, thus preventing the CRPs of other nodes from being cracked, allowing the entire system to resist modeling attacks. Furthermore, XORing the hash value with the PUF output breaks the inherent connection between the PUF input C and output R, thereby increasing the difficulty of modeling attacks on the PUF to the difficulty of modeling the hash algorithm itself. For well-designed hash functions (such as Sha256), this operation can effectively resist modeling attacks. Simultaneously, the XOR operation does not propagate bit errors caused by PUF instability.

[0054] During the registration phase, the registration nodes in the blockchain distribute registration information, containing verification information corresponding to each hardware device, to all verification nodes in the blockchain (the number of verification nodes is denoted as N); for example... Figure 3 As shown, it specifically includes:

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

[0056] S2: Each challenge signal and the device verification vector of each verification node are used as input to the Hash-Xor-Response (PUF) module to obtain the corresponding real Hash-Xor-Response Rm. Each challenge signal and its corresponding real Hash-Xor-Response constitute a verification message for the current verification node. After processing n challenge signals, all verification messages {C, Rm} between the hardware device and the current verification node are obtained. 1～n ;

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

[0058] S4: Repeat S1-S3 to register different hardware devices and generate all the 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 of verification node i. i The verification information {C,Rm} between each hardware device and verification node i 1～n Other publicly available information.

[0060] Registration information is sent to each verification node via a secure channel in a peer-to-peer manner. Specifically, the registration node User0 first negotiates a key with each verification node, then uses that key to encrypt the registration information using AES symmetric encryption before transmitting it to each node.

[0061] Although each verification node receives the same challenge signal data and in the same order, their device verification vectors (Vector) differ, resulting in different true hash XOR responses (Rm) for the same challenge signal. Upon receiving registration information, each verification node stores the verification information within its own private database and is responsible for protecting its privacy and security. After registration is complete, the hardware device can be traded on 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. User A, as the seller, may sell counterfeit devices and is therefore not trusted; while User B, as the buyer, will pay the price to become the device owner and is responsible for the device, and is the trusted party.

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

[0064] STEP 1: UserB, as a Client, submits a transaction request (the request includes the device ID of the hardware device to be traded) 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 user.

[0065] STEP1 is as follows:

[0066] STEP11: After each verification node receives a transaction request from a user, it checks the registration status of the hardware device based on 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] STEP12: Check the time of the last request issued by the current user based on the historical request information of the hardware device; if the time difference between the last and the current request is less than the preset request time difference (e.g., 5 minutes), then refuse to return the challenge signal; otherwise, proceed to STEP13.

[0068] STEP 13: The current verification node generates the current user's challenge ID, retrieves the corresponding challenge signal from its node database, and returns it to the user. Since each verification node stores verification information in the same order, the generated challenge signal C is also identical. 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] STEP 2: After receiving challenge signals from several verification nodes, the user inputs the challenge signal and corresponding device verification vector from each node into the hash XOR PUF module of the user's hardware device. This yields the actual hash XOR response for each verification node. A transaction message is then formed by the challenge signal from each verification node and the corresponding actual hash XOR response. The user then distributes verification transaction requests containing the transaction information from each verification node to the respective verification nodes. Each verification transaction request includes the device ID and the transaction information {C, Rm} of each verification node. 1～N} and Device Info, where Device Info contains additional information about the device, such as the device owner, remaining lifespan, and other device-related information that may change during use and transactions;

[0071] STEP 3: Each verification node verifies the correctness of the received transaction information through an on-chain smart contract. When a majority of verification nodes pass the verification, the hardware device passes verification and returns the final verification result to the user. The transaction is completed and written into the blockchain, and the device's historical request information and additional device information are also 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 an on-chain smart contract, specifically as follows:

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

[0074] Checking the user's status of acquiring a challenge signal includes checking whether the user has acquired a challenge signal and whether the time difference between acquiring the challenge signal and the current verification response time does not exceed a preset time threshold (e.g., 5 minutes). If both are true, the check passes.

[0075] 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 received actual hash XOR response 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 received actual hash XOR response exceeds 90%, the verification is successful.

[0076] Finally, it should be noted that the above embodiments and descriptions are only used to illustrate the technical solutions of the present invention and not to limit it. Those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the disclosure of the technical solutions of the present invention, and all such modifications and substitutions should be covered within the protection scope 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 aforementioned hardware devices carries a hash XOR PUF module; During the registration phase, the registration node distributes the registration information, which contains 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 received actual hash XOR response, and then generates the final verification result and returns it to the user. During the registration phase, the registration node distributes registration information, containing verification information corresponding to each hardware device, to all verification nodes, including: S1: Randomly generate n challenge signals for each hardware device and assign a device verification vector for each verification node corresponding to that hardware device; S2: Each challenge signal and the device verification vector of each verification node are used as input to the hash XOR PUF module to obtain the corresponding true hash XOR response Rm. Each challenge signal and its corresponding true hash XOR response constitute a verification message for the current verification node. After processing n challenge signals, all verification messages {C, Rm} between the hardware device and the current verification node are obtained. 1~n ; S3: Repeat S2, traverse and process all verification nodes, and obtain all the verification information corresponding to the hardware device and each verification node. S4: Repeat S1-S3 to register different hardware devices and generate all the 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 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 of verification node i. i The verification information {C, Rm} between each hardware device and verification node i. 1~n ; During the transaction phase, the user generates a hash XOR response using 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 received actual hash XOR response, thereby generating the final verification result and returning it to the user, including: STEP 1: 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 on-chain smart contract and returns it to the user; STEP 2: After receiving challenge signals from several verification nodes, the user inputs the challenge signal returned by each verification node and the corresponding device verification vector into the hash XOR PUF module of the user's hardware device to obtain the actual hash XOR response for each verification node. A transaction information is composed of the challenge signal returned by each verification node and the corresponding actual hash XOR response. Then, the user distributes the verification transaction request containing the transaction information of each verification node to the verification nodes respectively. STEP3: Each verification node verifies the correctness of the received transaction information through the on-chain smart contract, 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.

2. The hardware device verification method for a distributed verification system according to claim 1, characterized in that, Each of the aforementioned hardware devices has a hash XOR PUF module comprising a raw PUF module, a hash calculation module, and an XOR gate circuit. The raw 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 to the raw PUF module and the input to the hash calculation module. The device verification vector of each verification node also serves as the input to the hash calculation module. The XOR gate circuit outputs the corresponding hash XOR response.

3. The 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 via a secure channel in a P2P manner.

4. The hardware device verification method for a distributed verification system according to claim 1, characterized in that, STEP1 specifically refers to: STEP11: After each verification node receives a transaction request from a user, it checks the registration status of the hardware device based on 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. STEP12: Check the time of the last request sent by the current user based on the historical request information of the hardware device; if the time difference between the last and the current request time is shorter than the preset request time difference, then refuse to return the challenge signal; otherwise, proceed to STEP13. STEP13: The current verification node generates the 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.

5. The hardware device verification method for a distributed verification system according to claim 1, characterized in that, In STEP3, each verification node verifies the correctness of the received transaction information through an on-chain smart contract, specifically as follows: Each verification node retrieves the historical request information of the hardware device based on the device ID in the transaction information. It then checks the user's status in obtaining the challenge signal based on 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 received actual hash XOR response to obtain the corresponding comparison result. Finally, the verification result corresponding to the verification node is generated based on the comparison result.

6. The hardware device verification method for a distributed verification system according to claim 5, characterized in that, The process of checking the user's status of acquiring a challenge signal includes checking whether the user has acquired a challenge signal and whether the time difference between acquiring the challenge signal and the current verification response time does not exceed a preset time threshold. If both are true, the check passes.

Images