A lightweight consensus mechanism-based vehicle-mounted network data consistency method and medium

Abstract

The application discloses a kind of based on consensus mechanism's lightweight vehicle-mounted network data consistency method and medium, belong to vehicle network security technical field.The central gateway in the system pre-registers the challenge-response pair database of each DCU.Each DCU generates new block when, collect local vehicle-mounted data set, calculate its hash value, the hash value is as incentive input local PUF circuit generates unique response value, as block signature and identity authentication basis.New block is broadcast to whole network through bus.Receiving node verifies block legality using pre-registered CRP, and adds new block to DAG structure according to preset rule.Topological sorting is used to realize multi-block parallel confirmation.The application uses PUF to realize low computing overhead, high anti-fake identity authentication, combined with multi-parent DAG structure to improve the throughput and real-time performance of vehicle-mounted network data consistency processing, suitable for bandwidth and computing resource limited vehicle control system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle network security, in particular to a lightweight vehicle network data consistency method based on a consensus mechanism and a medium. BACKGROUND

[0002] Under the background of automatic driving and intelligent connected vehicles, the security threats and challenges faced by vehicle networks are also increasingly severe. The openness and complexity of vehicle networks make them vulnerable to external attacks, mainly manifested in data tampering and forgery, denial of service attacks, and identity forgery and leakage. In addition, another important challenge faced by vehicle networks is the real-time requirement. Vehicle control systems are very sensitive to data transmission latency, and any delay can affect driving safety and comfort, especially in automatic driving systems, network latency can cause decision-making errors or system failures. Therefore, how to ensure data security while meeting the demand for low latency and high throughput is an important factor that must be considered when designing vehicle network security solutions.

[0003] Blockchain technology, with its characteristics of decentralization, tamper resistance, transparency, and traceability, has become an effective tool for solving modern network security problems. The decentralized structure of blockchain enables each participating node in the system to verify transactions and data without relying on a central server, thereby reducing the risk of single point failure; its data tamper resistance ensures that all information once recorded cannot be modified, enhancing the credibility of the data; and the transparency and traceability of the system enable each data interaction to be traced back to the source, providing strong support for security monitoring.

[0004] Based on the characteristics of blockchain and the requirements of vehicle networks, we propose a blockchain security consensus mechanism suitable for vehicle networks, which registers and authenticates trusted domain control units (DCUs) through physical unclonable functions (PUFs), signs and verifies blocks, and supports different DCUs to generate blocks simultaneously through a time-based multi-parent directed acyclic graph (DAG) chaining strategy, ensuring that the vehicle network meets the requirements of low latency and high throughput while ensuring data consistency. SUMMARY

[0005] The technical problem to be solved by the present application is to overcome the shortcomings of existing vehicle network data consistency solutions in terms of security, real-time performance, and resource consumption, and to provide a vehicle data consistency method based on PUF and multi-parent DAG, which realizes low-computing-overhead and high-anti-fake identity authentication by introducing PUF hardware authentication in data generation nodes, and supports parallel data confirmation using DAG multi-parent block structure, thereby improving system throughput and reducing confirmation delay, while combining data priority screening and malicious node punishment mechanism to ensure the security and real-time consistency of vehicle networks in resource-constrained and high-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 iThe transmitted to the DCU node input to the PUF circuit, PUF circuit through its hardware characteristics generated a unique response R i . Response R i Since it is based on the hardware physical characteristics generated, thus has the characteristics of unclonable. The incentive C i and response R i Combination of CRP data, the pair of data will be as the identity authentication information of DCU. ID x , C i and R i Transmitted to the central gateway. The data is stored in the central gateway node, in subsequent DCU identity authentication when providing a unique identity, to ensure that each DCU identity is unique and can not be forged.

[0013] The node begins to carry out identity authentication, first send the DCU ID x To the central gateway, the central gateway by searching the registration database ID x Confirm its legitimacy. ID x For identifying the DCU node sending message, if it does not exist in the database, the identity authentication process of the DCU is refused; if it exists, the verification process continues. After receiving the message, the central gateway randomly selects an incentive C i According to the pre-stored CRP data set, send to the DCU. The incentive C i Input to the PUF circuit, PUF circuit through its hardware characteristics generated a unique response R i . The R i Sent to the central gateway, find out if there is a matching CRP combination. If the match is successful, it means that the identity of the DCU has been authenticated, and the block can be generated; if the match fails, the message is discarded, and the block generation function of the node is refused.

[0014] Further, in S2, the local data collected through PUF generated block and broadcasted specifically as follows:

