A vehicle networking trust management system and method

Abstract

The application discloses a kind of Internet of Vehicles trust management system and method, belong to Internet of Vehicles technical field, system includes vehicle, roadside unit, trusted agency, and based on edge layer blockchain and core layer blockchain of super account book;Vehicle is interacted with edge layer blockchain by network entry certificate;Roadside unit of edge layer, by network entry certificate and endorsement certificate, upload information management edge layer super account book of vehicle trust account book and interact with core layer trusted agency data;Vehicle trust account book records vehicle trust condition, and the change of vehicle trust account book is endorsed by single roadside unit;Trusted agency of core layer, management core layer super account book's certificate account book and roadside unit trust account book;Certificate account book records the certificate condition of vehicle and roadside unit, and roadside unit trust account book records roadside unit trust condition.The application can solve the problem that Internet of Vehicles lacks cross-regional data consistency, and improve the efficiency and security of Internet of Vehicles trust management.

Description

Technical Field

[0001] This invention belongs to the field of vehicle networking technology, specifically relating to a vehicle networking trust management system and method. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, the exchange of information between vehicles has become increasingly frequent and crucial. This information exchange is not only essential for improving road safety but also for optimizing traffic flow and enhancing the driving experience. However, this increased information exchange also brings significant security and privacy challenges. Protecting data security and user privacy during these exchanges has become an urgent issue to address.

[0003] In a connected vehicle environment, vehicles can share critical information such as location, speed, driving behavior, road conditions, and emergency actions. This information is crucial for improving road safety, optimizing traffic flow, and enhancing the driving experience. However, this data contains a large amount of sensitive information, such as location data, identity information, communication content, and user behavior data. Therefore, vehicle information must be anonymized to protect privacy. Furthermore, data security issues in connected vehicles are becoming increasingly prominent.

[0004] Malicious vehicles may send false information or deliberately discard data packets, causing data forwarding failures. These behaviors not only undermine the reliability and efficiency of the network but may also pose a serious threat to road safety. Specifically, malicious behaviors include, but are not limited to: (1) Spreading false information: Attackers may deliberately spread incorrect data, such as providing inaccurate location information or false road condition updates, misleading other vehicles' driving decisions and thus increasing the risk of traffic accidents. (2) Interfering with data transmission: Malicious vehicles may deliberately ignore forwarding received data packets or tamper with them during data transmission. This behavior will cause information to be inaccurately transmitted, affecting the efficiency of the entire traffic management system and the coordinated operation between vehicles.

[0005] Given these challenges, developing a vehicle-to-everything (V2X) trust management approach that ensures data security, maintains the authenticity and integrity of information, and protects user privacy is of paramount importance. This approach will help enhance the credibility of V2X systems, strengthen user confidence, and safeguard public safety.

[0006] In a vehicle-to-everything (V2X) environment, information transmission between vehicles must ensure the authenticity, integrity, and privacy of messages to prevent malicious attacks and information tampering. Cryptographic methods can guarantee the legitimacy of data sources, but they cannot solve the problem of legitimate vehicles being manipulated. Trust management, on the other hand, effectively solves this problem by evaluating the data transmission behavior of different vehicles, calculating trust values ​​for each vehicle, and blacklisting vehicles with low trust values. However, traditional distributed trust management has the following drawbacks: lack of cross-regional data consistency, slow trust value generation speed, and failure to fully utilize the computing resources of trusted sources (such as roadside units). Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide a vehicle network trust management system and method to solve the problem of lack of cross-regional data consistency in vehicle networks and improve the efficiency and security of vehicle network trust management.

[0008] To solve the above-mentioned technical problems, the present invention is implemented using the following technical solution:

[0009] In a first aspect, the present invention provides a vehicle-to-everything (V2X) trust management system, comprising vehicles, roadside units, trusted institutions, and an edge layer blockchain and a core layer blockchain based on a hyperledger. The vehicles interact with the edge layer blockchain through access certificates issued by the trusted institutions. The roadside units, as edge layer nodes of the blockchain, upload information to manage the vehicle trust ledger in the edge layer hyperledger and interact with data from the core layer trusted institutions through access certificates and endorsement certificates issued by the trusted institutions. The vehicle trust ledger records vehicle trust status, and changes to the vehicle trust ledger are endorsed by individual roadside units. The trusted institutions, as core layer nodes of the blockchain, manage the certificate ledger and the roadside unit trust ledger in the core layer hyperledger. The certificate ledger records the certificate status of vehicles and roadside units, and the roadside unit trust ledger records the trust status of roadside units.

[0010] Secondly, the present invention provides a vehicle network trust management method, based on the vehicle network trust management system of the first aspect, comprising:

[0011] S1: Initialize the vehicle network trust management system, and the trusted institution issues network access certificates and endorsement certificates to the roadside units that join the network;

[0012] S2: Verify the identity of vehicles entering the network for the first time, and apply for a pseudonym and network access certificate from a trusted institution;

[0013] S3: Perform trust management on the vehicles that joined the network in step S2 and the roadside units that joined the network in step S1 respectively;

[0014] The trust management in step S3 includes: repeatedly executing step S3, canceling the network access qualification of a malicious vehicle when it is determined that the vehicle is malicious; canceling the endorsement qualification of a roadside unit when it is determined that the roadside unit has uploaded incorrect information; and canceling the network access qualification of a roadside unit when it is determined that the roadside unit is malicious.

[0015] The aforementioned vehicle-to-everything (V2X) trust management method, in step S3, includes trust management of the vehicle that joined the network in step S2, which includes:

[0016] C1: The trust values ​​of vehicles entering the network are calculated among themselves, and the global trust values ​​of vehicles entering the network are calculated by roadside units;

[0017] C2: Integrate the trust value calculated in step C1, calculate the final trust value of the vehicle finally entering the network, and determine whether the vehicle entering the network is a malicious vehicle based on the preset final trust value threshold.

[0018] Step C1 involves the following steps: Other vehicles calculating the trust value of each other.

[0019] CC11: Vehicles that directly interact with vehicle j calculate their direct trust value for vehicle j based on their direct interaction records with vehicle j, and upload the calculated direct trust value to the vehicle trust ledger through the roadside unit.

[0020] CC12: For vehicles that do not directly interact with vehicle j, the indirect trust value for vehicle j is calculated based on the direct trust value provided by vehicles that directly interact with vehicle j in the vehicle trust ledger, and then uploaded to the vehicle trust ledger via the roadside unit.

[0021] In the aforementioned vehicle-to-everything (V2X) trust management method, step CC11, calculating direct trust in vehicle j, includes:

[0022] CC111: Vehicles that directly interact with vehicle j calculate vehicle j's transmission reliability, forgetting factor, and cooperation metric based on their direct interaction records with vehicle j; vehicle i is a vehicle that has directly interacted with vehicle j, and at the current time t, vehicle i calculates vehicle j's transmission reliability. The calculation formula is:

[0023] ,

[0024] In the formula, This represents the number of times vehicle j has successfully forwarded data packets, accumulated from the initial time to time t, as recorded by vehicle i. This represents the total number of data packets sent by vehicle i to vehicle j, accumulated from the initial time to time t. Successful forwarding of a data packet means that the data packet forwarded by vehicle j is complete and has not been tampered with. and The data comes from the direct interaction records between vehicle i and vehicle j;

[0025] At current time t, calculate the forgetting factor for vehicle j using vehicle i. The calculation formula is:

[0026] ,

[0027] In the formula, For the interaction moment, the data comes from the direct interaction records between vehicle i and vehicle j; The preset forgetting coefficient;

[0028] At current time t, vehicle i calculates the cooperation metric for vehicle j. The calculation formula is:

[0029] ,

[0030] In the formula, M represents the number of vehicles that have directly interacted with vehicle j from the initial time to time t; M represents the total number of vehicles in the vehicle network. This represents the maximum number of data packets forwarded by a single vehicle from the initial time to time t. This represents the number of data packets forwarded by vehicle j from the initial time to time t. M and The data comes from the vehicle networking system;

[0031] CC112: Based on the transmission reliability, forgetting factor and cooperation metric of vehicle j obtained in step CC111, calculate the direct trust value of the vehicle interacting with vehicle j to vehicle j.

[0032] At current time t, vehicle i calculates the direct trust value of vehicle j. The calculation formula is:

[0033] ,

[0034] In the formula, This is a preset transmission reliability weighting coefficient;

[0035] CC113: The vehicle pseudonym and the corresponding direct trust value for vehicle j obtained from the interaction between step CC112 and vehicle j are uploaded to the vehicle trust ledger as a vehicle trust table via the roadside unit.

[0036] Step CC12 involves calculating the indirect trust value for vehicle j, including:

[0037] CC121: For vehicles that do not directly interact with vehicle j, calculate the trust similarity between themselves and vehicles that directly interact with vehicle j based on the direct trust values ​​of themselves and vehicles that directly interact with vehicle j regarding the same vehicle.

[0038] Vehicle l is a vehicle that has no direct interaction with vehicle j, vehicle h is a vehicle that has directly interacted with vehicle j, and vehicle x is a vehicle that has directly interacted with both vehicle l and vehicle h. The trust similarity between vehicle l and vehicle h at the current time t is... The calculation formula is:

[0039] ,

[0040] In the formula, Let x be the set of vehicles. Let x be the number of vehicles. Let be the direct trust value of vehicle l for vehicle x. Let h be the direct trust value of vehicle h for vehicle x. For absolute value operations, For summation operations;

[0041] CC122: Based on the trust similarity calculated in step CC121, calculate the trust weight of vehicles that directly interact with vehicle j for vehicles that do not have direct interaction with vehicle j.

[0042] The trust weight of vehicle l to vehicle h at current time t. The calculation formula is:

[0043] ,

[0044] In the formula, Let be the direct trust value between vehicle l and vehicle h. If vehicle l and vehicle h have no direct interaction, then... The value is 0.5;

