Vehicle communication method and storage medium

Abstract

The embodiment of the invention provides a vehicle communication method and a storage medium, and the method comprises the steps: generating an asymmetric key pair and a reputation value through a first block chain main node in response to the first access of a vehicle to an Internet of Vehicles communication network; generating a dynamic voucher and a random number of the vehicle according to the reputation value and the current driving state information of the vehicle; performing signcryption processing on the road side unit public key, the identity identification information and the random number by using a vehicle private key to obtain a signcryption value; sending an authentication request through a wireless channel; in response to passing of the authentication request, establishing a communication link according to the session key; and data exchange is carried out through a communication link. According to the invention, the technical problems of potential safety hazards and insufficient dynamic adaptability of Internet of Vehicles communication in related technologies are solved.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and more specifically, to a vehicle communication method and storage medium. Background Technology

[0002] Vehicle-to-everything (V2X) communication technology is a wireless communication technology that allows vehicles to exchange information with other infrastructure in their surrounding environment. Current V2X communication technologies face security challenges, including identity forgery, data eavesdropping, and man-in-the-middle attacks, threatening information exchange between vehicles and other infrastructure. Secondly, current V2X communication technologies lack dynamic adaptability; existing solutions struggle to quickly respond to the authentication needs of vehicles moving at high speeds, thus affecting the efficiency of communication between vehicles and other infrastructure.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a vehicle communication method and storage medium to at least solve the technical problems of security risks and insufficient dynamic adaptability in vehicle network communication in related technologies.

[0005] According to one aspect of the embodiments of this application, a vehicle communication method is provided, the method comprising: in response to a vehicle first accessing a vehicle-to-everything (V2X) communication network, generating an asymmetric key pair and a reputation value through a first blockchain master node, wherein the V2X communication network is deployed in a first V2X coverage area, the asymmetric key pair includes a vehicle public key and a vehicle private key, and the reputation value is used to evaluate the vehicle's security behavior; generating a dynamic credential and a random number for the vehicle based on the reputation value and the vehicle's current driving status information, wherein the dynamic credential is used to reflect the vehicle's security status and identity information; performing signature processing on the roadside unit public key, identity information, and random number using the vehicle private key to obtain a signature value; sending an authentication request through a wireless channel, wherein the authentication request includes the signature value and the dynamic credential; in response to the authentication request being successful, establishing a communication link based on a session key, wherein the session key is determined according to a key negotiation protocol; and exchanging data through the communication link.

[0006] Furthermore, the current driving status information includes: current timestamp, encrypted location coordinates, and real-time speed. The vehicle communication method also includes: in response to the distance between the vehicle and any roadside unit being less than a preset threshold, obtaining the vehicle's current timestamp, encrypted location coordinates, and real-time speed.

[0007] Furthermore, based on the reputation value and the vehicle's current driving status information, a dynamic credential for the vehicle is generated, including: hashing the current timestamp, encrypted location coordinates, and real-time speed using a preset hash algorithm to obtain a first hash value; concatenating the first hash value, reputation value, and vehicle public key to obtain a concatenated result; and hashing the concatenated result using a preset hash algorithm to obtain the dynamic credential.

[0008] Furthermore, the vehicle's private key is used to perform signature processing on the roadside unit's public key, identity information, and random number to obtain a signature value. This includes: concatenating the identity information and random number to obtain a data string; performing signature processing on the data string based on the vehicle's private key to obtain a signature value; and encrypting the data string, signature value, and roadside unit's public key based on a preset encryption algorithm to obtain a signature value.

[0009] Furthermore, any roadside unit includes a federated learning module. After the communication link is established, the vehicle communication method further includes: acquiring feature vectors from the driving environment data; encrypting the feature vectors using a preset encryption algorithm to obtain encrypted feature vectors; and updating the federated learning module based on the encrypted feature vectors.

[0010] According to one aspect of the embodiments of this application, a vehicle communication method is provided. The method includes: receiving an authentication request, wherein the authentication request includes a signature value and a dynamic credential; decrypting the signature value using a vehicle public key to obtain a decryption result; verifying the decryption result to obtain a first verification result; verifying the dynamic credential using a smart contract to obtain a second verification result, wherein the smart contract is used to manage the identity information of the vehicle and any roadside unit; in response to both the first verification result and the second verification result indicating that the verification is successful, establishing a communication link based on a session key, wherein the session key is determined according to a key negotiation protocol; and exchanging data through the communication link.

[0011] Furthermore, the decryption result includes: vehicle identification information and a random number. The decryption result is verified to obtain the first verification result, which includes: verifying whether the random number is a historical value, and verifying whether the identification information is consistent with the pre-stored vehicle information.

[0012] Furthermore, the dynamic credential includes: the vehicle's current timestamp, encrypted location coordinates, real-time speed, and reputation value. The dynamic credential is verified through a smart contract to obtain a second verification result, which includes: sending the dynamic credential to a smart contract on the blockchain sidechain; hashing the current timestamp, encrypted location coordinates, real-time speed, and reputation value through the smart contract to obtain a second hash value; and verifying whether the hash value in the dynamic credential matches the second hash value to obtain the second verification result.

[0013] Furthermore, the vehicle communication method also includes: continuously monitoring any communication node; calculating the real-time anomaly score of any communication node based on a historical feature template library, wherein the historical feature template library is used to record historical anomaly communication features; generating an anomaly report within a first preset time period in response to the real-time anomaly score being greater than a preset anomaly threshold; verifying the anomaly report based on a smart contract to obtain the abnormal behavior of any communication node; and resetting the reputation value of any communication node in response to the abnormal behavior matching a preset anomaly pattern, wherein the preset anomaly pattern is stored in a blockchain.

[0014] Furthermore, the vehicle communication method also includes: in response to detecting that a vehicle has entered the second vehicle network coverage area, synchronizing the vehicle's authentication status to the second blockchain master node in the second vehicle network coverage area according to the cross-chain protocol, wherein a vehicle network communication network is deployed in the second vehicle network coverage area; updating the vehicle's asymmetric key pair based on a preset hash algorithm within a second preset time period to obtain the updated asymmetric key pair; and authenticating the vehicle based on the updated asymmetric key pair.

[0015] According to another aspect of the embodiments of this application, a vehicle communication device is also provided, comprising: a first generation module, configured to generate an asymmetric key pair and a reputation value through a first blockchain master node in response to a vehicle first accessing a vehicle-to-everything (V2X) communication network, wherein the V2X communication network is deployed in a first V2X coverage area, the asymmetric key pair includes a vehicle public key and a vehicle private key, and the reputation value is used to evaluate the vehicle's security behavior; a second generation module, configured to generate a dynamic credential and a random number for the vehicle based on the reputation value and the vehicle's current driving status information, wherein the dynamic credential is used to reflect the vehicle's security status and identity information; a first processing module, configured to perform signature processing on the roadside unit public key, identity information, and random number using the vehicle private key to obtain a signature value; a sending module, configured to send an authentication request through a wireless channel, wherein the authentication request includes the signature value and the dynamic credential; a first establishment module, configured to establish a communication link based on a session key in response to the authentication request being passed, wherein the session key is determined according to a key negotiation protocol; and a first exchange module, configured to exchange data through the communication link.

