Lightweight vehicle-mounted network data consistency method based on consensus mechanism and medium

Abstract

The invention discloses a lightweight vehicle-mounted network data consistency method based on a consensus mechanism and a medium, and belongs to the technical field of vehicle network security. In the system, a central gateway is pre-registered with a challenge-response pair database of each DCU. When a new block is generated by each DCU, a local vehicle-mounted data set is collected, a hash value of the local vehicle-mounted data set is calculated, and the hash value serves as an excitation input local PUF circuit to generate a unique response value which serves as a block signature and identity authentication basis. And the new block is broadcasted to the whole network through the bus. And the receiving node verifies the validity of the block by using the pre-registered CRP, and adds the new block to the DAG structure according to a preset rule. And multi-block parallel confirmation is realized through topological sorting. According to the invention, the PUF is utilized to realize identity authentication with low computing overhead and high anti-counterfeiting performance, the throughput rate and the real-time performance of vehicle-mounted network data consistency processing are improved in combination with a multi-parent DAG structure, and the method is suitable for a vehicle-mounted control system with limited bandwidth and computing resources.

Description

Technical Field

[0001] This invention relates to the field of vehicle network security technology, specifically to a lightweight in-vehicle network data consistency method and medium based on a consensus mechanism. Background Technology

[0002] In the context of autonomous driving and intelligent connected vehicles, the security threats and challenges facing in-vehicle networks are becoming increasingly severe. The openness and complexity of in-vehicle networks make them vulnerable to external attacks, primarily manifested in data tampering and forgery, denial-of-service attacks, and identity spoofing and leakage. Furthermore, another significant challenge for in-vehicle networks is their real-time requirements. Vehicle control systems are highly sensitive to data transmission latency; any delay can affect driving safety and comfort, especially in autonomous driving systems where network latency can lead to decision-making errors or system failures. Therefore, how to ensure data security while meeting the demands for low latency and high throughput has become a crucial factor that must be considered when designing in-vehicle network security solutions.

[0003] Blockchain technology, with its decentralized, immutable, transparent, and traceable characteristics, has become an effective tool for solving modern cybersecurity problems. The decentralized structure of blockchain allows every participating node in the system to verify transactions and data without relying on a central server, thus reducing the risk of single points of failure; its data immutability ensures that all information cannot be modified once recorded, enhancing data credibility; and its transparency and traceability allow every data interaction in the system to be traced back to its source, providing strong support for security monitoring.

[0004] Based on the characteristics of blockchain and the requirements of in-vehicle networks, we propose a blockchain security consensus mechanism adapted to in-vehicle networks. It uses a Physically Unclonable Function (PUF) to register the identity of trusted Domain Control Units (DCUs) and perform subsequent authentication, and signs and verifies the blocks. Through a time-based multi-parent Directed Acyclic Graph (DAG) on-chain strategy, it supports the simultaneous generation of blocks by different DCUs, ensuring that the in-vehicle network meets the requirements of low latency and high throughput while ensuring data consistency. Summary of the Invention

[0005] The technical problem to be solved by this invention is to overcome the shortcomings of existing vehicle network data consistency schemes in terms of security, real-time performance, and resource consumption, and to provide a vehicle data consistency method and medium based on PUF and multi-parent DAG. By introducing PUF hardware authentication at the data generation node, low computational overhead and high anti-counterfeiting identity authentication are achieved. The DAG multi-parent block structure is used to support parallel data confirmation, thereby improving system throughput and reducing confirmation latency. At the same time, combined with data priority filtering and malicious node punishment mechanism, the security and real-time consistency of the vehicle network are ensured in resource-constrained and highly dynamic environments.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: a lightweight vehicular network data consistency method based on a consensus mechanism, comprising the following steps:

[0007] S1: At the central gateway of the vehicle network, DCU identity registration is performed, a challenge-response pair (CRP) is generated for each DCU and stored in the CRP database. The CRP generation process includes: randomly generating incentive data for identity authentication for each DCU, and obtaining a unique and unpredictable response value through the PUF circuit built into the DCU, thereby establishing a one-to-one correspondence between incentives and responses; based on the CRP, DCUs need to undergo identity authentication before participating in blockchain transactions.