[0045] CC123: Vehicles that have no direct interaction with vehicle j calculate the indirect trust value for vehicle j based on the trust weight calculated in step CC122.

[0046] The indirect trust value of vehicle l to vehicle j at current time t. The calculation formula is:

[0047] ,

[0048] In the formula, Let h be the set of vehicles. For the number of vehicles h, Let h be the direct trust value between vehicle h and vehicle j;

[0049] CC124: The vehicle trust table, which is the vehicle pseudonym that has no direct interaction with vehicle j in step CC123 and the corresponding indirect trust value for vehicle j, is uploaded to the vehicle trust ledger via the roadside unit.

[0050] In the aforementioned vehicle-to-everything (V2X) trust management method, step C1, in which the roadside unit calculates the global trust value of the vehicle entering the network, includes:

[0051] CL11: The roadside unit selects trusted vehicles from those with zero malicious behavior; the roadside unit sets the initial malicious behavior for vehicles entering the network. =0, ;

[0052] CL12: The trusted vehicle sends a detection packet to the target vehicle. After receiving the detection packet, the target vehicle forwards the detection packet to the roadside unit in step CL11 according to a preset procedure. The preset procedure includes forwarding the detection packet to the roadside unit in step CL11 within a preset time period.

[0053] Current moment Trusted Vehicles To the target vehicle Send detection packet , ,in, It is a detection message; It is the hash value of the detected message; It is a trustworthy vehicle. Use its private key A digital signature is generated by signing the detection message;

[0054] CL13: After a preset duration, the roadside unit verifies the reception status of the detection packets;

[0055] The reception status includes: whether a detection packet is received within a preset time period and whether the received detection packet data is consistent with the content of the sent data packet;

[0056] CL14: If the roadside unit does not receive a detection packet within the preset time period or the content of the received detection packet is inconsistent with the content of the sent data packet, increment the record of the target vehicle's malicious behavior by 1.

[0057] CL15: Repeat steps CL11 to CL14 until the preset time.

[0058] CL16: Calculate the global trust value of vehicles entering the network based on malicious behavior recorded by roadside units;

[0059] Global trust value of vehicle j at current time t. The calculation formula is:

[0060] ,

[0061] In the formula, It represents the number of malicious actions committed by vehicle j from time t-1 to time t. It is the global trust weight from time t-1 to time t. = , This represents the maximum number of malicious actions per vehicle among the vehicles M that joined the network between time t-1 and time t.

[0062] CL17: The roadside unit uploads the target vehicle pseudonym from step CL16 and the corresponding calculated global trust value to the global trust table of the vehicle trust ledger.

[0063] The roadside unit will also upload the recorded malicious behavior to the vehicle trust ledger in the form of a malicious behavior verification code; the malicious behavior verification code includes trusted vehicles that detected the target vehicle. pseudonyms, digital signatures of trusted vehicles and the hash value of the detection message The storage format for malicious behavior verification codes is as follows:

[0064] < The kana>,

[0065] The roadside unit stores the malicious behavior verification code in the target vehicle's global trust table.

[0066] The aforementioned vehicle-to-everything (V2X) trust management method includes the following step C2:

[0067] C21: The final trust value of the vehicle finally joining the network is calculated and uploaded to the vehicle final trust table of the vehicle trust ledger via the roadside unit. This represents the final trust value of vehicle j at time t. The calculation formula is:

[0068] ,

[0069] In the formula, M-1; For vehicles other than vehicle j among the vehicles entering the network, and ; The preset final trust value weighting coefficient; For the vehicle at the current time t... The direct trust value for vehicle j;

[0070] C22: Based on the preset final trust value threshold Determining whether a vehicle joining the network is a malicious vehicle includes:

[0071] like If vehicle j is deemed a malicious vehicle, its current network access qualification is revoked, and its network access certificate is added to the revocation list; if If so, then vehicle j is determined to be a normal vehicle.

[0072] The aforementioned vehicle-to-everything (V2X) trust management method, in step S3, includes trust management of the roadside units that have joined the network in step S1, which includes:

[0073] The system checks the roadside unit's endorsement eligibility by determining whether the roadside unit has uploaded incorrect information to the blockchain based on the vehicle trust ledger and the roadside unit trust ledger. If the system determines that the roadside unit has uploaded incorrect information, the roadside unit's endorsement eligibility is revoked.

[0074] Testing the eligibility of roadside units for network access includes:

[0075] R1: The trusted authority detects whether the roadside unit sends an error message to the trusted authority by comparing data;

[0076] R2: When step R1 detects that the roadside unit sends an error message to the trusted agency, the trusted agency uses the maximum likelihood ratio to detect whether the roadside unit is a malicious roadside unit; when the roadside unit is determined to be a malicious roadside unit, the roadside unit's network access qualification is cancelled.

[0077] The aforementioned vehicle-to-everything (V2X) trust management method, wherein the detection of roadside unit endorsement qualifications includes:

[0078] B1: The trusted institution obtains the malicious behavior verification code recorded in the global trust table of the vehicle trust ledger, and determines whether the roadside unit has forged the vehicle malicious behavior record according to the verification function. If the roadside unit forges the vehicle malicious behavior record, the roadside unit's endorsement qualification is cancelled.

[0079] Retrieve the malicious behavior verification code from the global trust table:

[0080] ,pass Find the corresponding public key from the pseudonym Then according to the verification function The output result is judged;

[0081] If the verification function If the output is True, it indicates that the roadside unit has not forged any malicious vehicle behavior.

[0082] If the verification function The output result is If this indicates that the roadside unit has engaged in malicious behavior by forging vehicles, the trusted institution will revoke the roadside unit's endorsement qualification, add the roadside unit's endorsement certificate to the revocation list, and update the roadside unit's status to the roadside unit trust ledger. The status of the roadside unit includes: revocation of endorsement qualification, revocation of network access qualification, and normal.

[0083] B2: The trusted institution calculates the corresponding roadside unit trust value based on the vehicle trust ledger managed by the roadside unit, and determines whether the roadside unit has uploaded error information to the blockchain based on the roadside unit trust value; Step B2 includes:

[0084] B21: Trusted institutions calculate the trust distance between each roadside unit based on the vehicle trust ledger managed by each roadside unit;

[0085] Current moment roadside unit and roadside units Trust distance The calculation formula is:

[0086] ,

[0087] In the formula, Let t be the roadside unit at the current time. The final trust value of vehicle j is calculated. Let t be the roadside unit at the current time. The final trust value of vehicle j is calculated.

[0088] B22: Based on the trust distance between each roadside unit obtained in step B21, calculate the trust distance between each roadside unit. - Proximity trust distance;

[0089] Current moment roadside unit and roadside units Between - Proximity Trust Distance The calculation formula is:

[0090] = ,

[0091] In the formula, Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the roadside unit. With roadside units Trust distance , and R represents the total number of roadside units in the vehicle-to-everything (V2X) network.

[0092] B23: Based on the information obtained from step B22 regarding the relationships between various roadside units -Nearest trust distance, calculating the distance between each roadside unit. -Nearest trust density;

[0093] Current moment roadside unit of - Neighbor Trust Density The calculation formula is:

[0094] ,

[0095] ,

[0096] ,

[0097] ,

[0098] In the formula, For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The largest of the R-1 trust distance values ​​is that of the roadside unit. With roadside units Trust distance and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the roadside unit. With roadside units Trust distance and ; For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The second largest of the R-1 trust distance values ​​is the trust distance itself. and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. ; For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. ; roadside unit The total number; For reciprocal operations;

[0099] B24: Based on the roadside units obtained in step B23 -Nearest trust density, calculate the corresponding roadside cell trust value;

[0100] Current moment roadside unit Trust value The calculation formula is:

[0101] ,

[0102] In the formula, For the previous moment roadside unit Trust value;

[0103] B25: Based on the trust values ​​of each roadside unit calculated in step B24 and the preset roadside unit trust value threshold. Determine whether the roadside unit has uploaded error information to the blockchain; if Then determine the roadside unit Error information is uploaded to the blockchain, and a trusted organization cancels the roadside unit. The endorsement qualification will be used for roadside units The endorsement certificate is added to the revocation list, and the roadside unit trust value and roadside unit status are updated to the roadside unit trust ledger; if If so, the trusted institution will update the roadside unit trust value to the roadside unit trust ledger.

[0104] The aforementioned vehicle-to-everything (V2X) trust management method includes step R1, which includes:

[0105] R11: Vehicle j establishes a communication connection with the roadside unit and passes through the roadside unit. Send data packets to trusted node c Vehicle j generates authentication parameters based on bitwise XOR operations according to the sent data packets. Authentication parameters The expression is:

[0106] ,

[0107] In the formula, For vehicle j towards the roadside unit The first data packet sent; For vehicle j towards the roadside unit The first one sent One data packet; For vehicle j passing through the roadside unit The binary representation of the total number of data packets sent to the trusted node; For hash functions, It is the private key of vehicle j;

[0108] R12: Vehicle j uses the public key of trusted institution c. The authentication parameters generated in step R11 After encryption, a feedback packet is generated. And when vehicle j enters the coverage area of ​​another roadside unit and establishes communication, it will send a feedback packet. It is sent to a trusted institution c;

[0109] R13: Receiver from roadside unit Data packets sent Feedback packets sent by another roadside unit Then, trusted authority C recalculates the authentication parameters based on the received data packets. and using the trusted institution c's own key Decryption Feedback Packet Obtain authentication parameters ;

[0110] Recalculate authentication parameters The calculation formula is:

[0111] ,

[0112] In the formula, For trusted organization c, via roadside unit The first data packet received; For trusted organization c, via roadside unit The first received One data packet; For trusted organizations to access roadside units The binary representation of the total number of data packets received;