[0016] According to another aspect of the embodiments of this application, a vehicle communication device is also provided, comprising: a receiving module for receiving an authentication request, wherein the authentication request includes a signature value and a dynamic credential; a second processing module for decrypting the signature value using a vehicle public key to obtain a decryption result; a first verification module for verifying the decryption result to obtain a first verification result; a second verification module for verifying the dynamic credential using a smart contract to obtain a second verification result, wherein the smart contract is used to manage the identity information of the vehicle and any roadside unit; a second establishment module for establishing a communication link based on a session key in response to both the first and second verification results indicating successful verification, wherein the session key is determined according to a key negotiation protocol; and a second exchange module for exchanging data through the communication link.

[0017] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the methods in various embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0020] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0021] In this embodiment, when a vehicle first accesses the vehicle-to-everything (V2X) communication network, an asymmetric key pair and a reputation value are first generated by the first blockchain master node. Then, based on the reputation value and the vehicle's current driving status information, a dynamic credential and a random number are generated. The dynamic credential reflects the vehicle's security status and identity information. Next, the vehicle's private key is used to signify the roadside unit's public key, identity information, and random number to obtain a signature value. Then, an authentication request is sent via a wireless channel, including the signature value and the dynamic credential. If the authentication request passes, a communication link is established based on the session key, and finally, data exchange occurs through the communication link. This application significantly improves the speed and security of vehicle identity authentication in the V2X environment by introducing dynamic identity credentials, a lightweight on-chain authentication process, and a blockchain-based real-time detection mechanism. It reduces the risk of data leakage, enhances the system's adaptability to dynamic environments, and achieves the goal of enabling vehicles to quickly and securely access the V2X communication network in dynamic scenarios. This achieves the technical effect of secure communication with high dynamic adaptability and privacy protection, thereby solving the technical problems of security risks and insufficient dynamic adaptability in related technologies for V2X communication. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a flowchart of a vehicle communication method according to an embodiment of this application;

[0024] Figure 2 This is a flowchart of another vehicle communication method according to an embodiment of this application;

[0025] Figure 3 This is an optional on-chain trusted anomaly real-time detection flowchart according to an embodiment of this application;

[0026] Figure 4 This is a flowchart of an optional dynamic identity authentication method according to an embodiment of this application;

[0027] Figure 5 This is a flowchart of an optional blockchain anchoring mechanism according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of an optional privacy-enhanced federated learning hierarchical architecture according to an embodiment of this application;

[0029] Figure 7 This is a timing diagram of an optional on-chain trusted anomaly detection response according to an embodiment of this application;

[0030] Figure 8 This is an optional dynamic scene adaptation technology architecture diagram according to an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of an optional vehicle communication device according to an embodiment of this application;

[0032] Figure 10 This is a schematic diagram of another optional vehicle communication device according to an embodiment of this application. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] According to an embodiment of this application, an embodiment of a vehicle communication method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] This method embodiment can be executed in an electronic device or similar computing device that includes memory and a processor. Taking operation on a computer terminal as an example, the computer terminal may include one or more processors (processors may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), digital signal processing (DSP) chips, microcontroller units (MCUs), field-programmable gate arrays (FPGAs), neural network processors (NPUs), tensor processors (TPUs), artificial intelligence (AI) type processors, etc.) and memory for storing data. Optionally, the computer terminal may also include transmission devices, input / output devices, and display devices for communication functions. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the computer terminal. For example, the computer terminal may include more or fewer components than described above, or have a different configuration than described above.

[0037] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the vehicle communication method in this embodiment. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby implementing the aforementioned vehicle communication method. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0038] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0039] Display devices can be, for example, touchscreen liquid crystal displays (LCDs) and touch displays (also referred to as "touchscreens" or "touch displays"). The LCD allows users to interact with the user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), which allows users to interact with the GUI through finger contact and / or gestures on a touch-sensitive surface. Optional human-computer interaction functions include: creating web pages, drawing, word processing, creating electronic documents, playing games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital video, playing digital music, and / or web browsing, etc. Executable instructions for performing the above human-computer interaction functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0040] This embodiment provides a vehicle communication method. Figure 1 This is a flowchart of a vehicle communication method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0041] Step S11: In response to the vehicle's first access to the vehicle-to-everything (V2X) communication network, an asymmetric key pair and a reputation value are generated through the first blockchain master node. The V2X communication network is deployed in the first V2X coverage area. The asymmetric key pair includes the vehicle's public key and private key. The reputation value is used to evaluate the vehicle's security behavior.

[0042] In this embodiment, the vehicle-to-everything (V2X) communication network allows for information exchange and sharing between vehicles, roadside units, pedestrian equipment, infrastructure, and cloud servers. V2X communication networks are typically based on V2X technology, including different communication modes such as V2V (Vehicle-to-Vehicle), V2I (Vehicle-to-Infrastructure), V2P (Vehicle-to-Pedestrian), and V2N (Vehicle-to-Network).

[0043] The first blockchain master node is a node deployed in the vehicle-to-everything (V2X) communication network to perform key blockchain functions, such as identity registration, generation of asymmetric key pairs, execution and management of smart contracts, transaction verification, and on-chain data storage, etc., which are not restricted here.

[0044] The asymmetric key pair consists of a vehicle public key (PK_V) and a vehicle private key (SK_V). The vehicle public key is used to encrypt data, and the vehicle private key is used to decrypt received data and generate a digital signature to verify the integrity and authenticity of the data's origin.

[0045] Reputation score is used to assess a vehicle's safe behavior and trustworthiness in a vehicle-to-everything (V2X) communication network. For example, the reputation score R is typically calculated based on factors such as the vehicle's past behavior records, authentication history, data sharing contributions, and feedback from other nodes in the network.

[0046] In response to the vehicle's first access to the vehicle-to-everything (V2X) communication network, the generation of an asymmetric key pair and a reputation value through the first blockchain master node can be understood as follows: when the vehicle first accesses the V2X communication network, the vehicle terminal controls the first blockchain master node to generate a pair of asymmetric keys for the vehicle, including the vehicle's public key (PK_V) and private key (SK_V), and assigns an initial reputation value to the vehicle.

[0047] As can be seen, the generation of asymmetric key pairs through the above steps enhances the security of communication, while the setting of reputation values ​​provides a trust foundation for subsequent dynamic identity authentication and data exchange, which helps to quickly identify and respond to potential security threats and ensure the efficiency and security of vehicle network communication.