[0015] Data collection: DCU node from its management ECU collects real-time data within a period of time. These data include the running state of the vehicle, sensor output, control instruction, etc. Set at time t , DCU node from its control of each sensor and actuator collected data set D t , namely: D t = { d 1, d 2,…, d n} Where d i Indicates the i-th data point, n is the number of data points.

[0016] Generate hash value: DCU node will generate a hash value from the data D t collected in a period of time. Since the data can contain different types of sensor information and control instructions, and the amount of data varies in different time periods, a hash function is used to output a fixed number of bytes of data for subsequent processing. The DCU node will collect data D t and convert it into a fixed-length hash value through a hash function H . t The hash function H is a common cryptographic hash function (such as SHA-256). This step is represented as: H (D t )=Hash(D t ) where the hash value H (D t ) generated by the hash function t is a unique representation of the data D t . If an illegal user tampers with the data set D H after intercepting it, it will not be able to generate the same t (D t ), which ensures the tamper-proof nature of the data set D before it is produced into a block.

[0017] H PUF signature: The DCU node will use its PUF function to sign the generated hash data, which will be used by other DCU nodes to verify the legitimacy of the block. The DCU node will input the generated hash value t (D H ) into the PUF circuit as a stimulus and obtain the response, i.e. the PUF signature R = PUF( t (D )). This signature will be added to the block header of the block for block verification.

[0018] T Block structure: The generated block contains two parts, the block header and the block body. The block header contains the PUF signature R, the previous block PUF signature, the timestamp H , the block hash t (D T ), and the DCU ID. The representation of the block header is: Block Header = {R, Rprev, H , t (D t ), DCU ID}. The block body contains the data D t collected in a period of time, i.e. Block Body = D .

[0019] Block broadcast: after completing block generation, the DCU node broadcasts the new block to other DCU nodes through the vehicle network, and other DCU nodes that have successfully authenticated their identities will verify the block.

[0020] Further, in S3, the identity authenticity and content integrity of the block source are verified, specifically:

[0021] Verify the identity of the DCU sending the block: after receiving the broadcast block message, the DCU extracts the DCU ID from the block header and sends it to the central gateway. The central gateway compares the data in the registration database to check whether the DCU ID exists. If the ID exists, the block message is sent by a legal DCU with block generation function; if the ID does not exist, the subsequent block verification process is rejected.

[0022] Verify the block signature: the purpose of verifying the block signature is to confirm whether the block data has been tampered with and whether the block has been generated by a legal DCU node. After receiving the new block, the DCU node first extracts the PUF signature R and data hash H (D t from the block header, then inputs the data hash into the PUF to generate the corresponding response R'. By comparing the received PUF signature R with the generated PUF signature R', it is verified whether the signature in the block header is correct. If the comparison is consistent, it means that the block content has not been tampered with, and the block has indeed been generated by a legal DCU node; if it is not consistent, the block is illegal and needs to be marked as an invalid block and rejected.

[0023] Non-repetitive verification: the double-spend problem in the blockchain refers to the behavior of an attacker spending the same digital currency multiple times. In the context of the vehicle network, an attacker may also use a replay attack to continuously generate repeated blocks, causing rapid growth and resource consumption of the blockchain. The verification node checks whether the timestamp T of the block is later than the timestamp T prev of the previous block, i.e.: T > T prev If the time sequence is incorrect, the block is considered illegal.

[0024] Further, in S4, the block is added to the DAG according to the multi-parent reference rule, specifically:

[0025] In the DAG structure, the block needs to select two parent blocks to connect when it is added to the DAG structure. One of the parent blocks is the last block generated by the DCU that generated the 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 through timestamp sorting, ensuring that all events are recorded in the correct chronological order.

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

[0027] The present application uses PUF to generate a unique and unpredictable hardware response value to replace the traditional public-private key signature, avoids high computational complexity encryption operations, reduces the processing burden of the vehicle controller, and eliminates the risk of key storage leakage.

[0028] By introducing a multi-parent DAG structure to support parallel block generation and confirmation, the performance bottleneck of the single-chain structure is broken through, the confirmation delay is significantly shortened while ensuring data consistency, and the real-time demand of high-frequency interaction of the vehicle network is adapted.

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

[0030] Figure 1 A flowchart of a lightweight vehicle network data consistency method and medium based on a consensus mechanism provided for the implementation of the present application;

[0031] Figure 2 A node registration and authentication schematic diagram based on PUF provided for the implementation of the present application;

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

[0033] Figure 4 A DAG structure schematic diagram provided for the implementation of the present application. DETAILED DESCRIPTION

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

[0035] The core of the present application is to provide a lightweight vehicle network data consistency method and medium based on a consensus mechanism, to realize low computational overhead and high anti-fake identity authentication by using PUF, to improve the throughput rate and real-time performance of vehicle network data consistency processing by combining a multi-parent DAG structure, and to be suitable for vehicle control systems with limited bandwidth and computational 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, it is checked whether there is a matching CRP combination. If a match is successful, it means that the identity of the DCU has been authenticated, and a block can be generated; if a match fails, the message is discarded, and the block generation function of the node is rejected.

[0042] S2: Collect local data, generate signature block through PUF, and broadcast.

[0043] Data collection: The DCU node collects real-time data from the ECUs it manages over a period of time. These data include the running state of the vehicle, sensor output, control instructions, etc. Let t t be the time at which the DCU node collects data from each sensor and actuator it controls. The set of data collected by the DCU node is D t , i.e.: D t = { d 1, d 2,…, d n} where d i represents the i-th data point, and n is the number of data points.

[0044] Generating a hash value: The DCU node generates a fixed-length hash value from the data D t collected over a period of time through a hash function. Since the data may contain different types of sensor information and control instructions, and the amount of data varies over different time periods, a hash function is used to output a fixed number of bytes of data for subsequent processing. The DCU node will convert the data set D t into a fixed-length hash value H (D t ) through a hash function. The hash function H is a common cryptographic hash function (such as SHA-256). This step is represented as: H (D t )=Hash(D t ) The hash value H (D t ) generated by the hash function t is a unique representation of the data D t . If an illegal user tampers with the data set D H after intercepting it, it will not be able to generate the same t (D t ), which ensures the tamper-proof nature of the data set D before it is produced to generate a block.

[0045] Signing with PUF: The DCU node will use its PUF function to sign the generated hash data for subsequent verification of the legality of the block by other DCU nodes. The DCU node will generate a hash value H (Dt ) as the stimulus input into the PUF circuit, the response, i.e. the PUF signature R = PUF (D) is obtained H (D t )) which will be added into the block header of the block for block verification.