[0113] R14: Trusted node comparison step R13 recalculates authentication parameters Authentication parameters obtained through decryption Whether they are consistent, determine if the error message is caused by the roadside unit; if The error message is from the roadside unit. lead to.

[0114] The aforementioned vehicle-to-everything (V2X) trust management method includes the following step R2:

[0115] R21: Repeat step R1 to collect historical moments. up to the current moment Vehicles connected to the network and roadside units Communication records; communication records include those with roadside units The number of vehicles communicating and the number of times the data packets and feedback packets are inconsistent at each time step R1;

[0116] R22: Based on the number of times the data packets and feedback packets collected in step R21 are inconsistent, construct binomial distributions under the null hypothesis H0 and the alternative hypothesis H1, respectively; the binomial distributions are constructed as follows:

[0117] Under the null hypothesis H0, the probability that the roadside unit is not a malicious entity and the data packet and the feedback packet are inconsistent is: ,time Number of times the data packet and the response packet are inconsistent Obtain the parameter as binomial distribution: In the formula, For a historic moment up to the current moment and roadside units The number of vehicles communicating; ;

[0118] Under alternative assumption H1, the roadside unit at time... The probability that the detected entity is malicious and the data packet is inconsistent with the response packet is: ,time Number of times the data packet and the response packet are inconsistent At any moment Then, it follows the parameter as binomial distribution: ), ;

[0119] R23: Based on the binomial distribution constructed in step R22, calculate the joint probability under the null hypothesis H0 and the alternative hypothesis H1 respectively;

[0120] In roadside units Inconsistencies were observed between data packets and feedback packets at various time points, assuming no malicious intent. joint probability for:

[0121]

[0122] ;

[0123] In roadside units In cases of malicious intent, discrepancies were observed between data packets and feedback packets at various time points. joint probability for:

[0124]

[0125] ;

[0126] R24: Calculate the likelihood ratio statistic based on the joint probability calculated in step R23. Likelihood statistic The calculation formula is:

[0127] ;

[0128] R25: The likelihood ratio statistic calculated based on step R24 and the preset likelihood ratio statistic threshold. To determine whether the error message was caused by malicious behavior of the roadside unit;

[0129] like > Then determine the roadside unit The error message is malicious and is caused by malicious behavior from the roadside unit.

[0130] R26: If step R25 determines that the error message is caused by malicious behavior of the roadside unit, the trusted authority cancels the roadside unit. The qualification for network access will be for roadside units. The network access certificate is added to the revocation list, and the roadside unit status is updated to the roadside unit trust ledger.

[0131] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0132] This invention employs a vehicle-to-everything (V2X) trust management system comprised of vehicles, roadside units, trusted institutions, and edge and core layer blockchains based on Hyperledger. Vehicle certificates are issued by trusted institutions, serving as network access credentials and communication licenses. Roadside unit certificates are also issued by trusted institutions, authorizing them as endorsement nodes in the blockchain edge layer and verifying and signing transactions submitted by vehicles. Both types of certificates undergo full lifecycle management (registration / update / revocation) through the core layer blockchain, enhancing the credibility of V2X communication and trust assessment.

[0133] When vehicles move across regions, roadside units (RSUs) or edge nodes in different geographical areas may experience inconsistencies in key data such as vehicle identity status, trust assessment results, or transaction history due to network latency, ledger synchronization delays, or differences in management domains. This invention employs a layered ledger with collaborative edge and core layers. Edge-layer RSUs rapidly process high-frequency transactions of vehicles within their communication range, while the core-layer trusted institution manages the global certificate lifecycle and cross-regional arbitration, ensuring that all global state changes (such as certificate revocation) achieve immediate network-wide consensus. By utilizing blockchain edge caching combined with incremental synchronization, cross-regional latency is reduced. When a vehicle enters a new region, the new region's RSU queries vehicle information through data interaction with the core layer and pulls data from the old region's RSU. While ensuring cross-regional data consistency, this invention avoids the centralized bottleneck of traditional solutions, solves the problem of lack of cross-regional data consistency in the Internet of Vehicles (IoV), and improves the efficiency and security of IoV trust management.

[0134] The dual-layer blockchain network design of this invention isolates the edge layer and the core layer, improving the security of the Internet of Vehicles (IoV). In the edge layer, which has low security requirements, the RSU (Reliable Unit) is authorized to manage the trust status of vehicles. In the core layer, which has high security requirements, a trusted institution directly manages the trust status of the RSU. The core layer and the edge layer are securely isolated. The edge layer is exempt from sorting overhead and does not need to store complete ledger information, thus meeting the low latency requirements of the IoV.

[0135] The vehicle-to-everything (V2X) trust management method of this invention distinguishes between vehicle and RSU trust management. Vehicle trust management calculates trust values ​​for both the vehicle and the RSU separately, and assesses the vehicle's eligibility for network access based on the final calculated trust value. The RSU trust management method differentiates between endorsement qualification detection and network access qualification detection based on the impact of RSU behavior on the security of the V2X system.

[0136] The vehicle trust value calculation method of this invention includes direct and indirect trust values, and integrates the global trust value calculated by RSU to obtain the final trust value of the vehicle. This method of collecting trust opinions from multiple parties improves the accuracy of vehicle trust value calculation and reduces the risk of error.

[0137] This invention calculates the direct trust value of vehicles through multi-dimensional indicators: it assesses transmission reliability based on the interaction behavior between vehicles; it introduces a forgetting factor to assign higher weight to recent events to reflect the impact of timeliness; and it also filters cooperative vehicles that actively forward messages through cooperation metrics. Finally, it calculates the direct trust value by combining the three indicators. This method significantly improves the accuracy of trust value calculation through multi-angle quantitative evaluation.

[0138] The RSU trust management method of this invention achieves precise protection through hierarchical security control: when a trusted institution detects that an RSU affects the trust calculation of vehicles entering the network, it cancels the endorsement qualification of RSUs that only affect the security of edge layer data but retains the qualification to enter the network, thus isolating risks while maintaining basic services; for malicious RSUs that threaten core layer data, the qualification to enter the network is completely canceled to ensure the security of the global ledger. This design balances system security and availability through differentiated handling, which can quickly isolate risk nodes while avoiding excessive punishment. At the same time, a multi-layered defense system is built through dynamic monitoring by trusted institutions, which effectively improves the overall security protection capability.

[0139] This invention's RSU endorsement qualification detection employs a dual verification mechanism to ensure data reliability: on one hand, it detects whether the RSU has forged a vehicle malicious behavior verification code to identify direct fraudulent behavior; on the other hand, it assesses the historical credibility based on dynamically calculated RSU trust values. This dual criterion design of "behavioral evidence + trust assessment" significantly improves the accuracy of RSU endorsement qualification detection, preventing unilateral misjudgment and forming cross-verification. At the same time, the continuous updating of RSU trust value calculation enables dynamic monitoring of RSU behavior, effectively ensuring the authenticity and credibility of edge layer data uploaded to the blockchain, and maintaining the security of the vehicle network trust management system from the source.

[0140] This invention achieves accurate identification and handling of malicious RSU behavior through a dual verification mechanism: First, a dynamic authentication mechanism using data packets and feedback packets is employed. Vehicles generate authentication parameters through XOR operations and transmit them encrypted. A trusted organization directly identifies the party responsible for data tampering through data comparison. Then, a statistical detection model is constructed based on historical communication data. Binomial probability analysis and likelihood ratio tests are used to quantitatively determine malicious behavior, and a preset threshold is used to objectively identify malicious RSUs. This solution, through a two-layer detection architecture of "real-time data authentication + historical behavior analysis," significantly improves the reliability and security of vehicle-to-everything (V2X) trust management methods. Attached Figure Description

[0141] Figure 1 This is a schematic diagram of the framework of the vehicle network trust management method according to Embodiment 2 of the present invention; Detailed Implementation

[0142] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments and specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations thereof. Where there is no conflict, the embodiments and technical features in the embodiments can be combined with each other. In this document, the character " / " generally indicates that the preceding and following objects have an "or" relationship.

[0143] Example 1:

[0144] This embodiment introduces a vehicle network trust management system, including:

[0145] Vehicles, roadside units, trusted institutions, and edge and core layer blockchains based on Hyperledger;

[0146] The vehicle interacts with the edge blockchain through an access certificate issued by a trusted institution; the vehicle is equipped with an on-board unit with limited computing and storage resources, used to collect and process traffic information in real time, and interact with nearby blockchain entities (roadside units and other vehicles) by calling chaincode through a preset vehicle network communication protocol; when the vehicle first enters the network, it needs to apply for a digital certificate from a trusted institution to obtain a legitimate identity, and in subsequent communications, it uses this certificate to achieve anonymous identity verification (such as a pseudonym certificate) to ensure privacy protection and communication security;

[0147] The Roadside Unit (RSU), acting as a semi-trusted intermediary entity, is located between the vehicle and the trusted institution. It is a node in the blockchain edge layer and uploads information to the edge layer hyperledger (as shown in Table 1) and interacts with the core layer trusted institution through the network access certificate and endorsement certificate issued by the trusted institution. It is responsible for communicating with the vehicle to exchange road information and extend the communication range, while submitting the interaction data to the edge layer blockchain. The vehicle trust ledger records the vehicle trust status, and changes to the vehicle trust ledger are endorsed by a single Roadside Unit.

[0148] Table 1 Vehicle Trust Ledger

[0149]

[0150] The trusted institution, acting as the regulatory gateway for roadside units, is a node in the core layer of the blockchain. It manages the certificate ledger shown in Table 2 of the core layer hyperledger and the roadside unit trust ledger shown in Table 3. It performs the functions of registering, updating, and revoking vehicle certificates, and supervises the behavior of roadside units through the core layer blockchain, ultimately maintaining the consistency of the global trust value. The certificate ledger records the certificate status of vehicles and roadside units, and the roadside unit trust ledger records the trust status of roadside units.

[0151] Table 2 Certificate Ledger