[0048] For example, at least one blockchain master node equipped with a national cryptographic algorithm module and multiple roadside units are deployed within the vehicle-to-everything (V2X) coverage area. Each roadside unit needs to be pre-installed with a lightweight blockchain client and a federated learning edge computing module. Vehicle terminals need to integrate a security chip equipped with SM2 / SM3 / SM4 algorithms. Upon initial network access, the terminal registers its identity information with the blockchain master node via physical contact or a secure channel, generates an asymmetric key pair (PK_V, SK_V), and obtains initial identity credentials. The blockchain network adopts a layered architecture. The main chain uses the Hyperledger Fabric framework for global identity management and smart contract execution, while the side chains are built on Ethereum for real-time authentication and transaction processing. Data synchronization between the main chain and side chains is achieved through a cross-chain bridging protocol, which is not limited here.

[0049] Step S12: Based on the reputation value and the vehicle's current driving status information, generate a dynamic certificate and a random number for the vehicle. The dynamic certificate is used to reflect the vehicle's safety status and identity information.

[0050] In this embodiment of the application, the current driving status information is used to reflect the real-time position and motion status of the vehicle, and it can be determined whether the vehicle is in a normal driving state through the current driving status information.

[0051] Dynamic credentials are comprehensive identifiers that include the vehicle's current driving status information and reputation value, used to prove the vehicle's security status and identity at a specific time and place. For example, the generation of dynamic credentials involves hashing the aforementioned driving status information and reputation value, and then encrypting them using the vehicle's public key to ensure the credential's uniqueness and anti-counterfeiting capabilities; however, this is not limited to specific cases.

[0052] Random numbers are unpredictable values ​​generated by the vehicle terminal and are used for one-time authentication to ensure the uniqueness and non-reusability of the communication link.

[0053] Identification information can be understood as a data set containing a unique vehicle identifier and other auxiliary authentication information, used to verify the physical identity of a vehicle in vehicle-to-everything (V2X) communication.

[0054] The generation of a vehicle's dynamic credentials and random number based on its reputation score and current driving status information can be understood as follows: combining the reputation score and current driving status information, a specific encryption algorithm is used to generate the vehicle's dynamic credentials, and the random number is automatically generated by the vehicle terminal when it initiates an authentication request.

[0055] For example, a dynamic identity credential is generated using the national standard SM2 asymmetric encryption algorithm. This credential is then combined with a timestamp (millisecond precision), LBS encrypted coordinates, and the vehicle's real-time speed to form a unique identifier, Cred.

[0056] Cred=H(PK_V||H(T||LBS_encrypted||V_speed)||R)

[0057] Wherein, PK_V is the SM2 asymmetric public key of vehicle V, H(T||LBS_encrypted||V_speed) is the real-time status hash value of timestamp (millisecond level), encrypted coordinates of location-based services (LBS) (latitude and longitude desensitized to the hundred-meter level), and speed, and R is the historical reputation value of the vehicle, which is calculated by smart contract to reflect the node's security behavior score in the past 30 days, with a value range of 0-1.

[0058] As another embodiment of this application, a post-quantum cryptography algorithm based on lattice cryptography and aggregate signature technology can also be used to construct a future-oriented authentication system resistant to quantum computing attacks. During system initialization, the vehicle and roadside unit no longer have pre-set SM2 key pairs; instead, a public-private key pair based on a lattice problem is generated. In this case, the method for generating dynamic credentials is adjusted as follows:

[0059] Cred=Hash(PK_V_Lattice||LWE_Encrypt(T||LBS||V_speed)||R)

[0060] LWE_Encrypt is a fault-tolerant learning-based encryption algorithm. The ciphertext it calculates possesses quantum resistance properties and can be used as part of a dynamic credential. In the authentication process, when multiple vehicles initiate authentication with the same roadside unit, the roadside unit can aggregate the received digital signatures into a single aggregated signature. This means the roadside unit only needs to perform aggregated signature verification once, thus reducing the computational load on the roadside unit in high-density vehicle scenarios and significantly improving system throughput.

[0061] It can be seen that the dynamic credentials generated based on reputation value and current driving status information, together with the random number, constitute a dynamic and real-time vehicle identity authentication and secure communication mechanism in the Internet of Vehicles, thereby improving the security and efficiency of vehicle communication in the Internet of Vehicles environment.

[0062] Step S13: Use the vehicle's private key to perform a signature process on the roadside unit's public key, identity information, and random number to obtain a signature value;

[0063] In this embodiment, the roadside unit public key is used to encrypt messages received from the vehicle terminal, ensuring that only the corresponding roadside unit can decrypt the corresponding encrypted message.

[0064] The signature value is a data structure that combines signing and encryption, which not only ensures the confidentiality of the data, but also guarantees the integrity of the data and the authentication of the sender.

[0065] Using the vehicle's private key to perform signature processing on the roadside unit's public key, identity information, and random number, the resulting signature value can be understood as the vehicle terminal using the vehicle's private key (SK_V) to encrypt and sign specific data, generating a signature value.

[0066] For example, the vehicle terminal generates a random number Nv and calculates the signature value SC(V_priv, RSU_pub, Nv||V_ID), which is not limited here.

[0067] It can be seen that by using the vehicle's private key (SK_V) to perform signature processing on the roadside unit's public key, identity information, and random number to generate a signature value, the data is prevented from being tampered with or forged, thus ensuring the integrity, authentication, and confidentiality of the data.

[0068] Step S14: Send an authentication request via a wireless channel, wherein the authentication request includes a signature value and a dynamic credential.

[0069] In this embodiment of the application, the wireless channel refers to the wireless network channel used for communication between vehicles and roadside units in the vehicle network.

[0070] An authentication request is a message sent by the vehicle terminal to the roadside unit to request the establishment of a secure communication connection. The authentication request includes a signature value and dynamic credentials to ensure the confidentiality and non-repudiation of the communication.

[0071] Sending an authentication request via a wireless channel can be understood as the vehicle terminal sending an authentication request to the roadside unit via a wireless channel in order to establish a secure communication link.

[0072] It can be seen that sending authentication requests containing signature values ​​and dynamic credentials via wireless channels ensures the security, reliability, and real-time performance of communication between vehicle terminals and roadside units in the vehicle-to-everything (V2X) environment.

[0073] Step S15: In response to the successful authentication request, a communication link is established based on the session key, wherein the session key is determined according to the key negotiation protocol;

[0074] In this embodiment, the session key is a symmetric key used when the vehicle terminal and the roadside unit establish a temporary, secure communication session. The session key is only valid during the current communication session and is used to encrypt and decrypt all data transmitted during the session to prevent data from being eavesdropped on or tampered with during transmission.

[0075] A communication link refers to an encrypted communication channel established between the vehicle terminal and the roadside unit, used for secure data transmission after the authentication process is completed.