[0008] S2: During operation, the DCU collects local vehicle sensor data, control command data, or other real-time business data sets, calculates the hash value of the data set, and uses the hash value as an excitation input to the PUF circuit to generate a unique PUF response value to ensure the hardware uniqueness and anti-counterfeiting of the data source; based on the PUF response value, a block is constructed containing a direct parent block reference, a timestamp, the data set hash value, and a DCU identifier. The timestamp is used for global sorting and conflict resolution, the parent block reference is used to record data dependencies, and it is broadcast to other nodes in the network through the vehicle communication bus.

[0009] S3: The receiving node compares the PUF response value in the block with the pre-registered response value based on the CRP database, thereby verifying the authenticity of the block's source and the integrity of its content, and preventing illegal nodes from forging data or tampering with the block content.

[0010] S4: If the verification is successful, the block is added to the DAG structure shared by the entire network according to the multi-parent reference rule. The multi-parent reference rule includes selecting at least the generated block on the generating node and the most recently generated block from different nodes as parent blocks to improve the parallelism of block generation and network throughput. The updated DAG is then sorted topologically, and the position of each block in the global order is determined by combining the timestamp information. When it is confirmed that there is no conflict in the dependency relationship and that it has been verified by a majority of nodes, the block is marked as confirmed to ensure the consistency and real-time availability of multi-source data in the vehicle system.

[0011] Furthermore, in S1, the DCU's identity registration and authentication are specifically as follows:

[0012] The central gateway first randomly generates an incentive C. i The stimulus value is selected from a predefined set, and the stimulus C iAfter being transmitted to the DCU node, the data is input to the PUF circuit, which generates a unique response R based on its hardware characteristics. i Response R i Because it is generated based on the physical characteristics of the hardware, it possesses the characteristic of being unclonable. The stimulus C will be... i and response R i The data is combined to form CRP data, and this pair of data will serve as the identity authentication information for the DCU. x C i With R i The data is transmitted to the central gateway. This data is stored in the central gateway node and provides a unique identity verification for subsequent DCU authentication, ensuring that each DCU's identity is unique and cannot be forged.

[0013] When a node begins authentication, it first sets the DCU ID. x The data is sent to the central gateway, which then compares the IDs in the registration database. x Verify its legality. ID x The DCU node used to identify the sending message is rejected during authentication if it does not exist in the database; otherwise, the authentication process continues. Upon receiving a message, the central gateway randomly selects an incentive C corresponding to the DCU based on the pre-stored CRP dataset. i Send to DCU. This stimulus C i The input is fed into the PUF circuit, which generates a unique response R through its hardware characteristics. i The R i After being sent to the central gateway, the system checks if a matching CRP combination exists. If a match is found, it means that the DCU's identity has been authenticated and it can generate blocks; if a match fails, the message is discarded and the node's block generation function is rejected.

[0014] Furthermore, in S2, the collection of local data to generate blocks via PUF and broadcasting specifically involves the following steps:

[0015] Data Collection: The DCU node collects real-time data from the ECUs it manages over a period of time. This data includes the vehicle's operating status, sensor outputs, control commands, etc. Let's assume a time interval... t The data set collected by the DCU node from the various sensors and actuators it controls is called D. t That is: D t = { d 1, d 2,…, d n}in d i Let represent the i-th data point, and n be the number of data points.