[0152]

[0153] Table 3 Roadside Unit Trust Ledger

[0154]

[0155] A two-layer blockchain is built on Hyperledger Fabric, consisting of an edge layer and a core layer.

[0156] The edge layer consists of roadside units as nodes, responsible for local data collection and preliminary verification (such as trust data uploaded by vehicles); it runs lightweight edge chaincode to handle trust interactions between vehicles and roadside units (such as reputation score updates); key components include clients (vehicles), endorsing nodes (roadside units), and committing nodes, ensuring the consistency of edge layer data. In other words, the edge layer is responsible for real-time trust data collection and local trust consensus between vehicles and roadside units.

[0157] The core layer consists of trusted institutions responsible for global trust management and certificate authority; it runs the core chaincode, managing the certificate lifecycle of vehicles / roadside units and global trust consensus; key components include sorting nodes (responsible for transaction sorting and block generation) and commit nodes (completing the final ledger update). In other words, the core layer is responsible for global certificate management and maintaining trust value consistency.

[0158] Certificate lifecycle management includes:

[0159] Certificate Issuance: A digital certificate is issued to a vehicle when it first joins the network or when a roadside unit is deployed.

[0160] Certificate renewal: Replace certificates periodically (e.g., when a vehicle pseudonym certificate expires);

[0161] Certificate revocation: When an entity (vehicle / roadside unit) behaves abnormally (such as maliciously forging data), its certificate is added to the revocation list.

[0162] Certificate status synchronization: Trusted authorities write newly issued or revoked certificate information into the core layer blockchain, which can be queried in real time by all nodes in the network (including edge layer RSUs).

[0163] The core layer achieves global consensus through sorting nodes, ensuring the consistency of transaction order and ledger state; at the same time, it relies on chaincode logic and certificate issuance mechanism to maintain global consistency of trust values ​​between vehicles and roadside units, ultimately achieving trusted decision-making (such as isolation of malicious vehicles / nodes).

[0164] Roadside units (RSUs) and vehicles communicate and exchange road information according to a pre-defined vehicle-to-everything (V2X) communication protocol, submitting trust data to the edge layer blockchain. Trusted institutions verify the behavior of roadside units through the core layer, respond to certificate requests from vehicles and roadside units, and record the certificate status on the blockchain for network-wide verification. Simultaneously, the Hyperledger Fabric channel mechanism coordinates cross-layer data synchronization: edge layer RSUs submit local trust data to the core layer for aggregation, while the core layer distributes global policies (such as certificate revocation lists) to the edge layer. The system operates collaboratively through a layered architecture, achieving distributed storage, dynamic updates, and secure and efficient V2X communication of trust values.

[0165] Example 2

[0166] Based on the same inventive concept as Embodiment 1, such as Figure 1 As shown, this embodiment introduces a vehicle network trust management method, based on the vehicle network trust management system described in Embodiment 1, including:

[0167] S1: Initialize the vehicle network trust management system, and the trusted institution issues network access certificates and endorsement certificates to the roadside units that join the network;

[0168] S2: Verify the identity of vehicles entering the network for the first time, and apply for a pseudonym and network access certificate from a trusted institution;

[0169] S3: Perform trust management on the vehicles that joined the network in step S2 and the roadside units that joined the network in step S1 respectively;

[0170] The trust management in step S3 includes: repeatedly executing step S3, canceling the network access qualification of a malicious vehicle when it is determined that the vehicle is malicious; canceling the endorsement qualification of a roadside unit when it is determined that the roadside unit has uploaded incorrect information; and canceling the network access qualification of a roadside unit when it is determined that the roadside unit is malicious.

[0171] The specific implementation methods for each step are described below:

[0172] S1: Initialize the vehicle network trust management system;

[0173] S11: Initialize cryptographic tools for vehicle-to-everything (V2X) authentication; support pseudonym rotation for privacy protection;

[0174] S111: Deploy a Public Key Infrastructure (PKI) compliant with the IEEE 1609.2 standard;

[0175] Specifically, this includes defining the following cryptographic parameters during system initialization:

[0176] Define an elliptic curve In the formula, yes An additive cyclic group on the order of a large prime number. P is a group generator, and Simultaneously, two collision-resistant hash functions are selected. and , and The above parameters are broadcast to the blockchain network by a trusted institution.

[0177] S112: Configure Root Certificate Authority (CA) permissions for the Trusted Authority and generate the root certificate and the corresponding Certificate Revocation List (CRL) storage structure.

[0178] S12: Construct a two-layer blockchain network;

[0179] S121: Hyperledger Fabric network initialization, including organization definition, channel creation, and node deployment.

[0180] Organizational definitions include:

[0181] Core layer organization: responsible for global affairs such as certificate management and cross-layer data synchronization;

[0182] The core layer organization includes the following node types:

[0183] Endorsing nodes: These are performed by trusted institutions. They execute the chaincode and endorse transactions in the core layer to ensure the legality and validity of the transactions. They also sign the transactions according to a predetermined endorsement strategy to provide endorsement.

[0184] The sorting nodes are managed by a trusted institution and use the Kafka consensus algorithm to sort all transactions in total order. Then, a batch of sorted transactions (by time or size threshold) are packaged into a single block and broadcast to the committing nodes via the Gossip protocol.

[0185] Submitting node: Verifies blocks and submits the verified blocks to the core layer ledger; the core layer ledger includes the roadside unit trust ledger and the certificate ledger.

[0186] Edge layer organization: responsible for local tasks such as real-time vehicle-RSU interaction;

[0187] The edge layer organization includes the following node types:

[0188] Endorsement node: This is handled by the RSU, which processes local transaction endorsements;

[0189] Submitting Node: Verifies edge channel blocks and submits the verified blocks to the edge layer ledger; the edge layer ledger includes the vehicle trust ledger;

[0190] It does not contain sorting nodes and relies on the sorting nodes of the core layer to provide block sorting services.

[0191] Cross-layer collaboration:

[0192] Edge layer transactions are linked to core layer sorting nodes for unified sorting via channels; layered deployment reduces the computational load on edge nodes (RSUs do not need to participate in global consensus).

[0193] Channel creation includes:

[0194] Core channel: Only trusted organizations are allowed to join; used for global certificate management and trust policy synchronization.

[0195] Edge Channel: Allows RSUs to join and process local trust data transactions.

[0196] Node deployment includes:

[0197] Trusted Institutions: These are the ordering nodes and Certificate Authority (CA) nodes (endorsing nodes of the core channel) in the core channel.

[0198] RSU node: As an endorsement node for the edge channel, it installs lightweight chaincode (such as trust score calculation logic).

[0199] During the system initialization phase, the trusted authority provides identity authentication for the roadside units and generates roadside unit pseudonyms and certificates, as shown in Table 2. The identity information of the roadside units, such as ID, certificate and pseudonym, is saved to the certificate ledger.

[0200] The advantages of a two-layer blockchain network include:

[0201] Performance optimization: The edge layer eliminates sorting overhead, adapting to the low latency requirements of vehicle-to-everything (V2X) communication.

[0202] Security isolation: The core layer sorting service maintains the consistency of the global transaction order;

[0203] Resource adaptation: Edge devices such as RSU do not need to store the complete ledger (can be configured as light nodes).

[0204] To prevent verification delays caused by frequent vehicle certificate rotation, the edge layer caches valid pseudonym certificate hashes, reducing query pressure on the core layer.

[0205] S122: Configure differentiated endorsement strategies for different channels;

[0206] Edge channel: Employs an OR endorsement strategy, requiring only endorsement from a single roadside unit to pass verification;

[0207] Core channel: Employs a strict consensus mechanism, requiring endorsement from more than two-thirds of trusted institutions to confirm a transaction.

[0208] Step S2 includes: uploading the vehicle identification information as shown in Table 2 to the certificate ledger;

[0209] S21: When vehicle i joins the vehicle network, it first sends a certificate registration request to a trusted authority and uploads the vehicle ID. ;

[0210] S22: After receiving the vehicle registration request and vehicle ID, the trusted institution generates a random number for vehicle i. As the private key, and based on the private key Calculate the public key corresponding to vehicle i , In the formula, P is a base point on a predefined elliptic curve;

[0211] S23: Based on the public key generated in step S22, the trusted authority generates a certificate for vehicle i. and kana ,

[0212] The certificate includes the vehicle. Public key The signature of trusted authority C and certificate validity period To prove the vehicle's identity;

[0213] In the formula, This indicates the XOR operation. It is a pre-defined hash function; pseudonyms are the basis for anonymous vehicle communication, and the hash function... The inclusion of is to ensure the uniqueness and irreversibility of pseudonyms;

[0214] S24: The trusted authority uploads the vehicle ID, along with the certificate and pseudonym of vehicle i generated in step S23, to the certificate ledger.

[0215] When a certificate is about to expire or the private key is lost, vehicle i must submit a certificate renewal request to a trusted authority. After identity authentication is successful, when the vehicle chooses to revoke the original certificate, the old certificate will be added to the certificate revocation list.

[0216] Step S2 not only ensures the legality and security of the vehicle's identity, but also effectively protects the vehicle's privacy through a pseudonym mechanism.

[0217] Step S3 involves trust management for vehicles that joined the network in step S2, including:

[0218] C1: The trust values ​​of vehicles entering the network are calculated among themselves, and the global trust values ​​of vehicles entering the network are calculated by roadside units;

[0219] C2: Integrate the trust value calculated in step C1, calculate the final trust value of the vehicle finally entering the network, and determine whether the vehicle entering the network is a malicious vehicle based on the preset final trust value threshold.

[0220] Step C1, in which newly connected vehicles calculate trust values ​​with each other, includes:

[0221] CC11: Vehicles that interact directly with vehicle j calculate their direct trust value for vehicle j based on their direct interaction records with vehicle j, and upload the calculated direct trust value to the vehicle trust ledger.