[0076] In response to a successful authentication request, establishing a communication link based on the session key can be understood as follows: when the vehicle terminal's authentication request is verified and confirmed as legitimate by the roadside unit, the vehicle terminal and the roadside unit will jointly generate a session key based on the key negotiation protocol, and establish a temporary and secure communication link based on the session key.

[0077] It can be seen that the vehicle terminal and the roadside unit use a session key to encrypt data and establish an encrypted communication link. This communication link ensures the security and privacy of data during transmission, thereby effectively preventing security threats such as data leakage, tampering, and man-in-the-middle attacks.

[0078] Step S16: Data exchange is performed via the communication link.

[0079] In this embodiment of the application, data exchange via a communication link can be understood as the vehicle terminal and the roadside unit communicating normally via the communication link and exchanging encrypted data.

[0080] It can be seen that data exchange through the communication link enables secure, efficient, and real-time data exchange between the vehicle terminal and the roadside unit, providing reliable data transmission support for vehicle-to-everything (V2X) communication, while also ensuring the privacy protection of vehicle data and the non-repudiation of communication.

[0081] Through the above steps, when a vehicle first connects to the vehicle-to-everything (V2X) communication network, an asymmetric key pair and a reputation value are first generated by the first blockchain master node. Then, based on the reputation value and the vehicle's current driving status information, a dynamic credential and a random number are generated. The dynamic credential reflects the vehicle's security status and identity information. Next, the vehicle's private key is used to signify the roadside unit's public key, identity information, and random number to obtain a signature value. The vehicle terminal then sends an authentication request via a wireless channel, which includes the signature value and the dynamic credential. If the authentication request passes, a communication link is established based on the session key, and finally, data exchange occurs through this communication link. This application significantly improves the speed and security of vehicle identity authentication in the V2X environment by introducing dynamic identity credentials, a lightweight on-chain authentication process, and a blockchain-based real-time detection mechanism. It reduces the risk of data leakage, enhances the system's adaptability to dynamic environments, and achieves the goal of enabling vehicles to quickly and securely connect to the V2X communication network in dynamic scenarios. This achieves the technical effect of secure communication with high dynamic adaptability and privacy protection, thereby solving the technical problems of security risks and insufficient dynamic adaptability in related technologies for V2X communication.

[0082] Optionally, the current driving status information includes: current timestamp, encrypted location coordinates, and real-time speed. The vehicle communication method also includes the following execution steps:

[0083] When the distance between the vehicle and any roadside unit is less than a preset threshold, the vehicle's current timestamp, encrypted location coordinates, and real-time speed are obtained.

[0084] In this embodiment, the current timestamp refers to the precise time stamp when the vehicle terminal collects data, which is generally in milliseconds and is not limited here.

[0085] Encrypted location coordinates refer to the encrypted location information of a vehicle. For example, Chinese cryptographic algorithms (such as SM4) or other secure encryption algorithms can be used to encrypt the vehicle's location; this is not a limitation.

[0086] Real-time speed refers to the current driving speed of a vehicle as obtained by the vehicle terminal.

[0087] In response to the distance between the vehicle and any roadside unit being less than a preset threshold, the acquisition of the vehicle's current timestamp, encrypted location coordinates, and real-time speed can be understood as follows: when the distance between the vehicle and any roadside unit is less than a preset distance, the vehicle terminal will collect the vehicle's current driving status information, including: the current timestamp, the vehicle's encrypted location coordinates, and the vehicle's real-time speed.

[0088] It can be seen that by obtaining the vehicle's current driving status information, a data foundation is provided for establishing a communication link later.

[0089] Optionally, in step S12, a dynamic certificate for the vehicle is generated based on the reputation value and the vehicle's current driving status information, including the following execution steps:

[0090] Step S121: The current timestamp, encrypted location coordinates, and real-time speed are hashed using a preset hash algorithm to obtain the first hash value;

[0091] Step S122: Concatenate the first hash value, reputation value, and vehicle public key to obtain the concatenation result;

[0092] Step S123: Hash the concatenation result using a preset hash algorithm to obtain a dynamic credential.

[0093] In this embodiment of the application, the preset hash algorithm refers to an algorithm with a fixed-length output used for data integrity verification and digest generation, such as the SM3 algorithm in the national cryptographic standard, and is not limited here.

[0094] The first hash value is a digest value obtained by hashing the vehicle's current timestamp, encrypted location coordinates, and real-time speed using a preset hash algorithm, to ensure the integrity and timeliness of the information contained therein.

[0095] The first hash value is obtained by hashing the current timestamp, encrypted location coordinates, and real-time speed using a preset hash algorithm. This can be understood as inputting the vehicle's current timestamp, encrypted location coordinates, and real-time speed into a pre-defined hash algorithm for processing, thereby generating the first hash value.

[0096] Concatenating the first hash value, reputation value, and vehicle public key yields a concatenated result. This concatenation not only includes real-time vehicle information but also integrates historical reputation assessments, providing multi-dimensional data support for generating dynamic credentials.

[0097] The process of hashing the concatenated result using a preset hash algorithm to obtain a dynamic credential can be understood as using a preset hash algorithm (such as SM3) to process the concatenated result and generate a dynamic credential for the vehicle.

[0098] It can be seen that by generating dynamic credentials for vehicles, we can not only address the challenges of dynamic identity authentication in the Internet of Vehicles and enhance authentication security, but also ensure the efficiency of data processing and the protection of vehicle privacy.

[0099] Optionally, in step S13, the roadside unit public key, identity information, and random number are signed using the vehicle's private key to obtain a signed value, including the following execution steps:

[0100] Step S131: Concatenate the identity information and the random number to obtain a data string;

[0101] Step S132: Sign the data string based on the vehicle's private key to obtain a signature value;

[0102] Step S133: Encrypt the data string, signature value, and roadside unit public key based on a preset encryption algorithm to obtain the signature value.

[0103] In this embodiment, the signature value is the result of signing a data string containing vehicle identification information and a random number. The signature value ensures that the data is not tampered with during transmission and verifies the authenticity of the sender.

[0104] The preset encryption algorithm can be a hybrid encryption technique, combining the advantages of asymmetric and symmetric encryption. Asymmetric encryption is used to generate signatures and verify identity, while symmetric encryption is used for efficient encrypted data transmission; no restrictions are imposed here.

[0105] By concatenating identification information with random numbers to obtain a data string, it can be understood that the vehicle's identification information is combined with randomly generated numbers (i.e., random number Nv) to form a data string, thereby enhancing the randomness and unpredictability of the data.

[0106] Signing a data string using the vehicle's private key to obtain a signature value can be understood as using the digital signature mechanism in asymmetric encryption technology to sign the concatenated data string using the vehicle's private key (SK_V), thereby generating a signature value.