[0016] Generate hash value: The DCU node will generate the hash value of the data collected over a period of time. t A fixed-length hash value is generated using a hash function. Since the data may contain different types of sensor information and control commands, and the data volume varies over different time periods, a hash function is needed to output it as a fixed-length data set for easier subsequent processing. The DCU node will then process the data set D... t Converted into a fixed-length hash value using a hash function. H (D t Hash function H This is a common cryptographic hash function (such as SHA-256). The step is represented as: H (D t )=Hash(D t The generated hash value H (D t ) is data D t The unique representation of data set D. If an unauthorized user intercepts the data set D... t If it is then tampered with, the same result will not be generated. H (D t This process ensures that the data set D t Immutability from generation to block generation.

[0017] Using PUF signing: DCU nodes use their PUF function to sign the generated hash data, which is then used by other DCU nodes to verify the legitimacy of the block. The DCU node will then use the generated hash value... H (D t The input is used as an excitation to the PUF circuit, resulting in the response, i.e., the PUF signature R = PUF( H (D t This signature will be added to the block header for block verification.

[0018] Block Structure: The generated block consists of two parts: a block header and a block body. The block header contains the PUF signature (R), the PUF signature of the previous block, and a timestamp. T Block hash H (D t ), DCU ID. The block header is represented as: Block Header={R, Rprev, T , H (D t ), DCU ID}. Block body: Contains data D collected over a period of time. t That is: Block Body = D t .

[0019] Block Broadcast: After block generation is completed, the DCU node will broadcast the new block to other DCU nodes through the vehicle network. Other DCU nodes that have successfully authenticated will verify the block.

[0020] Furthermore, in S3, verifying the identity authenticity and content integrity of the block source specifically involves:

[0021] Verifying the DCU's identity as the block sender: After receiving a broadcast block message, the DCU extracts the DCUID from the block header and sends it to the central gateway. The central gateway compares the DCUID with the data in the registration database to check if it exists. If the ID exists, the block message was sent by a legitimate DCU with block generation capabilities; if the ID does not exist, the subsequent block verification process is rejected.

[0022] Block signature verification: The purpose of verifying the block signature is to confirm whether the block data has been tampered with and whether the block was generated by a legitimate DCU node. Upon receiving a new block, the DCU node first extracts the PUF signature (R) and data hash from the block header. H (D t The data hash is then input into the PUF to generate the corresponding response R'. The received PUF signature R is compared with the generated PUF signature R' to verify whether the signature in the block header is correct. If they match, it means that the block content has not been tampered with and the block was indeed generated by a legitimate DCU node; if they do not match, the block is invalid and must be marked as invalid and rejected.

[0023] Non-repeating verification: The double-spending problem in blockchain refers to an attacker spending the same amount of cryptocurrency multiple times. In the context of in-vehicle networks, attackers may also use replay attacks to continuously generate duplicate blocks, causing rapid growth of the blockchain and excessive resource consumption. Verifying nodes check the timestamps of blocks. T Is it later than the timestamp of the previous block? T prev ,Right now: T > T prev If the time sequence is incorrect, the block is considered invalid.

[0024] Furthermore, in S4, the block is added to the DAG according to the multiple parent reference rule as follows:

[0025] In a Directed Acyclic Graph (DAG) structure, a block needs to be added to the DAG by selecting two parent blocks. One parent block is the last block generated by the DCU that generated the current block, and the other parent block is the most recently generated block from a different DCU. In this way, a new block is added to the DAG structure based on timestamp order, ensuring that all events are recorded in true chronological order.

[0026] Compared with the prior art, the present invention has the following beneficial effects:

[0027] This invention utilizes PUF to generate unique and unpredictable hardware response values ​​to replace traditional public-private key signatures, avoiding computationally complex encryption operations, reducing the processing burden on the vehicle controller, and eliminating the risk of key storage leakage.

[0028] By introducing a multi-parent DAG structure to support the parallel generation and confirmation of blocks, the performance bottleneck of the single-chain structure is overcome, and the confirmation delay is significantly shortened while ensuring data consistency, thus meeting the real-time requirements of high-frequency interaction in vehicle networks.

[0029] The PUF response value is strongly bound to the hash value of the data set. Once the data is tampered with or the node identity is forged, the verification process will inevitably fail, thus effectively resisting the injection of illegal nodes and malicious data and ensuring the credibility of multi-source data in the vehicle system. Attached Figure Description

[0030] Figure 1 A flowchart illustrating a lightweight vehicular network data consistency method and medium based on a consensus mechanism, provided for the implementation of this invention;

[0031] Figure 2 A schematic diagram of PUF-based node registration and authentication provided for the implementation of this invention;

[0032] Figure 3 A schematic diagram of the block structure provided for the implementation of this invention;

[0033] Figure 4 A schematic diagram of a DAG structure provided for the implementation of this invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0035] The core of this invention is to provide a lightweight in-vehicle network data consistency method and medium based on a consensus mechanism. It utilizes PUF to achieve low computational overhead and high anti-counterfeiting identity authentication, and combines a multi-parent DAG structure to improve the throughput and real-time performance of in-vehicle network data consistency processing. It is suitable for in-vehicle control systems with limited bandwidth and computing resources.

[0036] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0037] Figure 1 is a flowchart of a lightweight vehicular network data consistency method and medium based on a consensus mechanism provided by an embodiment of the present invention. The method mainly includes the following steps:

[0038] S1: Identity registration and authentication.

[0039] Identity authentication is the first step in the consensus process. Only nodes that have registered and successfully authenticated through PUF can participate in the consensus process.

[0040] Specifically, as shown in Figure 2, in this embodiment, the central gateway first randomly generates an stimulus C. i The stimulus value is selected from a predefined set, and the stimulus C i After being transmitted to the DCU node, the data is input to the PUF circuit, which generates a unique response R based on its hardware characteristics. i Response R i Because it is generated based on the physical characteristics of the hardware, it possesses the characteristic of being unclonable. The stimulus C will be... i and response R i The data is combined to form CRP data, and this pair of data will serve as the identity authentication information for the DCU. x C i With R i The data is transmitted to the central gateway. This data is stored in the central gateway node and provides a unique identity verification for subsequent DCU authentication, ensuring that each DCU's identity is unique and cannot be forged.

[0041] When a node begins authentication, it first sets the DCU ID. x The data is sent to the central gateway, which then compares the IDs in the registration database. x Verify its legality. ID x The DCU node used to identify the sending message is rejected during authentication if it does not exist in the database; otherwise, the authentication process continues. Upon receiving a message, the central gateway randomly selects an incentive C corresponding to the DCU based on the pre-stored CRP dataset. i Send to DCU. This stimulus C i The input is fed into the PUF circuit, which generates a unique response R through its hardware characteristics. i The R iAfter being sent to the central gateway, the system checks if a matching CRP combination exists. If a match is found, it means that the DCU's identity has been authenticated and it can generate blocks; if a match fails, the message is discarded and the node's block generation function is rejected.

[0042] S2: Collect local data, generate a signed block via PUF, and broadcast it.

[0043] Data Collection: The DCU node collects real-time data from the ECUs it manages over a period of time. This data includes the vehicle's operating status, sensor outputs, control commands, etc. Let's assume a time interval... t The data set collected by the DCU node from the various sensors and actuators it controls is called D. t That is: D t = { d 1, d 2,…, d n}in d i Let represent the i-th data point, and n be the number of data points.

[0044] Generate hash value: The DCU node will generate the hash value of the data collected over a period of time. t A fixed-length hash value is generated using a hash function. Since the data may contain different types of sensor information and control commands, and the data volume varies over different time periods, a hash function is needed to output it as a fixed-length data set for easier subsequent processing. The DCU node will then process the data set D... t Converted into a fixed-length hash value using a hash function. H (D t Hash function H This is a common cryptographic hash function (such as SHA-256). The step is represented as: H (D t )=Hash(D t The generated hash value H (D t ) is data D t The unique representation of data set D. If an unauthorized user intercepts the data set D... t If it is then tampered with, the same result will not be generated. H (D t This process ensures that the data set D t Immutability from generation to block generation.

[0045] Using PUF signing: DCU nodes use their PUF function to sign the generated hash data, which is then used by other DCU nodes to verify the legitimacy of the block. The DCU node will then use the generated hash value... H (Dt The input is used as an excitation to the PUF circuit, resulting in the response, i.e., the PUF signature R = PUF( H (D t This signature will be added to the block header for block verification.

[0046] Block Structure: The generated block consists of two parts: a block header and a block body. Specifically, as shown in Figure 3, the block header includes the PUF signature R, the PUF signature of the previous block, and a timestamp. T Block hash H (D t ), DCU ID. The block header is represented as: Block Header={R, Rprev, T , H (D t ), DCU ID}. Block body: Contains data D collected over a period of time. t That is: Block Body = D t .

[0047] Block Broadcast: After block generation is completed, the DCU node will broadcast the new block to other DCU nodes through the vehicle network. Other DCU nodes that have successfully authenticated will verify the block.

[0048] S3: Verify the authenticity of the block's origin and the integrity of its content.

[0049] Verifying the DCU's identity as the block sender: After receiving a broadcast block message, the DCU extracts the DCUID from the block header and sends it to the central gateway. The central gateway compares the DCUID with the data in the registration database to check if it exists. If the ID exists, the block message was sent by a legitimate DCU with block generation capabilities; if the ID does not exist, the subsequent block verification process is rejected.

[0050] Block signature verification: The purpose of verifying the block signature is to confirm whether the block data has been tampered with and whether the block was generated by a legitimate DCU node. Upon receiving a new block, the DCU node first extracts the PUF signature (R) and data hash from the block header. H (D t The data hash is then input into the PUF to generate the corresponding response R'. The received PUF signature R is compared with the generated PUF signature R' to verify whether the signature in the block header is correct. If they match, it means that the block content has not been tampered with and the block was indeed generated by a legitimate DCU node; if they do not match, the block is invalid and must be marked as invalid and rejected.

[0051] Non-repeating verification (preventing double-spending): In blockchain, double-spending refers to an attacker spending the same amount of cryptocurrency multiple times. In the context of in-vehicle networks, attackers may also use replay attacks to continuously generate duplicate blocks, causing rapid growth of the blockchain and excessive resource consumption. Verifying nodes check the timestamps of blocks. T Is it later than the timestamp of the previous block? T prev ,Right now: T > T prev If the time sequence is incorrect, the block is considered invalid.

[0052] S4: Add the block to the DAG according to the multiple parent reference rule.

[0053] In a DAG structure, each new block can point to two predecessor blocks, instead of a single preceding block as in a chained blockchain. Multiple DCUs can generate new blocks simultaneously and connect them in parallel to the DAG structure by pointing to different predecessor blocks. This design allows the system to verify and generate blocks in parallel across the network, thereby improving throughput.

[0054] In a Directed Acyclic Graph (DAG) structure, a block needs to be added to the DAG by selecting two parent blocks. One parent block is the last block generated by the DCU that generated the current block, and the other parent block is the most recently generated block from a different DCU. In this way, a new block is added to the DAG structure based on timestamp order, ensuring that all events are recorded in true chronological order.

[0055] The foregoing has provided a detailed description of a lightweight vehicular network data consistency method and medium based on a consensus mechanism, as provided by this invention. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably.

Claims

1. A lightweight data consistency method for vehicular networks based on a consensus mechanism, characterized in that, Includes the following steps: S1: At the central gateway of the vehicle network, DCU identity registration is performed, and a CRP is generated for each DCU and stored in the CRP database. The CRP generation process includes: randomly generating incentive data for identity authentication for each DCU, and obtaining a unique and unpredictable response value through the PUF circuit built into the DCU, thereby establishing a one-to-one correspondence between incentives and responses; based on the CRP, DCUs need to undergo identity authentication before participating in blockchain transactions. S2: During operation, the DCU collects local vehicle sensor data, control command data, or other real-time business data sets, calculates the hash value of the data set, and uses the hash value as an excitation input to the PUF circuit to generate a unique PUF response value. Based on the PUF response value, a block is constructed containing a direct parent block reference, a timestamp, the data set hash value, and a DCU identifier. The timestamp is used for global sorting and conflict resolution, the parent block reference is used to record data dependencies, and the block is broadcast to other nodes in the network through the vehicle communication bus. S3: The receiving node compares the PUF response value in the block with the pre-registered response value based on the CRP database to verify the authenticity of the block's source and the integrity of its content; S4: If the verification is successful, add the block to the DAG structure shared by the entire network according to the multi-parent reference rule. The multi-parent reference rule includes selecting at least the generated block on the generating node and the most recently generated block from different nodes as parent blocks; perform topological sorting on the updated DAG, determine the position of each block in the global order by combining the timestamp information, and mark the block as confirmed when it is confirmed that there is no conflict in the dependency relationship and it has been verified by a majority of nodes.

2. The method as described in claim 1, characterized in that, In S1, the central gateway sends multiple random stimulus data to each DCU through a secure channel during the registration phase, collects and records the response values ​​generated by its PUF circuit, forms a unique CRP set, and stores it in the CRP database in an encrypted manner to prevent man-in-the-middle attacks or replay attacks during subsequent verification processes.

3. The method as described in claim 1, characterized in that, The S2 further includes performing real-time priority judgment on the data set according to preset task and message priority rules. Only when the priority of the data set reaches or exceeds a preset threshold will it be constructed into a block and participate in consensus, so as to reduce the transmission burden of low-value data in the network and improve the processing efficiency of key security information and control commands.

4. The method as described in claim 1, characterized in that, If verification fails in S3, the receiving node determines that the block is invalid; broadcasts the block header information of the invalid block to the entire network so that other nodes can synchronously remove the block and execute a scoring penalty on the DCU that generated the block. When the accumulated penalty score reaches a preset threshold, the central gateway or network scheduling module will blacklist the DCU, prohibiting it from generating new blocks for a certain period of time, thereby reducing the continuous interference of malicious nodes on the system.

5. The method as described in claim 1, characterized in that, The topological sorting in S4 incorporates block timestamps during the sorting process. When different DCUs generate concurrent blocks with the same timestamp, the DAG structure allows multiple blocks to exist in different units at the same time. The sorting ambiguity is resolved by following the parent block reference path, thereby ensuring the consistency and traceability of data processing.

6. A non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method as claimed in any one of claims 1 to 5.

Images