[0222] CC12: For vehicles that do not directly interact with vehicle j, the indirect trust value for vehicle j is calculated based on the direct trust value provided by vehicles that directly interact with vehicle j in the vehicle trust ledger, and then uploaded to the vehicle trust ledger via the roadside unit.

[0223] Step CC11, calculating direct trust in vehicle j, includes:

[0224] CC111: Vehicles that interact directly with vehicle j calculate vehicle j's transmission reliability, forgetting factor, and cooperation metric based on their own direct interaction records with vehicle j.

[0225] Vehicle i is a vehicle that has directly interacted with vehicle j. At the current time t, vehicle i calculates the transmission reliability of vehicle j. The calculation formula is:

[0226] ,

[0227] In the formula, This represents the number of times vehicle j has successfully forwarded data packets, accumulated from the initial time to time t, as recorded by vehicle i. This represents the total number of data packets sent by vehicle i to vehicle j, accumulated from the initial time to time t. Successful forwarding of a data packet means that the data packet forwarded by vehicle j is complete and has not been tampered with. and The data comes from the direct interaction records between vehicle i and vehicle j;

[0228] At current time t, calculate the forgetting factor for vehicle j using vehicle i. The calculation formula is:

[0229] ,

[0230] In the formula, For the interaction moment, the data comes from the direct interaction records between vehicle i and vehicle j; The preset forgetting coefficient;

[0231] The forgetting factor assigns higher weight to recent events to reflect the impact of the timeliness of events on direct trust values.

[0232] At current time t, vehicle i calculates the cooperation metric for vehicle j. The calculation formula is:

[0233] ,

[0234] In the formula, M represents the number of vehicles that have directly interacted with vehicle j from the initial time to time t; M represents the total number of vehicles in the vehicle network. This represents the maximum number of data packets forwarded by a single vehicle from the initial time to time t. This represents the number of data packets forwarded by vehicle j from the initial time to time t. M and The data comes from a vehicle-to-everything (V2X) system. The purpose of considering vehicle cooperation metrics is to identify vehicles willing to forward messages and provide services to others.

[0235] CC112: Based on the transmission reliability, forgetting factor and cooperation metric of vehicle j obtained in step CC111, calculate the direct trust value of the vehicle interacting with vehicle j to vehicle j.

[0236] At current time t, vehicle i calculates the direct trust value of vehicle j. The calculation formula is:

[0237] ,

[0238] In the formula, This is a preset transmission reliability weighting coefficient;

[0239] CC113: The vehicle pseudonym and the corresponding direct trust value for vehicle j obtained from the interaction between step CC112 and vehicle j are uploaded to the vehicle trust ledger as a vehicle trust table via the roadside unit.

[0240] Step CC12 involves calculating the indirect trust value for vehicle j, including:

[0241] CC121: For vehicles that do not directly interact with vehicle j, calculate the trust similarity between themselves and vehicles that directly interact with vehicle j based on the direct trust values ​​of themselves and vehicles that directly interact with vehicle j regarding the same vehicle.

[0242] Vehicle l is a vehicle that has no direct interaction with vehicle j, vehicle h is a vehicle that has directly interacted with vehicle j, and vehicle x is a vehicle that has directly interacted with both vehicle l and vehicle h. The trust similarity between vehicle l and vehicle h at the current time t is... The calculation formula is:

[0243] ,

[0244] In the formula, Let x be the set of vehicles. Let x be the number of vehicles. Let be the direct trust value of vehicle l for vehicle x. Let h be the direct trust value of vehicle h for vehicle x. For absolute value operations, For summation operations;

[0245] Vehicles that do not directly interact with vehicle j cannot directly determine their trust level in vehicle j based on their own direct interaction records. Therefore, they need to refer to the direct trust values ​​of other vehicles for vehicle j. In order to reduce the risk of accepting direct trust values ​​provided by malicious vehicles, it is necessary to calculate the similarity between the direct trust values ​​of the vehicle itself and the reference vehicles for the same vehicle. The reliability of the direct trust values ​​provided by the vehicles is judged by the trust similarity. The higher the trust similarity, the higher the reliability of the direct trust values ​​provided by the vehicles. In subsequent calculations, the direct trust values ​​with higher reliability are more likely to be adopted.

[0246] CC122: Based on the trust similarity calculated in step CC121, calculate the trust weight of vehicles that directly interact with vehicle j for vehicles that do not have direct interaction with vehicle j.

[0247] The trust weight of vehicle l to vehicle h at current time t. The calculation formula is:

[0248] ,

[0249] In the formula, This represents the direct trust value between vehicle l and vehicle h. If vehicle l and vehicle h have no direct interaction, The value is 0.5;

[0250] Trust weight is used to measure the degree of adoption of direct trust. For vehicles with a high degree of trust similarity to one's own vehicle, the degree of adoption is high and the corresponding trust weight is large; for vehicles with a low degree of trust similarity to one's own vehicle, the degree of adoption is low and the corresponding trust weight is small.

[0251] CC123: Vehicles that have no direct interaction with vehicle j calculate the indirect trust value for vehicle j based on the trust weight calculated in step CC122.

[0252] The indirect trust value of vehicle l to vehicle j at current time t. The calculation formula is:

[0253] ,

[0254] In the formula, Let h be the set of vehicles. For the number of vehicles h, Let h be the direct trust value between vehicle h and vehicle j;

[0255] CC124: The vehicle calculation trust table, which is uploaded to the vehicle trust ledger via the roadside unit, contains the vehicle pseudonym that has no direct interaction with vehicle j in step CC123 and the corresponding indirect trust value for vehicle j.

[0256] In step C1, the roadside unit calculates the global trust value of the vehicle entering the network, including:

[0257] CL11: The roadside unit selects trusted vehicles from those with zero malicious behavior; the roadside unit sets the initial malicious behavior for vehicles entering the network. =0, ;

[0258] CL12: The trusted vehicle sends a detection packet to the target vehicle. After receiving the detection packet, the target vehicle forwards the detection packet to the roadside unit in step CL11 according to a preset procedure. The preset procedure includes forwarding the detection packet to the roadside unit in step CL11 within a preset time period.

[0259] Current moment Trusted Vehicles To the target vehicle Send detection packet , ,in, It is a detection message; It is the hash value of the detected message; It is a trustworthy vehicle. Use its private key A digital signature is generated by signing the detection message. The digital signature is mainly used to prevent roadside units from forging the target vehicle. Malicious behavior;

[0260] CL13: After a preset duration, the roadside unit verifies the reception status of the detection packets;

[0261] The reception status includes: whether a detection packet is received within a preset time period and whether the received detection packet data is consistent with the content of the sent data packet;

[0262] CL14: If the roadside unit does not receive a detection packet within the preset time period or the content of the received detection packet is inconsistent with the content of the sent data packet, increment the record of the target vehicle's malicious behavior by 1.

[0263] CL15: Repeat steps CL11 to CL14 until the preset time.

[0264] CL16: Calculate the global trust value of vehicles entering the network based on malicious behavior recorded by roadside units;

[0265] Global trust value of vehicle j at current time t. The calculation formula is:

[0266] ,

[0267] In the formula, It represents the number of malicious actions committed by vehicle j from time t-1 to time t. It is the global trust weight from time t-1 to time t. = , This represents the maximum number of malicious actions per vehicle among the vehicles M that joined the network between time t-1 and time t.

[0268] CL17: The roadside unit uploads the target vehicle pseudonym and the corresponding calculated global trust value from step S46 to the global trust table of the vehicle trust ledger.

[0269] The roadside unit will also upload the recorded malicious behavior to the vehicle trust ledger in the form of a malicious behavior verification code; the malicious behavior verification code includes trusted vehicles that detected the target vehicle. pseudonyms, digital signatures of trusted vehicles and the hash value of the detection message The storage format for malicious behavior verification codes is as follows:

[0270] < The kana>,

[0271] The roadside unit stores all malicious behavior verification codes in the target vehicle's global trust table.

[0272] Roadside units collaborate with trusted vehicles to detect other vehicles, increasing the frequency of interactions. They also calculate global vehicle trust based on whether vehicles exhibit malicious behavior during vehicle-road cooperative detection.

[0273] Step C2 includes:

[0274] C21: The final trust value of the vehicle finally joining the network is calculated and uploaded to the vehicle final trust table of the vehicle trust ledger via the roadside unit. This represents the final trust value of vehicle j at time t. The calculation formula is:

[0275] ,

[0276] In the formula, M-1; For vehicles other than vehicle j among the vehicles entering the network, and ; The preset final trust value weighting coefficient; For the vehicle at the current time t... The direct trust value for vehicle j;

[0277] C22: Based on the preset final trust value threshold Determining whether a vehicle joining the network is a malicious vehicle includes:

[0278] like If vehicle j is determined to be a malicious vehicle, its current network access qualification will be cancelled, and its network access certificate will be added to the revocation list.

[0279] like If so, then vehicle j is determined to be a normal vehicle.

[0280] Trusted institutions at the core layer of the blockchain manage the trust of roadside units at the edge layer. Roadside units include endorsement qualifications and network access qualifications. When a trusted institution detects that a roadside unit affects the trust calculation of vehicles entering the network and affects the data security of the edge layer, it cancels the endorsement qualification of the roadside unit but retains the network access qualification. When a trusted institution detects that a roadside unit transmits incorrect information to the trusted institution and affects the data security of the core layer of the blockchain, it cancels the network access qualification of the roadside unit.

[0281] Step S3 involves trust management of the roadside units that were added to the network in step S1, including:

[0282] The system checks the roadside unit's endorsement eligibility by determining whether the roadside unit has uploaded incorrect information to the blockchain based on the vehicle trust ledger and the roadside unit trust ledger. If the system determines that the roadside unit has uploaded incorrect information, the roadside unit's endorsement eligibility is revoked.

[0283] Testing the eligibility of roadside units for network access includes:

[0284] R1: The trusted authority detects whether the roadside unit sends an error message to the trusted authority by comparing data;

[0285] R2: When step R1 detects that the roadside unit sends an error message to the trusted agency, the trusted agency uses the maximum likelihood ratio to detect whether the roadside unit is a malicious roadside unit; when the roadside unit is determined to be a malicious roadside unit, the roadside unit's network access qualification is cancelled.

[0286] The qualifications for endorsement of the roadside detection unit include:

[0287] B1: The trusted institution obtains the malicious behavior verification code recorded in the global trust table of the vehicle trust ledger, and determines whether the roadside unit has forged the vehicle malicious behavior record according to the verification function. If the roadside unit forges the vehicle malicious behavior record, the roadside unit's endorsement qualification is cancelled.

[0288] Trusted nodes located in the core layer detect whether roadside units in the edge layer have forged records of malicious behavior of vehicles. Due to the immutability of the blockchain, all uploaded blocks will have a record of which roadside unit endorsed them. Therefore, the roadside unit that endorsed the upload can be located based on the block.

[0289] Retrieve the malicious behavior verification code from the global trust table:

[0290] First, obtain the malicious behavior verification code from the global trust table. ,pass Find the corresponding public key from the pseudonym Then according to the verification function The output result is judged;

[0291] If the verification function If the output is True, it indicates that the roadside unit has not forged any malicious vehicle behavior.

[0292] If the verification function The output result is If this indicates that the roadside unit has engaged in malicious behavior by forging vehicles, the trusted institution will revoke the roadside unit's endorsement qualification, add the roadside unit's endorsement certificate to the revocation list, and update the roadside unit's status to the roadside unit trust ledger. The status of the roadside unit includes: revocation of endorsement qualification, revocation of network access qualification, and normal.

[0293] B2: The trusted institution calculates the corresponding roadside unit trust value based on the vehicle trust ledger managed by the roadside unit, and determines whether the roadside unit has uploaded error information to the blockchain based on the roadside unit trust value; Step B2 includes:

[0294] B21: Trusted institutions calculate the trust distance between each roadside unit based on the vehicle trust ledger managed by each roadside unit;

[0295] Current moment roadside unit and roadside units Trust distance The calculation formula is:

[0296] ,

[0297] In the formula, Let t be the roadside unit at the current time. The final trust value of vehicle j is calculated. Let t be the roadside unit at the current time. The final trust value of vehicle j is calculated.

[0298] B22: Based on the trust distance between each roadside unit obtained in step B21, calculate the trust distance between each roadside unit. - Proximity trust distance;

[0299] Current moment roadside unit and roadside units Between - Proximity Trust Distance The calculation formula is:

[0300] = ,

[0301] In the formula, Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the roadside unit. With roadside units Trust distance , and R represents the total number of roadside units in the vehicle-to-everything (V2X) network. In this embodiment, k is set to 3. refers to roadside units Among the R-1 trust distance values ​​arranged in descending order, Ranked 3rd;

[0302] B23: Based on the information obtained from step B22 regarding the relationships between various roadside units -Nearest trust distance, calculating the distance between each roadside unit. -Nearest trust density;

[0303] Current moment roadside unit of - Neighbor Trust Density The calculation is made by dividing the total number of eligible roadside units by the number of eligible units. -The sum of the nearest trust distances is obtained;

[0304] The total number of eligible roadside units refers to: the total number of roadside units. Trust the nearest roadside unit and roadside units Trust the second closest roadside unit , and roadside units Trust the roadside unit closest to the kth distance The total number;

[0305] Meets the requirements -The sum of proximity trust distances refers to: roadside units With roadside units Between - Proximity trust distance, roadside unit With roadside units Between - Proximity Trust Distance, Roadside unit With roadside units Between - The sum of the nearest trust distances;

[0306] Current moment roadside unit of - Neighbor Trust Density The calculation formula is:

[0307] ,

[0308] ,

[0309] ,

[0310] ,

[0311] In the formula, For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The largest of the R-1 trust distance values ​​is that of the roadside unit. With roadside units Trust distance and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the roadside unit. With roadside units Trust distance and ; For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The second largest of the R-1 trust distance values ​​is the trust distance itself. and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. ; For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. ; roadside unit The total number; if the roadside units meet the requirements Each is unique, i.e., roadside unit If there are no overlapping trust distances between the trust distances of the two R-1 roadside units, then... If there are two roadside units that meet the requirements and roadside units that meet the requirements If each is unique, then +1; and so on; This is for reciprocal operations.

[0312] if If the value is negative, it means that the final trust value uploaded by the roadside unit is out of the loop, and the trust value of the roadside unit should be reduced.

[0313] B24: Based on the roadside units obtained in step B23 -Nearest trust density, calculate the corresponding roadside cell trust value;

[0314] Current moment roadside unit Trust value The calculation formula is:

[0315] ,

[0316] In the formula, For the previous moment roadside unit Trust value; In this embodiment, the initial trust value of the roadside unit is 1.

[0317] B25: Based on the trust values ​​of each roadside unit calculated in step B24 and the preset roadside unit trust value threshold. Determine whether the roadside unit has uploaded error information to the blockchain;

[0318] like Then determine the roadside unit Error information is uploaded to the blockchain, and a trusted organization cancels the roadside unit. The endorsement qualification will be used for roadside units The endorsement certificate is added to the revocation list, and the roadside cell trust value and roadside cell status are updated to the roadside cell trust ledger;

[0319] like If so, the trusted institution will update the roadside unit trust value to the roadside unit trust ledger.

[0320] To prevent information tampering when roadside units act as a transmission medium for communication between vehicles and trusted nodes, it is necessary to detect the information transmission of roadside units. Step R1 includes:

[0321] R11: Vehicle j establishes a communication connection with the roadside unit and passes through the roadside unit. Send data packets to trusted node c Vehicle j generates authentication parameters based on bitwise XOR operations according to the sent data packets. Authentication parameters The expression is:

[0322] ,

[0323] In the formula, For vehicle j towards the roadside unit The first data packet sent; For vehicle j towards the roadside unit The first one sent One data packet; For vehicle j passing through the roadside unit The binary representation of the total number of data packets sent to the trusted node; For hash functions, It is the private key of vehicle j;

[0324] R12: Vehicle j uses the public key of trusted institution c. The authentication parameters generated in step R11 After encryption, a feedback packet is generated. And when vehicle j enters the coverage area of ​​another roadside unit and establishes communication, it will send a feedback packet. It is sent to a trusted institution c;

[0325] R13: Receiver from roadside unit Data packets sent Feedback packets sent by another roadside unit Then, trusted authority C recalculates the authentication parameters based on the received data packets. and using the trusted institution c's own key Decryption Feedback Packet Obtain authentication parameters ;

[0326] Recalculate authentication parameters The calculation formula is:

[0327] ,

[0328] In the formula, For trusted organization c, via roadside unit The first data packet received; For trusted organization c, via roadside unit The first received One data packet; For trusted organizations to access roadside units The binary representation of the total number of data packets received;

[0329] R14: Trusted node comparison step R13 recalculates authentication parameters Authentication parameters obtained through decryption Whether they are consistent, determine if the error message is caused by the roadside unit; if The error message is from the roadside unit. lead to;

[0330] Step R2 includes:

[0331] R21: Repeat step R1 to collect historical moments from the vehicle network system. up to the current moment Vehicles connected to the network and roadside units Communication records; communication records include those with roadside units The number of communicating vehicles and the number of times the data packets and feedback packets are inconsistent at each time point in step S63; in this embodiment, historical time points... For vehicles to enter roadside units The moment within the scope of management, the current moment For vehicles to leave the roadside unit The moment within the scope of management.

[0332] R22: Based on the number of times the data packets and feedback packets collected in step R21 are inconsistent, construct binomial distributions under the null hypothesis H0 and the alternative hypothesis H1 respectively.

[0333] The binomial distribution is constructed as follows:

[0334] Under the null hypothesis H0, the probability that the roadside unit is not a malicious entity and the data packet and the feedback packet are inconsistent is: ,time Number of times the data packet and the response packet are inconsistent Obtain the parameter as binomial distribution: ;

[0335] In the formula, For a historic moment up to the current moment and roadside units The number of vehicles communicating; ;

[0336] Under alternative assumption H1, the roadside unit at time... The probability that the detected entity is malicious and the data packet is inconsistent with the response packet is: ,time Number of times the data packet and the response packet are inconsistent At any moment Then, it follows the parameter as binomial distribution: ), ;

[0337] R23: Based on the binomial distribution constructed in step R22, calculate the joint probability under the null hypothesis H0 and the alternative hypothesis H1 respectively;

[0338] In roadside units Inconsistencies were observed between data packets and feedback packets at various time points, assuming no malicious intent. joint probability for:

[0339]

[0340] ;

[0341] In cases of malicious behavior occurring in roadside units, at any given time Previously, roadside units At any moment At that time Without malicious intent, the probability that the data packet and the response packet are inconsistent is: ,therefore ); at time Subsequently, the probability that the data packet and the feedback packet are inconsistent is... ,therefore ).

[0342] In roadside units In cases of malicious intent, discrepancies were observed between data packets and feedback packets at various time points. joint probability for:

[0343]

[0344] ;

[0345] R24: Calculate the likelihood ratio statistic based on the joint probability calculated in step R23. Likelihood statistic The calculation formula is:

[0346] ;

[0347] R25: The likelihood ratio statistic calculated based on step R24 and the preset likelihood ratio statistic threshold. To determine whether the error message was caused by malicious behavior of the roadside unit;

[0348] like > Then determine the roadside unit The error message is malicious and is caused by malicious behavior from the roadside unit.

[0349] R26: If step R25 determines that the error message is caused by malicious behavior of the roadside unit, the trusted authority cancels the roadside unit. The qualification for network access will be for roadside units. The network access certificate is added to the revocation list, and the roadside unit status is updated to the roadside unit trust ledger;