[0107] The signature value is obtained by encrypting the data string, signature value and roadside unit public key based on the preset encryption algorithm. It can be understood that a hybrid encryption strategy is adopted. First, the data string and signature value are encrypted using a symmetric encryption algorithm. Then, the entire encrypted message and possible session keys are encapsulated using asymmetric encryption to obtain the signature value.

[0108] It can be seen that by encrypting the data string, signature value, and public key of the roadside unit using a preset encryption algorithm to generate a signature value, not only is the data protected from eavesdropping, but the secure transmission of data is also achieved, thereby strengthening data privacy protection in the vehicle-to-everything (V2X) environment.

[0109] Optionally, any roadside unit includes: a federated learning module; and after the communication link is established, the vehicle communication method further includes:

[0110] Step S17: Obtain the feature vector from the driving environment data;

[0111] Step S18: Encrypt the feature vector using a preset encryption algorithm to obtain an encrypted feature vector;

[0112] Step S19: Update the federated learning module based on the encrypted feature vector.

[0113] In this embodiment, the federated learning module is used to execute machine learning algorithms based on distributed data without directly accessing the original data. Within the federated learning module, the vehicle terminal or roadside unit retains its own data, sharing only gradient updates or a portion of the model parameters during model iteration; this is not restricted here.

[0114] Encrypted feature vectors are data representations extracted from driving environment data and encrypted with sensitive information.

[0115] The acquisition of feature vectors from driving environment data can be understood as the vehicle terminal collecting data from various sensors (such as camera images, radar signals, location coordinates, etc.) and extracting useful feature vectors from the above data, such as road conditions, distribution of surrounding vehicles, and pedestrian positions, etc., without limitation here.

[0116] Encrypting the feature vector using a preset encryption algorithm to obtain an encrypted feature vector can be understood as follows: in order to avoid the leakage of the original data, the above feature vector is encrypted using a preset encryption algorithm (such as the Paillier homomorphic encryption algorithm) to generate an encrypted feature vector.

[0117] Updating the federated learning module based on encrypted feature vectors can be understood as allowing vehicles to participate in the collaborative training process of the federated learning module while maintaining data privacy, thus ensuring the effectiveness of the federated learning module and the security of data processing.

[0118] For example, after the communication link is established, privacy-enhanced federated learning collaborative computation begins. The vehicle terminal collects environmental data through local sensors, extracts feature vectors at the edge, and then encrypts the features using the Paillier homomorphic encryption algorithm. The encrypted feature data, along with the gradient parameters of the locally trained model, is uploaded to the edge server. The server aggregates data from multiple nodes and performs a global federated learning model update. During this process, the smart contract dynamically monitors the contribution of each node and adds (ε, δ)-differential privacy-compliant Laplacian noise to the uploaded gradients. The noise intensity is adjusted in stages according to data sensitivity. The hash value of the gradient parameters is recorded to the blockchain in real time, effectively preventing gradient tampering and poisoning attacks; however, this is not restricted here.

[0119] As can be seen, the above steps not only improve the training efficiency of the federated learning module, but also greatly reduce the risk of data leakage during transmission and storage, thus meeting the dual needs of data collaboration and privacy protection in the Internet of Vehicles environment.

[0120] This embodiment provides yet another vehicle communication method. Figure 2 This is a flowchart of another vehicle communication method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0121] Step S21: Receive an authentication request, wherein the authentication request includes a signature value and a dynamic credential;

[0122] Step S22: Decrypt the signature value using the vehicle's public key to obtain the decryption result;

[0123] Step S23: Verify the decryption result to obtain the first verification result;

[0124] Step S24: Verify the dynamic credentials through the smart contract to obtain the second verification result. The smart contract is used to manage the identity information of the vehicle and any roadside unit.

[0125] Step S25: In response to the fact that both the first verification result and the second verification result indicate that the verification is successful, a communication link is established based on the session key, wherein the session key is determined according to the key negotiation protocol;

[0126] Step S26: Data exchange is performed via the communication link.

[0127] In this embodiment of the application, the smart contract is program code that runs on the blockchain network and is mainly used to manage the identity information between the vehicle terminal and the roadside unit, verify dynamic credentials, and execute security policies.

[0128] Receiving an authentication request can be understood as the roadside unit receiving an authentication request sent by the vehicle through the wireless communication network, and the authentication request includes a signature value that has been encrypted and signed, as well as a dynamic credential.

[0129] The process of decrypting the signature value using the vehicle's public key can be understood as the roadside unit using the vehicle's public key (PK_V) stored in advance or obtained from the blockchain to decrypt the signature value and obtain the decryption result.

[0130] Verifying the decryption result and obtaining the first verification result can be understood as the roadside unit further verifying the vehicle identification information and random number in the decryption result to obtain the first verification result.

[0131] The second verification result obtained by verifying the dynamic credentials through smart contracts can be understood as the roadside unit using smart contracts to verify the vehicle driving status information and reputation value in the dynamic credentials and obtain the second verification result.

[0132] In response to both the first and second verification results indicating that the verification is successful, establishing a communication link based on the session key can be understood as follows: if both the first and second verification results indicate that the verification is successful, the roadside unit establishes a communication link with the vehicle terminal based on the session key.

[0133] Data exchange via a communication link can be understood as the vehicle terminal and roadside unit exchanging data based on the communication link, including but not limited to driving environment data, vehicle status information, and model parameter updates in federated learning, etc., which are not limited here.

[0134] For example, upon receiving a request, the roadside unit uses the pre-stored vehicle public key PK_V to decrypt and verify the legitimacy of the random number Nv and the vehicle identifier V_ID. Simultaneously, it verifies the validity of the dynamic credential Cred through a sidechain smart contract. After successful verification, both parties establish a secure communication link based on the negotiated session key K. The entire authentication process takes less than 87ms, and the authentication event hash value is stored on the blockchain in real time; no restrictions are imposed here.

[0135] As can be seen, through the above steps, the roadside unit first receives the authentication request, decrypts the signature value using the vehicle's public key, obtains the decryption result, then verifies the decryption result to obtain the first verification result, and then verifies the dynamic credential through the smart contract to obtain the second verification result. If both the first and second verification results indicate that the verification is successful, a communication link is established based on the session key, and finally, data is exchanged through the communication link. This achieves the goal of enabling vehicles to quickly and securely establish communication with the roadside unit while in dynamic driving conditions. Thus, it realizes the technical effect of efficient communication between vehicles and roadside units while ensuring privacy, security, and data integrity, thereby solving the technical problems of security risks and insufficient dynamic adaptability in vehicle-to-everything (V2X) communication in related technologies.

[0136] Optionally, the decryption result includes: vehicle identification information and a random number. In step S23, the decryption result is verified to obtain a first verification result, including the following execution steps:

[0137] Verify whether the random number is a historical value, and verify whether the identity information matches the pre-stored vehicle information.