[0046] Block structure: the generated block contains two parts, block header and block body. Specifically, as shown in FIG. 3, the block header contains the PUF signature R, the previous block PUF signature, the timestamp T (D H (D t ), DCU ID. The representation of the block header is: Block Header = {R, Rprev, T , H (D t ), DCU ID}. Block body: contains the data D t collected in a period of time, i.e. Block Body = D t .

[0047] Block broadcast: after the block generation is completed, the DCU node broadcasts the new block to other DCU nodes through the vehicle-mounted network, and the other DCU nodes with successful identity authentication will verify the block.

[0048] S3: verify the identity authenticity and content integrity of the block source.

[0049] Verify the identity of the DCU sending the block: after receiving the broadcasted block message, the DCU extracts the DCU ID from the block header and sends it to the central gateway. The central gateway compares the data in the registration database to retrieve whether the DCU ID exists. If the ID exists, the block message is sent by a legal DCU with block generation function; if the ID does not exist, the subsequent block verification process is rejected.

[0050] Verify the block signature: the purpose of verifying the block signature is to confirm whether the block data is tampered with and whether the block is generated by a legal DCU node. After receiving the new block, the DCU node first extracts the PUF signature R and the data hash H (D t ) from the block header, and then inputs the data hash into the PUF to generate the corresponding response R'. By comparing the received PUF signature R with the generated PUF signature R', it is verified whether the signature in the block header is correct. If the comparison is consistent, it means that the block content has not been tampered with, and the block is indeed generated by a legal DCU node; if it is not consistent, the block is illegal and needs to be marked as an invalid block and rejected.

[0051] Non-repetitive verification (to prevent double-spending problem): The double-spending problem in the blockchain refers to the behavior of an attacker spending the same digital currency multiple times. In the context of vehicular networks, an attacker may also use a replay attack to continuously generate duplicate blocks, causing rapid growth and resource consumption of the blockchain. The verification node will check whether the timestamp of the block is later than the timestamp of the previous block T T prev That is: T > T prev If the time sequence is wrong, the block is considered illegal.

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

[0053] In the DAG structure, each new block can point to two predecessor blocks, rather than only pointing to a unique previous block as in the chain-based blockchain. Multiple DCUs can generate new blocks at the same time and connect them to the DAG structure in parallel by pointing to different predecessor blocks. This design allows the system to verify and generate blocks in parallel in the network, thereby improving throughput.

[0054] In the DAG structure, a block needs to select two parent blocks to connect when being added to the DAG structure. One of the parent blocks is the last block generated by the DCU that generates the block, and the other parent block is the most recently generated block on a different DCU. In this way, a new block is added to the DAG structure by sorting the timestamps, ensuring that all events are recorded in the true time sequence.

[0055] The above describes in detail a lightweight vehicular network data consistency method and medium based on a consensus mechanism provided by the present application. The embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts of each embodiment can be mutually referenced.​

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