[0350] The likelihood ratio statistic calculated in step R24 includes:

[0351] R241: For parameters respectively , , as well as By performing maximum likelihood estimation, the estimated value is obtained. , , as well as ;

[0352] calculate Parameters need to be adjusted To perform maximum likelihood estimation, it is necessary to calculate... Make the joint probability If there is a maximum value, use partial derivatives to find the maximum point:

[0353] ,

[0354] The parameters are obtained by solving the formula after derivation. Maximum likelihood estimate :

[0355] ;

[0356] calculate Includes: parameters To perform maximum likelihood estimation, therefore, it is necessary to Make the joint probability If there is a maximum value, use partial derivatives to find the maximum point:

[0357] ,

[0358] Solving for the parameters Maximum likelihood estimate :

[0359] ,

[0360] calculate Includes: parameters To perform maximum likelihood estimation, it is necessary to calculate... Make the joint probability If there is a maximum value, use partial derivatives to find the maximum point:

[0361] ,

[0362] Solving for the parameters Maximum likelihood estimate :

[0363] ;

[0364] calculate Includes: parameters Perform maximum likelihood estimation; in order to estimate , needs to be maximized :

[0365] ,

[0366] Solving for the parameters Maximum likelihood estimate :

[0367] ,

[0368] In the formula, express When taking the maximum value, the parameter The value;

[0369] R242: Traversal from arrive All times are calculated according to the L341 method. , , as well as Take one of them The largest As ;Will corresponding As a likelihood ratio statistic used in calculations.

[0370] This invention integrates trust value calculation, a collaborative mechanism between roadside units and vehicles, a blockchain architecture, and privacy protection technologies to achieve high efficiency, security, and privacy protection in message authentication within the vehicle-to-everything (V2X) environment. This method not only improves the throughput of the edge layer but also enables the core layer to manage trust at the edge layer. Furthermore, it enhances the accuracy and real-time performance of trust assessment through a vehicle-to-infrastructure (V2I) collaborative detection mechanism. Simultaneously, identity authentication and pseudonym mechanisms effectively protect the true identity of vehicles. The method and system of this invention can be widely applied to various scenarios in the V2X, including but not limited to vehicle-to-vehicle information sharing, traffic flow optimization, intelligent transportation systems, and autonomous vehicles.

[0371] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0372] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0373] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0374] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0375] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A vehicle-to-everything (V2X) trust management method, characterized in that, Vehicle network trust management is based on a vehicle network trust management system, which includes: vehicles, roadside units, trusted institutions, and edge layer blockchain and core layer blockchain based on Hyperledger. The vehicle interacts with the edge layer blockchain through a network access certificate issued by a trusted institution; The roadside unit, as a blockchain edge layer node, uploads the vehicle trust ledger of the information management edge layer super ledger and interacts with the core layer trusted institution through the network access certificate and endorsement certificate issued by the trusted institution; the vehicle trust ledger records the vehicle trust status, and changes to the vehicle trust ledger are endorsed by a single roadside unit. The trusted institution, as a core layer node of the blockchain, manages the certificate ledger and roadside unit trust ledger of the core layer hyperledger; the certificate ledger records the certificate status of vehicles and roadside units, and the roadside unit trust ledger records the trust status of roadside units. The methods include: S1: Initialize the vehicle network trust management system, and the trusted institution issues network access certificates and endorsement certificates to the roadside units that join the network; S2: Verify the identity of vehicles entering the network for the first time, and apply for a pseudonym and network access certificate from a trusted institution; S3: Perform trust management on the vehicles that joined the network in step S2 and the roadside units that joined the network in step S1 respectively; The trust management in step S3 includes: repeatedly executing step S3, canceling the network access qualification of a malicious vehicle when it is determined that the vehicle is malicious; canceling the endorsement qualification of a roadside unit when it is determined that the roadside unit has uploaded incorrect information; and canceling the network access qualification of a roadside unit when it is determined that the roadside unit is malicious. Step S3 involves trust management for vehicles that joined the network in step S2, including: C1: Connecting vehicles calculate trust values ​​with each other, and roadside units calculate the global trust value of connecting vehicles based on the recorded malicious behavior of connecting vehicles. C2: Integrate the trust value calculated in step C1, calculate the final trust value of the vehicle finally entering the network, and determine whether the vehicle entering the network is a malicious vehicle based on the preset final trust value threshold. Step C1, in which newly connected vehicles calculate trust values ​​with each other, includes: Other vehicles calculate the trust value for a single vehicle: CC11: Vehicles that directly interact with vehicle j calculate their direct trust value for vehicle j based on their direct interaction records with vehicle j, and upload the calculated direct trust value to the vehicle trust ledger through the roadside unit. CC12: For vehicles that do not directly interact with vehicle j, the indirect trust value for vehicle j is calculated based on the direct trust value provided by vehicles that directly interact with vehicle j in the vehicle trust ledger, and then uploaded to the vehicle trust ledger via the roadside unit. Step CC11, calculating direct trust in vehicle j, includes: CC111: Vehicles that interact directly with vehicle j calculate vehicle j's transmission reliability, forgetting factor, and cooperation metric based on their own direct interaction records with vehicle j. Vehicle i is a vehicle that has directly interacted with vehicle j. At the current time t, vehicle i calculates the transmission reliability of vehicle j. The calculation formula is: ， In the formula, This represents the number of times vehicle j has successfully forwarded data packets, accumulated from the initial time to time t, as recorded by vehicle i. This represents the total number of data packets sent by vehicle i to vehicle j, accumulated from the initial time to time t. Successful forwarding of a data packet means that the data packet forwarded by vehicle j is complete and has not been tampered with. and The data comes from the direct interaction records between vehicle i and vehicle j; At current time t, calculate the forgetting factor for vehicle j using vehicle i. The calculation formula is: ， In the formula, For the interaction moment, the data comes from the direct interaction records between vehicle i and vehicle j; The preset forgetting coefficient; At current time t, vehicle i calculates the cooperation metric for vehicle j. The calculation formula is: ， In the formula, M represents the number of vehicles that have directly interacted with vehicle j from the initial time to time t; M represents the total number of vehicles in the vehicle network. This represents the maximum number of data packets forwarded by a single vehicle from the initial time to time t. This represents the number of data packets forwarded by vehicle j from the initial time to time t. M and The data comes from the vehicle networking system; CC112: Based on the transmission reliability, forgetting factor and cooperation metric of vehicle j obtained in step CC111, calculate the direct trust value of the vehicle interacting with vehicle j to vehicle j. At current time t, vehicle i calculates the direct trust value of vehicle j. The calculation formula is: ， In the formula, This is a preset transmission reliability weighting coefficient; CC113: The vehicle pseudonym obtained from the interaction with vehicle j in step CC112, along with the corresponding calculated direct trust value for vehicle j, is uploaded to the vehicle trust ledger as a vehicle trust table via the roadside unit.

2. The vehicle network trust management method according to claim 1, characterized in that, Step CC12 involves calculating the indirect trust value for vehicle j, including: CC121: For vehicles that do not directly interact with vehicle j, calculate the trust similarity between themselves and vehicles that directly interact with vehicle j based on the direct trust values ​​of themselves and vehicles that directly interact with vehicle j regarding the same vehicle. Vehicle l is a vehicle that has no direct interaction with vehicle j, vehicle h is a vehicle that has directly interacted with vehicle j, and vehicle x is a vehicle that has directly interacted with both vehicle l and vehicle h. The trust similarity between vehicle l and vehicle h at the current time t is... The calculation formula is: ， In the formula, Let x be the set of vehicles. Let x be the number of vehicles. Let be the direct trust value of vehicle l for vehicle x. Let h be the direct trust value of vehicle h for vehicle x. For absolute value operations, For summation operations; CC122: Based on the trust similarity calculated in step CC121, calculate the trust weight of vehicles that directly interact with vehicle j for vehicles that do not have direct interaction with vehicle j. The trust weight of vehicle l to vehicle h at current time t. The calculation formula is: ， In the formula, Let be the direct trust value between vehicle l and vehicle h. If vehicle l and vehicle h have no direct interaction, then... The value is 0.5; CC123: Vehicles that have no direct interaction with vehicle j calculate the indirect trust value for vehicle j based on the trust weight calculated in step CC122. The indirect trust value of vehicle l to vehicle j at current time t. The calculation formula is: ， In the formula, Let h be the set of vehicles. For the number of vehicles h, Let h be the direct trust value between vehicle h and vehicle j; CC124: The vehicle trust table, which is the vehicle pseudonym that has no direct interaction with vehicle j in step CC123 and the corresponding indirect trust value for vehicle j, is uploaded to the vehicle trust ledger via the roadside unit.