[0138] In this embodiment, verifying whether the random number is a historically used value can be understood as the roadside unit's authentication server, upon receiving an authentication request from a vehicle, checking whether the random number Nv contained in the request has been used in a previous session, thereby preventing replay attacks. A replay attack refers to an attacker recording valid communication data (such as an authentication request) and resending it later, thereby gaining unauthorized access to the system. For example, if the roadside unit determines that the random number Nv in the request is duplicated, the authentication process will be interrupted, thereby enhancing the overall system security and its ability to resist attacks.

[0139] Verifying the consistency between the identity information and the pre-stored vehicle information can be understood as the roadside unit verifying the identity information in the received authentication request to ensure that it matches the vehicle information pre-stored by the roadside unit or authentication server. For example, if the identity information in the authentication request matches the pre-stored vehicle information, indicating that the vehicle identity is valid and has not been tampered with, the first verification result is successful, allowing the establishment of a secure communication link; otherwise, the first verification result is unsuccessful, authentication fails, and communication is blocked. This is not strictly limited here.

[0140] It can be seen that by verifying whether the random number is a historical value, the system can effectively resist replay attacks. By verifying the consistency between the identity information and the pre-stored vehicle information, it ensures that only legitimate and in good condition vehicles can access the network, thus jointly maintaining the security and reliability of vehicle network communication.

[0141] Optionally, the dynamic credential includes: the vehicle's current timestamp, encrypted location coordinates, real-time speed, and reputation value. In step S24, the dynamic credential is verified through a smart contract to obtain a second verification result, including the following execution steps:

[0142] Step S241: Send the dynamic credentials to the smart contract on the blockchain sidechain;

[0143] Step S242: The current timestamp, encrypted location coordinates, real-time speed, and reputation value are hashed using a smart contract to obtain a second hash value;

[0144] Step S243: Verify whether the hash value in the dynamic credential matches the second hash value to obtain the second verification result.

[0145] In this embodiment of the application, sending the dynamic credentials to the smart contract on the blockchain sidechain can be understood as the roadside unit forwarding the dynamic credentials to the smart contract on the blockchain sidechain for verification after receiving the vehicle's authentication request.

[0146] The second hash value is obtained by hashing the current timestamp, encrypted location coordinates, real-time speed, and reputation value through a smart contract. This can be understood as the smart contract recalculating the hash value of key fields such as timestamp, encrypted location coordinates, real-time speed, and historical reputation value contained in the dynamic credential, thereby obtaining the second hash value.

[0147] Verifying whether the hash value in the dynamic credential matches the second hash value to obtain the second verification result can be understood as comparing whether the original hash value in the dynamic credential is consistent with the newly calculated second hash value, thus obtaining the second verification result. For example, if the two hash values ​​match, it means that the dynamic credential has not been tampered with during transmission, and all included timestamps, locations, speeds, and reputation values ​​meet the latest requirements; otherwise, it indicates that the credential may have been tampered with or its status does not meet the requirements, and authentication will be considered a failure. This is not limited to specific cases.

[0148] As can be seen, through the verification process executed by the smart contract described above, this application can ensure that the identity credentials dynamically generated by each vehicle are correctly and securely verified in the vehicle network communication, effectively preventing various security threats, including replay attacks, while ensuring the integrity of the data and the authenticity of the vehicle status.

[0149] Optionally, the vehicle communication method also includes:

[0150] Continuously monitor any communication node;

[0151] The real-time anomaly score of any communication node is calculated based on a historical feature template library, which is used to record historical anomaly communication features.

[0152] In response to a real-time anomaly score exceeding a preset anomaly threshold, an anomaly report is generated within a first preset time period.

[0153] The abnormal reports are verified based on smart contracts to obtain the abnormal behavior of any communication node.

[0154] In response to abnormal behavior matching a preset abnormal pattern, the reputation value of any communication node is reset, where the preset abnormal pattern is stored in the blockchain.

[0155] In this embodiment, the historical feature template library is a database compiled by analyzing past abnormal communication instances, extracting common features, and summarizing them. For example, the historical feature template library stores the feature patterns of all abnormal communication behaviors identified in the past, which may include, but are not limited to, abnormal communication frequency, data packet size, transmission rate, abnormal occurrence of specific types of data, and frequent communication with other known malicious nodes, etc., and are not limited here.

[0156] The preset abnormal patterns are standardized and typical abnormal communication behavior manifestations that are further refined from data analysis in the historical feature template library.

[0157] Continuous monitoring of any communication node can be understood as the roadside unit identifying potential anomalies or suspicious activities by analyzing and monitoring the data flow and behavior patterns of all communication nodes in real time.

[0158] Calculating the real-time anomaly score of any communication node based on the historical feature template library can be understood as the roadside unit calculating a real-time anomaly score for each communication node at each time point based on the abnormal behavior patterns stored in the historical feature template library.

[0159] In response to a real-time anomaly score exceeding a preset anomaly threshold, generating an anomaly report within a first preset time period can be understood as follows: when the real-time anomaly score of a certain communication node exceeds a preset safety threshold, the monitoring system will generate an anomaly report to record in detail the specific circumstances of the abnormal behavior, including but not limited to the value of the anomaly score, the time point when the anomaly was triggered, and the specific manifestations of the abnormal behavior.

[0160] The verification of anomaly reports based on smart contracts means that any abnormal behavior of a communication node can be understood as follows: the anomaly report will be submitted to a smart contract on the blockchain, and the smart contract will automatically match and verify it against a preset anomaly pattern to determine the abnormal behavior of any communication node.

[0161] Resetting the reputation value of any communication node in response to anomaly behavior matching a preset anomaly pattern can be understood as follows: when a smart contract confirms that anomaly behavior matches a built-in anomaly pattern, it will reset the reputation value of that communication node. For example, the reputation value of the communication node is typically set to a low value to reflect that the node's current state is untrustworthy; this is not a limitation here.

[0162] For example, Figure 3 This is an optional on-chain trusted anomaly real-time detection flowchart according to an embodiment of this application, such as... Figure 3 As shown, the system operates a parallel on-chain trusted anomaly detection mechanism. Each roadside unit node continuously monitors communication traffic and node behavior, calculating a real-time anomaly score based on a historical feature template library. When a real-time anomaly score exceeds a preset anomaly threshold, the local node generates an anomaly event transaction report within 200ms and submits it to the smart contract for on-chain verification. The smart contract matches the anomaly characteristics with the historical feature template library stored on the blockchain. If an attack is confirmed, the historical feature template library is automatically updated, and an alarm is broadcast to the entire network. If an attack cannot be confirmed, multi-node voting verification is performed. For confirmed malicious nodes, the smart contract immediately performs an identity revocation operation, resetting their historical reputation value R to 0 and permanently recording the attack evidence in the blockchain's immutable storage (no restrictions are imposed here).

[0163] As can be seen, by taking the above steps, effectively monitoring and responding to abnormal communication behavior in the vehicle-to-everything (V2X) environment not only improves the overall security level of the system, but also enables the efficiency and accuracy of the anomaly detection and response process through the automated operation of smart contracts.

[0164] Optionally, the vehicle communication method also includes:

[0165] In response to the detection that a vehicle has entered the second vehicle network coverage area, the vehicle's authentication status is synchronized to the second blockchain master node in the second vehicle network coverage area according to the cross-chain protocol. The vehicle network communication network is deployed in the second vehicle network coverage area.

[0166] The vehicle's asymmetric key pair is updated within a second preset time period based on a preset hash algorithm to obtain the updated asymmetric key pair;

[0167] The vehicle is authenticated using the updated asymmetric key.

[0168] In this embodiment, the cross-chain protocol allows for secure data exchange and state synchronization between different blockchain networks. Specifically, when a vehicle moves from one vehicle-to-everything (V2X) coverage area (first V2X) to another (second V2X) coverage area, the cross-chain protocol is activated. This ensures that the authentication status information in the first V2X coverage area can be transmitted and verified to the blockchain nodes in the first V2X coverage area, avoiding the need for the vehicle to undergo a complete identity authentication process every time it crosses a regional boundary.

[0169] The second blockchain master node refers to a node deployed in the blockchain network within the coverage area of ​​the second vehicle network. It is responsible for executing smart contracts, maintaining the distributed ledger and global identity authentication information, and coordinating all blockchain-related operations within the area.

[0170] In response to the detection that a vehicle has entered the second vehicle network coverage area, the authentication status of the vehicle is synchronized to the second blockchain master node in the second vehicle network coverage area according to the cross-chain protocol. This can be understood as follows: when the system detects that a vehicle has moved from the first vehicle network coverage area to the second vehicle network coverage area, the blockchain master node in the first vehicle network coverage area will immediately and seamlessly transmit the current authentication status information of the vehicle to the second blockchain master node in the second vehicle network coverage area according to the preset cross-chain protocol.

[0171] The system updates the vehicle's asymmetric key pair within a second preset time period based on a preset hash algorithm. The updated asymmetric key pair can be understood as follows: after the vehicle enters the second vehicle network coverage area, within the second preset time period (e.g., a few seconds to tens of seconds), the system will automatically update the vehicle's asymmetric key pair (including the public key PK and the private key SK) according to a preset national cryptographic algorithm (such as SM2) to generate the updated key pair.

[0172] Authenticating a vehicle using the updated asymmetric key pair can be understood as follows: after the vehicle's asymmetric key pair is updated, the second blockchain master node will use the updated asymmetric key pair to verify the vehicle's identity.

[0173] As can be seen, through the above steps, this application can not only quickly synchronize the vehicle's authentication status to the blockchain master node of the new region in the scenario of vehicle cross-domain movement, but also complete the update of asymmetric key pairs and the verification of vehicle identity in a short time, thereby improving the adaptability and security of the Internet of Vehicles in dynamic environments.

[0174] Figure 4 This is a flowchart of an optional dynamic identity authentication method according to an embodiment of this application, such as... Figure 4As shown, when a vehicle first joins the network, the vehicle terminal applies for and registers its identity with the blockchain master node, generating an asymmetric key pair based on national cryptographic algorithms (SM2 / SM3 / SM4). The vehicle terminal generates a dynamic identity credential using a hash algorithm based on real-time status (such as timestamps, encrypted location information, vehicle speed, etc.) and historical reputation values. The vehicle broadcasts the signature value and dynamic credential, performs signature calculation using its private key, and conducts two-way authentication with the roadside unit. The roadside unit verifies the validity of the signature information and dynamic credential.

[0175] Figure 5 This is a flowchart of an optional blockchain anchoring mechanism according to an embodiment of this application, such as... Figure 5 As shown, the roadside unit performs desigma verification, which involves matching the vehicle's encrypted location coordinates and speed information. After successful authentication, the vehicle and the roadside unit will negotiate to generate a session key and establish a secure communication link. Finally, the authentication event hash value is recorded in real time to the blockchain sidechain, enabling rapid response to identity updates and revocations.

[0176] Figure 6 This is a schematic diagram of an optional privacy-enhanced federated learning hierarchical architecture according to an embodiment of this application, such as... Figure 6 As shown, the privacy-enhanced federated learning layered architecture includes: Edge layer: Vehicles and roadside unit terminals extract feature vectors from local data and encrypt the data using homomorphic encryption algorithms (such as Paillier). On-chain computation layer: Edge servers aggregate the encrypted data, and the federated learning model performs global updates on the blockchain. Node contributions are dynamically monitored through smart contracts. Privacy protection layer: Differential privacy technology is applied to gradient uploading to ensure data privacy and security during transmission and aggregation. Smart contract layer: Manages all aspects of federated learning, including task distribution, gradient aggregation, and model updates, while recording metadata and gradient hashes to ensure the transparency and auditability of the computation process.

[0177] Figure 7 This is a response timing diagram of an optional on-chain trusted anomaly detection according to an embodiment of this application, such as... Figure 7 As shown, the roadside unit monitors communication traffic and calculates real-time anomaly scores based on historical feature templates. When abnormal behavior is detected, the system generates an anomaly report within a first preset time period and reports the abnormal event transaction to a smart contract on the blockchain for verification. The smart contract compares the abnormal event transaction with preset anomaly patterns. If the abnormal event transaction is confirmed as an attack, a network-wide warning is triggered and the historical feature template is updated. If the abnormal event transaction is confirmed as a suspected attack, multi-node voting is initiated.

[0178] Figure 8 This is an optional dynamic scene adaptation technology architecture diagram according to an embodiment of this application, such as... Figure 8As shown, when a vehicle is moving at high speed, the national cryptographic algorithm SM2 is used for key updates, preparing to switch to the authentication system of the next area. A bridging mechanism between the two blockchain networks ensures rapid synchronization of identity information and authentication status. When the vehicle enters a new area, the roadside unit in the new area quickly completes secondary verification based on the synchronized authentication status (e.g., within 50ms), without needing to repeat the entire process. Through this efficient switching mechanism, vehicles can communicate seamlessly in different vehicle-to-everything (V2X) coverage areas, ensuring the real-time performance and security of applications such as autonomous driving. Furthermore, the system ensures regulatory compliance through a data anonymization and tiered strategy. In accordance with the General Data Protection Regulation (GDPR) minimization principle, the onboard terminal only uploads homomorphically encrypted feature vectors and gradient parameters with added differential privacy noise; the original sensor data remains locally. The blockchain only stores the hash value of the encrypted data, model metadata, and authentication records, achieving a balance between maximizing data value and minimizing privacy risks; no restrictions are imposed here.

[0179] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0180] According to the embodiments of this application, an embodiment of a vehicle communication device is provided. It should be noted that the device can be used to execute the above-described vehicle communication method.