3. The vehicle network trust management method according to claim 2, characterized in that, In step C1, the roadside unit calculates the global trust value of the vehicle entering the network, including: CL11: The roadside unit selects trusted vehicles from those with zero malicious behavior; the roadside unit sets the initial malicious behavior for vehicles entering the network. =0, , This represents the set of vehicles with a total number of M in the Internet of Vehicles (IoV). CL12: The trusted vehicle sends a detection packet to the target vehicle. After receiving the detection packet, the target vehicle forwards the detection packet to the roadside unit in step CL11 according to a preset procedure. The preset procedure includes forwarding the detection packet to the roadside unit in step CL11 within a preset time period. Current moment Trusted Vehicles To the target vehicle Send detection packet , ,in, It is a detection message; It is the hash value of the detected message; It is a trustworthy vehicle. Use its private key A digital signature is generated by signing the detection message; CL13: After a preset duration, the roadside unit verifies the reception status of the detection packets; The reception status includes: whether a detection packet is received within a preset time period and whether the received detection packet data is consistent with the content of the sent data packet; CL14: If the roadside unit does not receive a detection packet within the preset time period or the content of the received detection packet is inconsistent with the content of the sent data packet, increment the record of the target vehicle's malicious behavior by 1. CL15: Repeat steps CL11 to CL14 until the preset time. CL16: Calculate the global trust value of vehicles entering the network based on malicious behavior recorded by roadside units; Global trust value of vehicle j at current time t. The calculation formula is: ， In the formula, It represents the number of malicious actions committed by vehicle j from time t-1 to time t. It is the global trust weight from time t-1 to time t. = , This represents the maximum number of malicious actions committed by a single vehicle among the vehicles that joined the network between time t-1 and time t. CL17: The roadside unit uploads the target vehicle pseudonym from step CL16 and the corresponding calculated global trust value to the global trust table of the vehicle trust ledger. The roadside unit will also upload the recorded malicious behavior to the vehicle trust ledger in the form of a malicious behavior verification code; the malicious behavior verification code includes trusted vehicles that detected the target vehicle. pseudonyms, digital signatures of trusted vehicles and the hash value of the detection message The storage format for malicious behavior verification codes is as follows: < The kana>, The roadside unit stores the malicious behavior verification code in the target vehicle's global trust table.

4. The vehicle network trust management method according to claim 3, characterized in that, Step C2 includes: C21: The final trust value of the vehicle finally joining the network is calculated and uploaded to the vehicle final trust table of the vehicle trust ledger via the roadside unit. This represents the final trust value of vehicle j at time t. The calculation formula is: ， In the formula, M-1; For vehicles other than vehicle j among the vehicles entering the network, and ; The preset final trust value weighting coefficient; For the vehicle at the current time t... The direct trust value for vehicle j; C22: Based on the preset final trust value threshold Determining whether a vehicle joining the network is a malicious vehicle includes: like If vehicle j is determined to be a malicious vehicle, its current network access qualification will be cancelled, and its network access certificate will be added to the revocation list. like If so, then vehicle j is determined to be a normal vehicle.

5. The vehicle network trust management method according to claim 4, characterized in that, Step S3 involves trust management of the roadside units that were added to the network in step S1, including: The system checks the roadside unit's endorsement eligibility by determining whether the roadside unit has uploaded incorrect information to the blockchain based on the vehicle trust ledger and the roadside unit trust ledger. If the system determines that the roadside unit has uploaded incorrect information, the roadside unit's endorsement eligibility is revoked. Testing the eligibility of roadside units for network access includes: R1: The trusted authority detects whether the roadside unit sends an error message to the trusted authority by comparing data; R2: When step R1 detects that the roadside unit sends an error message to the trusted agency, the trusted agency uses the maximum likelihood ratio to detect whether the roadside unit is a malicious roadside unit; when the roadside unit is determined to be a malicious roadside unit, the roadside unit's network access qualification is cancelled.

6. The vehicle network trust management method according to claim 5, characterized in that, The qualifications for endorsement of the roadside detection unit include: B1: The trusted institution obtains the malicious behavior verification code recorded in the global trust table of the vehicle trust ledger, and determines whether the roadside unit has forged the vehicle malicious behavior record according to the verification function. If the roadside unit forges the vehicle malicious behavior record, the roadside unit's endorsement qualification is cancelled. Retrieve the malicious behavior verification code from the global trust table: ,pass Find the corresponding public key from the pseudonym Then according to the verification function The output result is judged; If the verification function If the output is True, it indicates that the roadside unit has not forged any malicious vehicle behavior. If the verification function The output result is If this indicates that the roadside unit has engaged in malicious behavior by forging vehicles, the trusted institution will revoke the roadside unit's endorsement qualification, add the roadside unit's endorsement certificate to the revocation list, and update the roadside unit's status to the roadside unit trust ledger. The status of the roadside unit includes: revocation of endorsement qualification, revocation of network access qualification, and normal. B2: The trusted institution calculates the corresponding roadside unit trust value based on the vehicle trust ledger managed by the roadside unit, and determines whether the roadside unit has uploaded error information to the blockchain based on the roadside unit trust value; Step B2 includes: B21: Trusted institutions calculate the trust distance between each roadside unit based on the vehicle trust ledger managed by each roadside unit; Current moment roadside unit and roadside units Trust distance The calculation formula is: ， In the formula, Let t be the roadside unit at the current time. The final trust value of vehicle j is calculated. Let t be the roadside unit at the current time. The final trust value of vehicle j is calculated. B22: Based on the trust distance between each roadside unit obtained in step B21, calculate the trust distance between each roadside unit. - Proximity trust distance; Current moment roadside unit and roadside units Between - Proximity Trust Distance The calculation formula is: = ， In the formula, Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the roadside unit. With roadside units Trust distance , , Let R represent the total number of roadside units in the vehicle-to-everything (V2X) network, and R represents the total number of roadside units in the vehicle-to-everything (V2X) network. B23: Based on the information obtained from step B22 regarding the relationships between various roadside units -Nearest trust distance, calculating the distance between each roadside unit. -Nearest trust density; Current moment roadside unit of - Neighbor Trust Density The calculation formula is: ， ， ， ， In the formula, For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The largest of the R-1 trust distance values ​​is that of the roadside unit. With roadside units Trust distance , and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the roadside unit. With roadside units Trust distance and ; For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The second largest of the R-1 trust distance values ​​is the trust distance itself. and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. ; For the current moment roadside unit With roadside units Between - Proximity trust distance; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. and ; Indicates the current time roadside unit The k-th largest of the R-1 trust distance values ​​is the trust distance itself. ; roadside unit The total number; For reciprocal operations; B24: Based on the roadside units obtained in step B23 -Nearest trust density, calculate the corresponding roadside cell trust value; Current moment roadside unit Trust value The calculation formula is: ， In the formula, For the previous moment roadside unit Trust value; B25: Based on the trust values ​​of each roadside unit calculated in step B24 and the preset roadside unit trust value threshold. Determine whether the roadside unit has uploaded error information to the blockchain; like Then determine the roadside unit Error information is uploaded to the blockchain, and a trusted organization cancels the roadside unit. The endorsement qualification will be used for roadside units The endorsement certificate is added to the revocation list, and the roadside cell trust value and roadside cell status are updated to the roadside cell trust ledger; like If so, the trusted institution will update the roadside unit trust value to the roadside unit trust ledger.

7. The vehicle network trust management method according to claim 6, characterized in that, Step R1 includes: R11: Vehicle j establishes a communication connection with the roadside unit and passes through the roadside unit. Send data packets to trusted node c Vehicle j generates authentication parameters based on bitwise XOR operations according to the sent data packets. Authentication parameters The expression is: ， In the formula, For vehicle j towards the roadside unit The first data packet sent; For vehicle j towards the roadside unit The first one sent One data packet; For vehicle j passing through the roadside unit The binary representation of the total number of data packets sent to the trusted node; For hash functions, It is the private key of vehicle j; R12: Vehicle j uses the public key of trusted institution c. The authentication parameters generated in step R11 After encryption, a feedback packet is generated. And when vehicle j enters the coverage area of ​​another roadside unit and establishes communication, it will send a feedback packet. It is sent to a trusted institution c; R13: Receiver from roadside unit Data packets sent Feedback packets sent by another roadside unit Then, trusted authority C recalculates the authentication parameters based on the received data packets. and using the trusted institution c's own key Decryption Feedback Packet Obtain authentication parameters ; Recalculate authentication parameters The calculation formula is: ， In the formula, For trusted organization c, via roadside unit The first data packet received; For trusted organization c, via roadside unit The first received One data packet; For trusted organizations to access roadside units The binary representation of the total number of data packets received; R14: Trusted node comparison step R13 recalculates authentication parameters Authentication parameters obtained through decryption Whether they are consistent, determine if the error message is caused by the roadside unit; if The error message is from the roadside unit. lead to.

8. The vehicle network trust management method according to claim 7, characterized in that, Step R2 includes: R21: Repeat step R1 to collect historical moments. up to the current moment Vehicles connected to the network and roadside units Communication records; communication records include those with roadside units The number of vehicles communicating and the number of times the data packets and feedback packets are inconsistent at each time step R1; R22: Based on the number of times the data packets and feedback packets collected in step R21 are inconsistent, construct binomial distributions under the null hypothesis H0 and the alternative hypothesis H1 respectively. The binomial distribution is constructed as follows: Under the null hypothesis H0, the probability that the roadside unit is not a malicious entity and the data packet and the feedback packet are inconsistent is: ,time Number of times the data packet and the response packet are inconsistent Obtain the parameter as binomial distribution: ; In the formula, For a historic moment up to the current moment and roadside units The number of vehicles communicating; ; Under alternative assumption H1, the roadside unit at time... The probability that the detected entity is malicious and the data packet is inconsistent with the response packet is: ,time Number of times the data packet and the response packet are inconsistent At any moment Then, it follows the parameter as binomial distribution: ), ; R23: Based on the binomial distribution constructed in step R22, calculate the joint probability under the null hypothesis H0 and the alternative hypothesis H1 respectively; In roadside units Inconsistencies were observed between data packets and feedback packets at various time points, assuming no malicious intent. joint probability for: ； In roadside units In cases of malicious intent, discrepancies were observed between data packets and feedback packets at various time points. joint probability for: ； R24: Calculate the likelihood ratio statistic based on the joint probability calculated in step R23. Likelihood statistic The calculation formula is: ； R25: The likelihood ratio statistic calculated based on step R24 and the preset likelihood ratio statistic threshold. To determine whether the error message was caused by malicious behavior of the roadside unit; like > Then determine the roadside unit The error message is malicious and is caused by malicious behavior from the roadside unit. R26: If step R25 determines that the error message is caused by malicious behavior of the roadside unit, the trusted authority cancels the roadside unit. The qualification for network access will be for roadside units. The network access certificate is added to the revocation list, and the roadside unit status is updated to the roadside unit trust ledger.

Images