[0181] Figure 9 This is a schematic diagram of an optional vehicle communication device according to an embodiment of this application, such as... Figure 9As shown, the vehicle communication device 900 includes: a first generation module 901, used to generate an asymmetric key pair and a reputation value through a first blockchain master node in response to the vehicle's first access to the vehicle network communication network, wherein the vehicle network communication network is deployed in the first vehicle network coverage area, the asymmetric key pair includes a vehicle public key and a vehicle private key, and the reputation value is used to evaluate the vehicle's security behavior; a second generation module 902, used to generate a dynamic credential and a random number for the vehicle based on the reputation value and the vehicle's current driving status information, wherein the dynamic credential is used to reflect the vehicle's security status and identity information; a first processing module 903, used to perform signature processing on the roadside unit public key, identity information, and random number using the vehicle private key to obtain a signature value; a sending module 904, used to send an authentication request through a wireless channel, wherein the authentication request includes the signature value and the dynamic credential; a first establishment module 905, used to establish a communication link based on a session key in response to the successful authentication request, wherein the session key is determined according to a key negotiation protocol; and a first exchange module 906, used to exchange data through the communication link.

[0182] Figure 10 This is a schematic diagram of another optional vehicle communication device according to an embodiment of this application, such as... Figure 10 As shown, the vehicle communication device 1000 includes: a receiving module 1001 for receiving an authentication request, wherein the authentication request includes a signature value and a dynamic credential; a second processing module 1002 for decrypting the signature value using the vehicle's public key to obtain a decryption result; a first verification module 1003 for verifying the decryption result to obtain a first verification result; a second verification module 1004 for verifying the dynamic credential using a smart contract to obtain a second verification result, wherein the smart contract is used to manage the identity information of the vehicle and any roadside unit; a second establishment module 1005 for establishing a communication link based on a session key in response to both the first and second verification results indicating successful verification, wherein the session key is determined according to a key negotiation protocol; and a second exchange module 1006 for exchanging data through the communication link.

[0183] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0184] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0185] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the methods in various embodiments of this application.

[0186] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0187] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0188] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0189] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0190] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0191] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0192] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

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

Claims

1. A vehicle communication method, characterized in that, The method includes: In response to a vehicle's first access to the vehicle-to-everything (V2X) communication network, an asymmetric key pair and a reputation value are generated through the first blockchain master node. The V2X communication network is deployed in the first V2X coverage area. The asymmetric key pair includes a vehicle public key and a vehicle private key. The reputation value is used to evaluate the vehicle's security behavior. Based on the reputation value and the vehicle's current driving status information, a dynamic credential and a random number are generated for the vehicle, wherein the dynamic credential is used to reflect the vehicle's security status and identity information; The vehicle's private key is used to perform a signature-crypto processing on the roadside unit's public key, the identity information, and the random number to obtain a signature value; An authentication request is sent via a wireless channel, wherein the authentication request includes the signature value and the dynamic credential; Upon successful authentication, a communication link is established based on a session key, wherein the session key is determined according to a key negotiation protocol. Data is exchanged through the communication link.

2. The method according to claim 1, characterized in that, The current driving status information includes: current timestamp, encrypted location coordinates, and real-time speed. The method further includes: In response to the distance between the vehicle and any roadside unit being less than a preset threshold, the vehicle's current timestamp, encrypted location coordinates, and real-time speed are obtained.

3. The method according to claim 2, characterized in that, The step of generating a dynamic credential for the vehicle based on the reputation value and the vehicle's current driving status information includes: The current timestamp, the encrypted location coordinates, and the real-time speed are hashed using a preset hash algorithm to obtain a first hash value. The first hash value, the reputation value, and the vehicle public key are concatenated to obtain the concatenation result; The concatenation result is hashed using the preset hash algorithm to obtain the dynamic credential.

4. The method according to claim 1, characterized in that, The step of using the vehicle's private key to perform cryptographic processing on the roadside unit's public key, the identity information, and the random number to obtain a cryptographic value includes: The identity information and the random number are concatenated to obtain a data string; The data string is signed based on the vehicle's private key to obtain a signature value; The data string, the signature value, and the roadside unit public key are encrypted using a preset encryption algorithm to obtain the signature value.

5. The method according to claim 2, characterized in that, Each roadside unit includes a federated learning module. After the communication link is established, the method further includes: Obtain feature vectors from driving environment data; The feature vector is encrypted using a preset encryption algorithm to obtain an encrypted feature vector; The federated learning module is updated based on the encrypted feature vector.

6. A vehicle communication method, characterized in that, The method includes: Receive an authentication request, wherein the authentication request includes a signature value and a dynamic credential; The signature value is decrypted using the vehicle's public key to obtain the decryption result; The decryption result is verified to obtain the first verification result; The dynamic credentials are verified by a smart contract to obtain a second verification result, wherein the smart contract is used to manage the identity information of the vehicle and any roadside unit. In response to both the first verification result and the second verification result indicating that the verification is successful, a communication link is established based on the session key, wherein the session key is determined according to a key negotiation protocol; Data is exchanged through the communication link.

7. The method according to claim 6, characterized in that, The decryption result includes: the vehicle's identification information and a random number. Verifying the decryption result to obtain a first verification result includes: Verify whether the random number is a historical value, and verify whether the identity information is consistent with the pre-stored vehicle information.

8. The method according to claim 6, characterized in that, The dynamic credential includes: the vehicle's current timestamp, encrypted location coordinates, real-time speed, and reputation value. The verification of the dynamic credential via a smart contract to obtain a second verification result includes: Send the dynamic credentials to the smart contract on the blockchain sidechain; The smart contract performs hash processing on the current timestamp, the encrypted location coordinates, the real-time speed, and the reputation value to obtain a second hash value. The second verification result is obtained by verifying whether the hash value in the dynamic credential matches the second hash value.

9. The method according to claim 6, characterized in that, The method further includes: Continuously monitor any communication node; The real-time anomaly score of any of the communication nodes is calculated based on a historical feature template library, wherein the historical feature template library is used to record historical anomaly communication features. In response to the real-time anomaly score being greater than a preset anomaly threshold, an anomaly report is generated within a first preset time period. The anomaly report is verified based on the smart contract to obtain the abnormal behavior of any of the communication nodes; In response to the abnormal behavior matching a preset abnormal pattern, the reputation value of any of the communication nodes is reset, wherein the preset abnormal pattern is stored in the blockchain.

10. The method according to claim 6, characterized in that, The method further includes: In response to the detection that the vehicle has entered the second vehicle network coverage area, the authentication status of the vehicle is synchronized to the second blockchain master node in the second vehicle network coverage area according to the cross-chain protocol, wherein a vehicle network communication network is deployed in the second vehicle network coverage area; The asymmetric key pair of the vehicle is updated within a second preset time period based on a preset hash algorithm to obtain the updated asymmetric key pair; The vehicle is authenticated based on the updated asymmetric key pair.

Images