A Decentralized Authentication and Key Exchange Method Based on Blockchain

Abstract

This invention discloses a decentralized authentication and key exchange method based on blockchain, comprising the following steps: an initialization phase, a registration phase, an RSU registration and data synchronization phase, a vehicle login phase, an identity authentication and pseudo-identity update phase, and a key exchange phase. The initialization phase provides global security parameters and a foundation for reputation management. The registration phase enables vehicles and RSUs to obtain legitimate identities and key materials. The RSU registration and data synchronization phase ensures rapid verification and reputation assessment while the vehicle is in motion. The vehicle login phase establishes a session with the TA and determines permissions. The identity authentication phase ensures the legitimacy of communication and defends against attacks. The pseudo-identity update and key exchange phase ensures anonymity and secure session establishment. This invention effectively improves the security of identity verification and optimizes communication efficiency through a dynamic reputation management mechanism.

Description

Technical Field

[0001] This invention belongs to the field of identity verification technology, and specifically relates to a decentralized authentication and key exchange method based on blockchain. Background Technology

[0002] With the rapid development of vehicle-to-everything (IoV) technology, applications such as intelligent transportation and autonomous driving have received widespread attention. IoV enables real-time data exchange through the collaboration of vehicles, road infrastructure, and sensors to improve traffic efficiency and driving safety. However, with the surge in the number of vehicles and the complexity of traffic environments, IoV systems face severe security and privacy challenges. Due to the highly dynamic nature of the IoV environment, frequent network switching, and the presence of a large number of nodes, traditional centralized authentication schemes suffer from single points of failure, excessive computational burden, and privacy leaks. Especially in high-density traffic scenarios, when vehicles simultaneously initiate authentication and key exchange requests, system overhead and computational burden increase dramatically, potentially leading to communication delays or network congestion.

[0003] Traditional centralized authentication schemes typically rely on a central trusted authority, such as a Trusted Management Center (TA), Certificate Authority (CA), or cloud server, to uniformly generate system parameters, distribute keys, and maintain the vehicle's true identity. When a vehicle connects to the network, it must initiate an authentication request to the central entity to complete identity verification and key negotiation. This type of scheme has a significant single point of failure risk; the central server's computational burden is too heavy, making it difficult to maintain high efficiency in environments with high-speed vehicle movement and frequent network switching; it also easily leads to user privacy leaks.

[0004] Some studies have proposed using identity-based signatures or conditional anonymity mechanisms (such as the CPPA scheme) to achieve two-way authentication and privacy protection. By assigning a pseudo-identity to each message and having a central authority restore the real identity when necessary, message authentication and traceability are achieved. However, such schemes are insufficient in terms of communication and storage overhead to meet the ultra-low latency emergency message requirements of connected vehicles. Furthermore, the system's secret keys are stored long-term in tamper-proof devices, and the risk of key leakage increases significantly over time and with the rise of side-channel attacks.

[0005] For resource-constrained in-vehicle environments, some solutions employ elliptic curve cryptography (ECC), aggregate signatures, and physically unclonable functions (PUF) to design lightweight authentication and key exchange protocols. These solutions can significantly reduce communication and computational overhead while enhancing resistance to physical capture attacks, enabling efficient execution of authentication and key negotiation processes. However, in practical applications, issues remain, including insufficient anonymity, limited resistance to impersonation, and inadequate node group coordination and scalability.

[0006] In recent years, blockchain technology has been introduced into vehicle-to-everything (V2X) identity authentication and reputation management. Through smart contracts and distributed ledgers, vehicles can complete identity verification without relying on centralized certification authorities and ensure the immutability of messages, improving system transparency and data integrity. This type of solution can alleviate single points of failure and improve network robustness. However, relying solely on the blockchain ledger itself makes it difficult to comprehensively assess the trustworthiness of node behavior; in highly dynamic and high-density V2X environments, computational overhead and communication latency still require further optimization.

[0007] In summary, existing technical solutions still have limitations in solving the problems of vehicle network identity authentication and key exchange, such as insufficient real-time performance, high communication and computing overhead, limited protection against complex attacks, and insufficient dynamic reputation management. Summary of the Invention

[0008] To overcome the aforementioned technical problems, the present invention aims to provide a decentralized authentication and key exchange method based on blockchain. This method combines physically unclonable functions and zero-knowledge proof technology, effectively improving the security of identity verification and optimizing communication efficiency through a dynamic reputation management mechanism. Through blockchain technology, vehicles can undergo secure authentication without relying on a centralized certification authority, eliminating the risk of single points of failure and providing greater transparency and data integrity guarantees. Simultaneously, the use of a lightweight key exchange protocol reduces computational and communication overhead, making it more adaptable to resource-constrained and highly dynamic environments.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] A decentralized authentication and key exchange method based on blockchain includes the following steps;

[0011] It includes the initialization phase, registration phase, RSU registration and data synchronization phase, vehicle login phase, identity authentication and pseudo-identity update phase, and key exchange phase;

[0012] The initialization phase is used by the Trusted Authority (TA) to generate system security parameters before system deployment, including elliptic curves, subgroups, generators, and bilinear mappings, and to allocate initial public-private key pairs, hash functions, and initial reputation values ​​to vehicles and RSUs. This phase ensures the security and consistency of the system's global parameters, and pre-installs smart contracts on the blockchain to store vehicle and RSU registration information and reputation data, providing a trusted foundation for subsequent authentication and key exchange.

[0013] The registration phase involves vehicles submitting their identity, password, and biometric information to the TA via the On-Board Unit (OBU). The TA verifies the legitimacy of the identity and generates the vehicle's public and private keys, challenge-response pairs (CRPs), and fuzz extractor parameters. Simultaneously, it initializes the vehicle's reputation status and stores the relevant information in the blockchain and the on-board module. This phase ensures that each vehicle obtains a unique and legitimate identity and can participate in subsequent secure communications.

[0014] The RSU registration and data synchronization phase is used for Roadside Units (RSUs) to register with the TA before deployment and synchronize vehicle reputation information within the coverage area. The RSU stores lightweight vehicle information for rapid identity verification and evaluates vehicle reputation values ​​in subsequent communications, dynamically adjusting communication priorities and access permissions. This phase ensures that the RSU can provide continuous and secure services while reducing the overhead of repeated authentication.

[0015] The vehicle login phase is used by registered vehicles to establish a legitimate session with the TA (Task Authority) through the login process. The vehicle verifies its own identity, password, and biometrics, and uses the PUF (Power-Only Function) to generate a challenge response for identity confirmation. The TA verifies the legitimacy and performs an access decision based on the vehicle's reputation. This phase ensures that the vehicle can obtain a legitimate identity and communication permissions in the network, providing a foundation for subsequent identity authentication and key exchange.

[0016] The authentication mechanism is used for two-way authentication between the vehicle, RSU, and TA. It verifies the PUF response, root identifier, pseudo-identity (PID), and zero-knowledge proof (ZKP) to ensure the legitimacy of both communicating parties and detects desynchronization attacks or identity forgery. Authentication ensures the security of data transmission and the legitimacy of communication, providing a safeguard against pseudo-identity updates and key exchange.

[0017] The pseudo-identity update phase and key exchange phase are used to update the vehicle's pseudo-identity PID to ensure anonymity after identity authentication is completed, and to negotiate a session key with the communication partner; the key exchange phase uses key materials generated by ECC multiplication and PUF to establish a secure session, ensuring that both parties can achieve secure data transmission in a highly dynamic network environment, while preventing key leakage and impersonation attacks.

[0018] The functions of the six steps and their interrelationships are as follows:

[0019] The initialization phase provides global security parameters and a foundation for reputation management; the registration phase enables vehicles and RSUs to obtain legitimate identities and key materials. The RSU registration and data synchronization phase ensures rapid verification and reputation assessment while vehicles are in motion. The vehicle login phase establishes a session with the TA and determines permissions. The identity authentication phase ensures the legitimacy of communication and defends against attacks. The pseudo-identity update and key exchange phase ensures anonymity and secure session establishment.

[0020] The initialization phase specifically refers to:

[0021] Given a security parameter λ, TA generates an elliptic curve over the finite field Fz. Where z is a prime power; then, in A subgroup G is selected from the additive group, with generator P, where q is a prime order of P; the car manufacturer configures associated secret parameters and records them in the blockchain. A blockchain smart contract is used to store vehicle and RSU registration information, including public and private keys, identity identifiers, and reputation scores; TA selects a secure hash function. Create your own public / private key pair , , and select and For two prime-order subgroups on the curve, Define a bilinear mapping for the target group: Satisfy any , and ,have The TA pre-sets the range of reputation values ​​in the smart contract. Initial reputation value Historical decay factor Historical weight in reputation updates Reputation threshold Time unit .

[0022] The registration phase specifically includes:

[0023] Before the OBU is actually deployed, it must be registered with the TA.

[0024] Step 1: The user first selects their identity. Key And enter the password Biological characteristics ,calculate , Users send messages through secure channels Send to TA;

[0025] Step 2: TA Inspection The system verifies the legitimacy of the identity and checks its uniqueness in its database. If the uniqueness is not satisfied, the user is required to select a different identity. Legal and unique, TA chooses Generate random numbers ,challenge The TA runs the Groth16 Setup algorithm to generate common parameters and proof / verification keys for the vehicle. Initialize reputation status as ,in This represents the vehicle's current credit score. The last valid timestamp for reputation updates. This is a malicious behavior counter, initialized to... TA assigns an initial reputation value to the vehicle. value range And calculate the root identifier of the reputation mechanism. , , , , , , , and TA stores information { } to the blockchain and send the message The data is transmitted to the onboard unit of vehicle A via a secure channel.

[0026] Step 3: After the user device receives the message, vehicle A generates the challenge. According to user input Generate relevant biometric parameters And generate a response to the challenge via PUF. Simultaneously, the device uses a fuzz extractor to process the noise in the PUF response and generate... and calculate , .equipment storage{ }, assuming that Tamper-resistant data stored in vehicle A In, and will Stored in the TPM of vehicle A.

[0027] The RSU registration and data synchronization phase specifically includes:

[0028] Before actual deployment, RSU must also register with TA and synchronize some vehicle information. RSU only maintains a vehicle reputation cache table related to its coverage area. Each record contains only lightweight fields such as identity information, reputation value, and corresponding block height. If the information broadcast by the vehicle is not stored in RSU, the vehicle is allowed to conduct low-priority basic AKE communication. At the same time, RSU asynchronously synchronizes the vehicle's reputation information from the blockchain or neighboring RSUs in the background and dynamically adjusts its communication permissions and priorities after synchronization is completed.

[0029] Description of the RSU registration and data synchronization process;

[0030] Step 1: The TA first selects their identity identifier. key And generate The TA runs the Groth16 Setup algorithm to generate common parameters and proof / verification keys for the RSU. and calculate , ,in The public reference strings include information about the elliptic curve group G1, G2, the bilinear mapping e, the hash function h, etc. The proof key used for "generating proof" is issued only to the prover (vehicle). The Verifying Key, used for "verifying proof," is issued to all verifiers (RSU, Vehicle A / B). The Verifying Key transmits the message via a secure channel. Send to RSU;

[0031] Step 2: RSU generates random numbers ,calculate , , , ;

[0032] RSU will send information { Store the message in the blockchain and send it to the blockchain. The information is sent to the TA via a secure channel. At this point, before the vehicle participates in the mission, the RSU can verify the legitimacy of the vehicle by querying the stored vehicle information and assess its reputation score.

[0033] Step 3: After receiving the message, the TA generates a random number. ,calculate , , , .storage{ And update the RSU information to the blockchain.

[0034] The vehicle registration phase specifically includes:

[0035] Step 1: During the login and authentication phase, the onboard unit obtains the timestamp message. Users first enter their identity information. ,password And verify biological characteristics Vehicle A retrieves information based on the information stored in the device. And use a blur extractor to restore Then use PUF to calculate the response. And check the restored result , Is it equal to the stored value? , and through ≟ Calculate and store values The comparison is used for verification; if the verification passes, the device calculates... , Vehicle A will Send to TA via a public channel;

[0036] Step 2: After receiving the message, the TA first checks the validity of the timestamp, and then relies on the pseudo-identity of vehicle A. Index and retrieve stored information and calculate , Then verify ≟ If the verification is successful, the TA confirms the legitimacy of vehicle A's identity; at this point, the TA proceeds based on the vehicle's root identifier. Read its current reputation value from the blockchain. and last update timestamp And based on the reputation threshold set by the system. The login access determination process is executed. For vehicles with a reputation score below the threshold, the TA allows them to complete the login process but marks them as restricted for service level control in subsequent communication phases. After successful verification, the calculation is performed. , , And store { };

[0037] Step 3: TA will send the message The message is sent back to the vehicle-mounted equipment. After receiving the message, the vehicle-mounted equipment checks the validity of the timestamp again and calculates... ≟ Verify the integrity of the sent message and the reliability of the TA. Successful verification results in successful login. Calculate... , And store { Meanwhile, the normal or restricted login status of vehicle A will be saved as an attribute marker and used for selecting service priority and connection strategy during subsequent communication and key negotiation phases; after successful login, vehicle A will proactively broadcast its pseudo-identity information. It is assumed that all vehicles that meet can receive each other's updated pseudo-identity information, and that TA can also successfully receive the pseudo-identity information broadcast by the vehicle.

[0038] The identity authentication and pseudo-identity update stages are specifically as follows:

[0039] Step 1: In the identity authentication and pseudo-identity update stage, firstly, vehicle A obtains a timestamp. And generate random numbers ,calculate , , , , Then vehicle A will Send to RSU via public channel;

[0040] Step 2: The RSU receives communication request information M1 from vehicle A. Since vehicle A sent a broadcast message to the RSU, vehicle B, and TA after successful login, it broadcasts its own... If vehicle A's broadcast message is up-to-date. Then through Verify the timestamp; if the timestamps match, verify. ≟ Verify the identity of vehicle A. Once verification is successful, calculate... , The RSU calculates this information based on the false identity information broadcast by vehicles A and B. Determine if it is the latest If the vehicle broadcast is the previous one If this occurs, the vehicle may be at risk of desynchronization attacks. In this case, the RSU should use the previous method. Resend the login phase message M2 to the vehicle, assuming the RSU receives a message from vehicle A containing the previous login information. If so, vehicle A will be considered offline and notified to log in again. If it is the latest version... Then calculate , , and will Send to TA;

[0041] Step 3: After the TA receives the message, it retrieves... And verify the validity of the timestamp and the verification message. The integrity, when satisfy ≟ At that time, calculate , ,verify ≟ If the verification passes, then based on the false identity information broadcast by vehicle B, the updated PID and corresponding key are searched on the blockchain. , and obtain ,examine ;

[0042] If the verification passes, the TA confirms the legitimacy of vehicle A's identity. At this point, the TA proceeds based on the vehicle's root identifier. Read its current reputation value from the blockchain. and last update timestamp And based on the reputation threshold set by the system. The TA determines whether to allow pseudo-identity updates. For vehicles with a reputation value below a threshold, the TA does not reject their authentication results but delays or restricts their pseudo-identity update operations and marks them as restricted for service control in subsequent communication phases. It is worth noting that the TA maintains a pseudo-identity update queue. Define the scheduling priority function. ,in When multiple vehicles are simultaneously restricted, it does not mean that vehicle authentication or communication requests are rejected. Rather, it refers to imposing update frequency and scheduling priority constraints on low-reputation vehicles in scenarios with limited system resource contention, such as pseudo-identity updates. This priority function is only used for scheduling within the pseudo-identity update queue and does not affect the authentication result or subsequent key exchange stage. After successful verification, the TA updates the vehicle's PID to the blockchain. If verification fails, the PID needs to be restored to its original value, and vehicle A needs to be notified to log in again. The RSU is also notified to restore the PID to its original value. After successful verification, the calculation... , , , Finally, TA will Send to vehicle A;

[0043] Step 4: After receiving the message, vehicle A first obtains... And verify the validity and calculation of the timestamp. , ,examine ≟ If the verification passes, the update is successful. .

[0044] It is worth noting that TA will use the previous one Copying the old one to the blockchain In the field, the new one obtained based on the calculation Update the existing blockchain From this point on, TA can accept the updated version. And the last time Regardless of receiving the update It's still the same as last time. They can find all the relevant information about the vehicle, but they received the previous one. At this time, an error count will be performed for the corresponding vehicle. When the error count is greater than 3, an alarm will be sent to the upper-level administrator. At this time, it may be that the network has failed or that it has been subjected to a desynchronization attack by an attacker.

[0045] The key exchange phase specifically includes:

[0046] Step 1: During the key exchange phase, vehicle A obtains the timestamp message. Generate random numbers Equipment calculation , , Vehicle A will Send to vehicle B via a public channel;

[0047] Step 2: After receiving the message, vehicle B first checks the validity of the timestamp, and then verifies... ≟ After successful verification, a common session key is calculated. After this phase, both vehicles A and B successfully established connections, ensuring secure communication for subsequent sessions.

[0048] The beneficial effects of the present invention.

[0049] This invention combines blockchain, PUF, and zero-knowledge proof to achieve decentralized identity authentication and key exchange, effectively preventing identity forgery, replay attacks, man-in-the-middle attacks, and side-channel attacks.

[0050] Zero-knowledge proofs protect vehicle privacy during the authentication process, ensuring that vehicles do not need to disclose sensitive information during authentication and preventing information association and tracking.

[0051] A dynamic reputation management mechanism is introduced to adjust the reputation value in real time based on the vehicle's historical behavior and task performance, and to prioritize the allocation of communication resources to high-reputation vehicles, thereby reducing the consumption of system resources by low-reputation vehicles.

[0052] The lightweight key exchange protocol and ECC encryption significantly reduce computational and communication overhead, making the solution suitable for highly dynamic and high-density vehicle-to-everything (V2X) environments.

[0053] Blockchain smart contracts store vehicle registration information and reputation scores, enabling decentralized management and eliminating single points of failure.

[0054] The system can dynamically update vehicle information and reputation values, support rapid authentication and task scheduling across RSUs, and enhance network robustness and scalability.

[0055] This invention designs a real-time identity authentication and reputation assessment mechanism for highly dynamic and high-density network environments, enabling vehicles to quickly establish secure sessions even with frequent network switching and high-speed movement.

[0056] The dynamic reputation mechanism combines time decay and forgetting factors to enable reputation values ​​to reflect recent vehicle behavior in a timely manner, thereby improving the system's adaptability and reliability in dynamic environments.

[0057] The protocol is designed to ensure mutual authentication, data integrity verification, anonymity protection, and scalability at every step.

[0058] Through formal security verification (using the Scyther tool) and informal analysis, this invention can comprehensively resist complex attacks, and its security is superior to existing technologies.

[0059] In summary, this invention not only solves the problems of insufficient security, privacy protection, and communication efficiency in the existing technology in the high-dynamic, high-density vehicle network environment, but also has significant advantages in scalability, system robustness, and real-time performance, and can provide a reliable guarantee for the efficient and safe operation of the vehicle network. Attached Figure Description

[0060] Figure 1 This is a timeline diagram of the vehicle registration phase.

[0061] Figure 2 This is a sequence diagram for the RSU registration and data synchronization phases.

[0062] Figure 3 This is a sequence diagram for the vehicle login phase.

[0063] Figure 4 This is a sequence diagram for the identity authentication and pseudo-identity update stages.

[0064] Figure 5 This is a timing diagram for the key exchange phase. Detailed Implementation

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

[0066] A decentralized authentication and key exchange method based on blockchain includes the following steps;

[0067] It includes six main phases: initialization phase, registration phase, RSU registration and data synchronization phase, vehicle login phase, identity authentication and pseudo-identity update phase, and key exchange phase.

[0068] Initialization phase: Given a safety parameter λ, TA generates an elliptic curve over the finite field Fz. , where z is a prime power. Then, in A subgroup G is chosen from the additive group, with generator P, where q is a prime order of P. The car manufacturer configures associated secret parameters and records them in the blockchain. A blockchain smart contract is used to store vehicle and RSU registration information, including public and private keys, identity identifiers, and reputation scores. TA selects a secure hash function. Create your own public / private key pair , , and select and For two prime-order subgroups on the curve, Define a bilinear mapping for the target group: Satisfy any , and ,have The TA pre-sets the range of reputation values ​​in the smart contract. Initial reputation value Historical decay factor Historical weight in reputation updates Reputation threshold Time unit .

[0069] Registration phase:

[0070] Before the OBU is actually deployed, it must be registered with the TA. Below is... Figure 2 The vehicle registration process is described below.

[0071] Step 1: The user first selects their identity. Key And enter the password Biological characteristics ,calculate , Users send messages through secure channels Send it to them.

[0072] Step 2: TA Inspection The system verifies the legitimacy of the identity and checks its uniqueness in its database. If the uniqueness is not satisfied, the user is required to select a different identity. Legal and unique, TA chooses Generate random numbers ,challenge The TA runs the Groth16 Setup algorithm to generate common parameters and proof / verification keys for the vehicle. Initialize reputation status as ,in This represents the vehicle's current credit score. The last valid timestamp for reputation updates. This is a malicious behavior counter, initialized to... TA assigns an initial reputation value to the vehicle. value range And calculate the root identifier of the reputation mechanism. , , , , , , , and TA stores information { } to the blockchain and send the message The data is transmitted to the onboard unit of vehicle A via a secure channel.

[0073] Step 3: After the user device receives the message, vehicle A generates the challenge. According to user input Generate relevant biometric parameters And generate a response to the challenge via PUF. Simultaneously, the device uses a fuzz extractor to process the noise in the PUF response and generate... and calculate , .equipment storage{ }, assuming that Tamper-resistant data stored in vehicle A In, and will Stored in the TPM of vehicle A.

[0074] RSU registration and data synchronization phase:

[0075] Before actual deployment, RSUs must also register with the TA and synchronize some vehicle information. In this solution, the RSU only maintains a vehicle reputation cache table related to its coverage area. Each record contains only lightweight fields such as identity information, reputation value, and corresponding block height. If the information broadcast by a vehicle is not stored in the RSU, the vehicle is allowed to perform low-priority basic AKE communication. At the same time, the RSU asynchronously synchronizes the vehicle's reputation information from the blockchain or neighboring RSUs in the background and dynamically adjusts its communication permissions and priorities after synchronization is complete. Below is... Figure 3The description of the RSU registration and data synchronization phase process is shown below.

[0076] Step 1: The TA first selects their identity identifier. key And generate The TA runs the Groth16 Setup algorithm to generate common parameters and proof / verification keys for the RSU. and calculate , ,in The public reference strings include information about the elliptic curve group G1, G2, the bilinear mapping e, the hash function h, etc. The proof key used for "generating proof" is issued only to the prover (vehicle). The Verifying Key, used for "verifying proof," is issued to all verifiers (RSU, Vehicle A / B). The Verifying Key transmits the message via a secure channel. Send to RSU.

[0077] Step 2: RSU generates random numbers ,calculate , , , RSU will send information { Store the message in the blockchain and send it to the blockchain. The information is sent to the TA via a secure channel. At this point, before the vehicle participates in the mission, the RSU can verify the vehicle's legitimacy and assess its reputation score by querying the stored vehicle information.

[0078] Step 3: After receiving the message, the TA generates a random number. ,calculate , , , .storage{ And update the RSU information to the blockchain.

[0079] Vehicle registration phase:

[0080] Step 1: During the login and authentication phase, the onboard unit obtains the timestamp message. Users first enter their identity information. ,password And verify biological characteristics Vehicle A retrieves information based on the information stored in the device. And use a blur extractor to restore Then use PUF to calculate the response. And check the restored result , Is it equal to the stored value? , and through ≟ Calculate and store values The comparison is used for verification. If the verification passes, the device calculates... , Vehicle A will Send to TA via a public channel.

[0081] Step 2: After receiving the message, the TA first checks the validity of the timestamp, and then relies on the pseudo-identity of vehicle A. Index and retrieve stored information and calculate , Then verify ≟ If the verification is successful, the TA confirms the legitimacy of vehicle A's identity. At this point, the TA proceeds based on the vehicle's root identifier. Read its current reputation value from the blockchain. and last update timestamp And based on the reputation threshold set by the system. The login access determination process is executed. For vehicles with a reputation score below the threshold, the TA allows them to complete the login process but marks them as restricted for service level control in subsequent communication phases. Upon successful verification, the calculation... , , And store { }

[0082] Step 3: TA will send the message The message is sent back to the vehicle-mounted equipment. After receiving the message, the vehicle-mounted equipment checks the validity of the timestamp again and calculates... ≟ Verify the integrity of the sent message and the reliability of the TA. Successful verification results in successful login. Calculate... , And store { Meanwhile, vehicle A's normal or restricted login status will be saved as an attribute marker and used in subsequent communication and key negotiation phases to select service priority and connection strategies. After successful login, vehicle A will proactively broadcast its pseudo-identity information. It is assumed that all vehicles that meet can receive each other's updated pseudo-identity information, and that TA can also successfully receive the pseudo-identity information broadcast by the vehicle.

[0083] Identity authentication and pseudo-identity update phase:

[0084] Step 1: In the identity authentication and pseudo-identity update stage, firstly, vehicle A obtains a timestamp. And generate random numbers ,calculate , , , , Then vehicle A will Sent to RSU via a public channel.

[0085] Step 2: The RSU receives communication request information M1 from vehicle A. Since vehicle A sent a broadcast message to the RSU, vehicle B, and TA after successful login, it broadcasts its own... If vehicle A's broadcast message is up-to-date... Then through Verify the timestamp; if the timestamps match, verify. ≟ Verify the identity of vehicle A. Once verification is successful, calculate... , The RSU calculates this information based on the false identity information broadcast by vehicles A and B. Determine if it is the latest If the vehicle broadcast is the previous one If this occurs, the vehicle may be at risk of desynchronization attacks. In this case, the RSU should use the previous method. Resend the login phase message M2 to the vehicle, assuming the RSU receives a message from vehicle A containing the previous login information. If so, vehicle A will be considered offline and notified to log in again. If it is the latest version... Then calculate , , and will Send it to them.

[0086] Step 3: After the TA receives the message, it retrieves... And verify the validity of the timestamp and the verification message. The integrity, when satisfy ≟ At that time, calculate , ,verify ≟ If the verification passes, then based on the false identity information broadcast by vehicle B, the updated PID and corresponding key are searched on the blockchain. , and obtain ,examine .

[0087] If the verification passes, the TA confirms the legitimacy of vehicle A's identity. At this point, the TA proceeds based on the vehicle's root identifier. Read its current reputation value from the blockchain. and last update timestamp And based on the reputation threshold set by the system. The TA determines whether to allow pseudo-identity updates. For vehicles with a reputation value below a threshold, the TA does not reject their authentication results but delays or restricts their pseudo-identity update operations and marks them as restricted for service control in subsequent communication phases. It is worth noting that the TA maintains a pseudo-identity update queue. Define the scheduling priority function. ,in When multiple vehicles are simultaneously restricted, it does not mean that vehicle authentication or communication requests are rejected. Rather, it refers to imposing update frequency and scheduling priority constraints on low-reputation vehicles in scenarios with limited system resource contention, such as pseudo-identity updates. This priority function is only used for scheduling within the pseudo-identity update queue and does not affect the authentication result or subsequent key exchange stage. After successful verification, the TA updates the vehicle's PID to the blockchain. If verification fails, the PID needs to be restored to its original value, and vehicle A needs to be notified to log in again. The RSU is also notified to restore the PID to its original value. After successful verification, the calculation... , , , Finally, TA will Send to vehicle A.

[0088] Step 4: After receiving the message, vehicle A first obtains... And verify the validity and calculation of the timestamp. , ,examine ≟ If the verification passes, the update is successful. .

[0089] It is worth noting that TA will use the previous one Copying the old one to the blockchain In the field, the new one obtained based on the calculation Update the existing blockchain From this point on, TA can accept the updated version. And the last time Regardless of receiving the update It's still the same as last time. They can find all the relevant information about the vehicle, but they received the previous one. At this time, an error count will be performed for the corresponding vehicle. When the error count is greater than 3, an alarm will be sent to the upper-level administrator. At this time, it may be that the network has failed or that it has been subjected to a desynchronization attack by an attacker.

[0090] Key exchange phase:

[0091] Step 1: During the key exchange phase, vehicle A obtains the timestamp message. Generate random numbers Equipment calculation , , Vehicle A will Send it to vehicle B via a public channel.

[0092] Step 2: After receiving the message, vehicle B first checks the validity of the timestamp, and then verifies... ≟ After successful verification, a common session key is calculated. After this phase, both vehicles A and B successfully established connections, ensuring secure communication for subsequent sessions.

[0093] In addition to PUF technology, hardware security modules (HSM) or trusted platform modules (TPM) can be used in combination with biometric recognition for identity authentication.

[0094] These hardware security components can generate unique identifiers and keys, thus preventing identity forgery and cloning attacks.

[0095] The difference lies in the fact that the security and cost may be slightly lower than the PUF scheme, but it can still meet the purpose of decentralized authentication and secure key exchange.

[0096] In addition to Groth16 zero-knowledge proofs, other zero-knowledge proof protocols (such as Bulletproofs, zk-SNARKs, etc.) or hybrid anonymity technologies can be used to achieve vehicle authentication and privacy protection.

[0097] These methods can complete identity verification without disclosing sensitive information, thus protecting user privacy.

[0098] Depending on the limitations of actual computing power and communication resources, different zero-knowledge proof schemes can be selected as alternatives.

[0099] Dynamic reputation management can be achieved through other trust assessment algorithms, such as blockchain-based distributed scoring systems, Bayesian trust models, or machine learning methods for predicting reputation values.

[0100] By evaluating vehicle history and task completion in real time, task priority scheduling and communication resource allocation can be achieved, thereby optimizing communication efficiency.

[0101] In addition to ECC lightweight key exchange, secure key negotiation can be accomplished using schemes such as elliptic curve Diffie-Hellman (ECDH), cryptographic symmetric key derivation, or lightweight signature aggregation algorithms.

[0102] Although the implementation methods differ, they can still ensure communication security in highly dynamic vehicle-to-everything (V2X) environments while meeting the requirements for low computation and low latency.

[0103] In addition to consortium blockchains, public or private blockchain architectures can be used to achieve decentralized authentication and information management.

[0104] By managing vehicle identity and reputation values ​​through smart contracts, single points of failure can still be eliminated, data integrity can be guaranteed, and system scalability and robustness can be supported.

[0105]

[0106] like Figure 1 The diagram illustrates the registration process between a vehicle and a trusted institution. The vehicle first selects an identity identifier, password, and biometrics, calculates relevant parameters, and sends a registration request to the TA via a secure channel. After verifying the identity, the TA runs the Groth16 algorithm to generate zero-knowledge proof parameters, calculates the vehicle's root identifier, pseudo-identity, and authentication materials, and stores the registration information on the blockchain. Finally, it returns the necessary key parameters to the vehicle via a secure channel. Upon receiving the data, the vehicle uses a PUF (Proof-of-Factory Function) and a fuzz extractor to process the biometrics and PUF response, generating and storing the final key materials to complete the registration.

[0107] like Figure 2 The diagram illustrates the registration and data synchronization process between a trusted authority (TA) and a roadside unit (RSU). The TA selects the RSU's identity and key, runs Groth16 to generate zero-knowledge proof parameters for the RSU, and sends a registration request to the RSU via a secure channel. Upon receiving the request, the RSU generates a random number, uses a PUF (Proof-of-Factory Function) to generate a response, calculates its own pseudo-identity and authentication parameters, stores the registration information in the blockchain, and returns a response. After verification, the TA generates session key materials and updates the blockchain record. After registration, the RSU only caches reputation information for vehicles within its coverage area; uncached vehicles are allowed low-priority communication, and reputation data is asynchronously synchronized in the background.

[0108] like Figure 3The diagram illustrates the login authentication process between a vehicle and a trusted institution. The vehicle obtains a timestamp, inputs its identity, password, and biometrics, recovers the key material using a fuzz extractor and PUF (Programmatic Authentication Function), verifies the consistency of its local storage, calculates the login credentials, and sends a login request to the TA (Trustee) via a public channel. The TA verifies the timestamp validity and message integrity, recovers the PUF response, verifies the vehicle's identity, and makes an admission determination based on the reputation value in the blockchain (low-reputation vehicles are marked as restricted). It then generates a session credential and returns it to the vehicle. The vehicle verifies the timestamp and message integrity again, updates its local storage upon successful login, and broadcasts pseudo-identity information.

[0109] like Figure 4 The diagram illustrates the two-way authentication and pseudo-identity update process between vehicles, roadside units (Roadside Units), and trusted institutions. The vehicle obtains a timestamp and generates a random number, calculates authentication parameters, and sends an authentication request to the Roadside Unit (RSU). The RSU verifies the validity of the timestamp and the vehicle's pseudo-identity. If the pseudo-identity is up-to-date, it forwards the message to the TA (Trusted Agent); otherwise, it resends the login message using the old pseudo-identity or requires the vehicle to log in again. The TA verifies the timestamp, message integrity, and vehicle identity, and determines whether to allow the pseudo-identity update based on the reputation value in the blockchain (low-reputation vehicles have delayed updates). It updates the vehicle's pseudo-identity to the blockchain and returns a response. After verifying the response, the vehicle completes the pseudo-identity update. The TA also retains the old pseudo-identity for future reference and performs error counting for the use of the old pseudo-identity.

[0110] like Figure 5 The diagram illustrates the process of establishing a session key between vehicle A and vehicle B. Vehicle A obtains a timestamp and generates a random number. Using the pseudo-identities and key materials of both parties, it calculates the session key and related authentication parameters, and sends a key exchange request to vehicle B through a public channel. Vehicle B verifies the validity of the timestamp and the integrity of the authentication parameters. If the verification passes, it calculates the same session key as vehicle A, completing the establishment of a secure session. Subsequent communications are encrypted using this key.

[0111] This invention effectively resists various attacks such as man-in-the-middle attacks, replay attacks, and identity forgery by introducing the decentralized authentication mechanism, physically unclonable functions, and zero-knowledge proofs of blockchain, significantly improving the security of identity authentication. Formal security verification ensures the reliability of identity verification and data integrity, effectively guaranteeing the security of vehicle-to-everything (V2X) communication.

[0112] This invention achieves anonymity and untraceability in vehicle communication through a dynamic pseudo-identity update mechanism, combined with random number generation and hash calculation, preventing malicious tracking and privacy leaks. The pseudo-identity used in each communication is dynamically generated, effectively improving vehicle privacy protection and demonstrating strong adaptability in highly dynamic vehicle-to-everything (V2X) environments.

[0113] The lightweight key exchange protocol designed in this invention simplifies the authentication and key negotiation process, optimizes the computation and communication process, significantly reduces the computational burden and communication overhead of the system, and greatly reduces the amount of communication data, effectively supporting the real-time and low-latency requirements of vehicle networking.

[0114] The authentication scheme of this invention is flexible, supporting multiple communication modes such as V2V and V2I, and adapting to dynamic topology changes in the vehicle network environment. Its distributed architecture makes the protocol compatible with various hardware devices, has strong scalability, and can provide stable and reliable authentication and secure communication in different vehicle network scenarios.

[0115] This invention, through its tamper-resistant hardware design and distributed key management mechanism, effectively prevents internal attacks and device tampering risks, ensuring the integrity of the vehicle-to-everything (V2X) system. PUF technology ensures the uniqueness of each device, while the fuzz extractor effectively improves the system's fault tolerance, further enhancing its security.

[0116] This invention uses homomorphic hash functions to encrypt and verify the integrity of communication data, ensuring that the data is tamper-resistant and that the identity is genuine during transmission. Experimental results show that the message integrity verification success rate based on homomorphic hash functions reaches 100%, providing a strong guarantee for the confidentiality of data transmitted in the Internet of Vehicles.

[0117] This invention ensures the uniqueness of each session key by dynamically generating a session key, combining authentication information and a random number, thereby achieving forward and backward security. Even if an attacker obtains a long-term key, it cannot affect the security of subsequent sessions. Real or Random (ROR) model verification results show that the probability of an attacker obtaining the key using known session information is extremely low, effectively guaranteeing the security of the session key.

[0118] To verify the security and feasibility of the protocol described in this invention, this section conducts verification from three dimensions: formal security experiments, computational and communication overhead analysis, and functional simulation experiments. Specifically, the Scyther tool is used to automate the verification of security attributes; the computational and communication overhead is derived theoretically; and the protocol interaction process is tested using a Python simulation platform, verifying that the protocol can execute normally and meets the design objectives.

[0119] To verify the feasibility and stability of the proposed protocol in actual communication processes, this study built a prototype system based on Python to simulate message interaction between vehicles A / B, RSU, and TA. In the experiment, vehicles A / B logged in, authenticated, and negotiated session keys with the RSU and TA through the onboard unit, fully covering the key operations in the protocol design.

[0120] In terms of functionality, the simulation system completed the following tasks: First, it implemented vehicle login and identity verification functions, verifying the legitimacy of the vehicle's identity through PUF response and user biometrics; second, it completed the two-way identity authentication steps specified in the protocol, using a zero-knowledge proof mechanism to ensure the legitimacy of both parties' identities and privacy protection; third, the system simulated a dynamic pseudo-identity update process to verify the correctness of anonymity protection and key update mechanisms; finally, it completed the negotiation of session keys through ECC point multiplication operations, achieving secure communication.

[0121] Experimental results show that the entire protocol process can be executed smoothly in the simulation environment. There are no errors or anomalies in the generation, transmission, and verification of messages at each stage. The protocol logic is complete, and the functions are implemented correctly. Based on this simulation verification, it can be confirmed that the proposed protocol has good feasibility in engineering implementation, the process is stable, and it can meet the secure communication requirements of resource-constrained vehicular network environments. Detailed description of the attached figures

[0122] like Figure 1 As shown, the vehicle registration process includes the following steps:

[0123] Vehicle A sends a registration request message to TA via a secure channel. This message includes the user's selected identity, password, biometric information, and their hash value. Upon receiving the request, TA first verifies the legitimacy and uniqueness of the identity. If the verification passes, TA selects system parameters, generates a random number and a challenge value, runs the Groth16 Setup algorithm to generate public parameters for a zero-knowledge proof and a proof / verification key for the vehicle, and initializes the vehicle's state. TA assigns an initial reputation value to the vehicle, calculates the root identifier and related parameters, and stores the vehicle registration information in the blockchain. Subsequently, TA returns a message containing the challenge value, key materials, and fuzz extractor parameters to Vehicle A via a secure channel. Upon receiving the message, Vehicle A generates a challenge, uses the user's biometrics to generate parameters, generates a response using the PUF (Proof-of-Factory) algorithm, uses the fuzz extractor to process noise in the PUF response, and calculates and stores the relevant key materials in the vehicle's onboard equipment.

[0124] like Figure 2 As shown, the RSU registration and data synchronization phase includes the following steps:

[0125] The TA first selects the RSU's identity and key, runs the Groth16 Setup algorithm to generate public parameters for zero-knowledge proofs and proof / verification keys for the RSU, calculates relevant authentication parameters, and then sends the registration message to the RSU via a secure channel. Upon receiving the message, the RSU generates a random number, calculates its own authentication parameters, stores the RSU registration information in the blockchain, and simultaneously returns a response message to the TA via a secure channel. Upon receiving this response, the TA generates a random number, further calculates, and updates the RSU's relevant information to the blockchain. After registration, the RSU only maintains a vehicle reputation cache table related to its coverage area. If a vehicle's information is not cached in the RSU, the RSU allows it to perform low-priority basic AKE communication, while asynchronously synchronizing the vehicle's reputation information from the blockchain or neighboring RSUs in the background, and dynamically adjusting its communication permissions and priorities after synchronization.

[0126] like Figure 3 As shown, the vehicle registration phase includes the following steps:

[0127] Vehicle A obtains the current timestamp. The user enters their identity identifier, password, and biometric verification. Vehicle A extracts and reconstructs the PUF response based on the device's stored information and verifies if the stored hash value matches. If verification passes, Vehicle A calculates the relevant authentication parameters and sends the login request message to TA via a public channel. Upon receiving the message, TA first checks the timestamp's validity, extracts the stored information using Vehicle A's pseudo-identity index, and verifies message integrity. If verification is successful, TA reads the current reputation value and last updated timestamp from the blockchain based on the vehicle's root identifier and performs login access determination according to the reputation threshold. Vehicles with reputation values ​​below the threshold are marked as restricted, but are still allowed to log in. TA then calculates and stores the new session parameters and sends a login success message back to Vehicle A. Upon receiving this message, Vehicle A verifies the timestamp and message integrity again. If verification is successful, login is complete, and the updated parameters are stored. After successful login, Vehicle A actively broadcasts its pseudo-identity information so that other vehicles and TA can receive it.

[0128] like Figure 4 As shown, the identity authentication and pseudo-identity update stage includes the following steps:

[0129] Vehicle A obtains a timestamp and generates a random number. After calculating the relevant authentication parameters, it sends an identity authentication request message M1 to the RSU via a public channel. Upon receiving the message, the RSU verifies the timestamp and the pseudo-identity of Vehicle A. If the pseudo-identity is up-to-date, the RSU continues to calculate and forwards the message to the TA. The RSU then resends the login phase message to the vehicle using the previous pseudo-identity, or notifies the vehicle to log in again. Upon receiving the message, the TA verifies the timestamp, message integrity, and vehicle identity. If the verification passes, the TA reads the current reputation value and timestamp from the blockchain based on the vehicle's root identifier and decides whether to allow the pseudo-identity update based on the reputation threshold. Vehicles with reputation values ​​below the threshold are delayed or restricted from updating their operations, but identity authentication is not rejected. The TA maintains a pseudo-identity update queue and defines a scheduling priority function for internal sorting. After successful verification, the TA updates the vehicle's new pseudo-identity to the blockchain and calculates the relevant response message to return to Vehicle A. Upon receiving the message, Vehicle A verifies the timestamp and message integrity. If the verification passes, the pseudo-identity is successfully updated. The system will copy the previous fake identity into the old field of the blockchain so that it can still be queried when the old fake identity is received. At the same time, it will count errors and issue an alarm when the error count exceeds 3.

[0130] like Figure 5 As shown, the key exchange phase includes the following steps:

[0131] Vehicle A obtains the current timestamp, generates a random number, and calculates the session key material and related authentication parameters based on ECC multiplication. It then sends a key exchange request message to Vehicle B via a public channel. Upon receiving the message, Vehicle B first checks the validity of the timestamp and then verifies whether the authentication parameters in the message match. If the verification is successful, Vehicle B calculates the same shared session key as Vehicle A. At this point, Vehicle A and Vehicle B have successfully established a secure session key for subsequent encrypted communication.

Claims

1. A decentralized authentication and key exchange method based on blockchain, characterized in that, Includes the following steps; It includes the initialization phase, registration phase, RSU registration and data synchronization phase, vehicle login phase, identity authentication and pseudo-identity update phase, and key exchange phase; The initialization phase is used by the trusted authority (TA) to generate system security parameters before system deployment, including elliptic curves, subgroups, generators, and bilinear mappings, and to assign initial public-private key pairs, hash functions, and initial reputation values ​​to vehicles and RSUs. The registration phase is used for vehicles to submit their identity, password and biometric information to the TA through the on-board unit (OBU). The TA verifies the legitimacy of the identity and generates the vehicle's public and private keys, challenge-response pair (CRP) and fuzz extractor parameters. At the same time, it initializes the vehicle's reputation status and stores the relevant information in the blockchain and the on-board module. The RSU registration and data synchronization phase is used for the roadside unit (RSU) to register with the TA before deployment and synchronize vehicle reputation information within the coverage area; the RSU stores lightweight vehicle information for rapid identity verification and evaluates vehicle reputation values ​​in subsequent communications, dynamically adjusting communication priorities and access permissions. The vehicle login phase is used for registered vehicles to establish a legitimate session with the TA through the login process; the vehicle verifies its own identity, password and biometrics, uses PUF to generate a challenge response for identity confirmation, the TA verifies the legitimacy and performs an access determination based on the vehicle's reputation. The identity authentication is used for two-way identity authentication between the vehicle and the RSU and TA. It ensures the legitimacy of the identities of both parties by verifying the PUF response, root identifier, pseudo-identity PID and zero-knowledge proof ZKP, and detects desynchronization attacks or identity forgery. The pseudo-identity update phase and key exchange phase are used to update the vehicle's pseudo-identity PID to ensure anonymity after identity authentication is completed, and to negotiate a session key with the communication partner; the key exchange phase uses key materials generated by ECC multiplication and PUF to establish a secure session, ensuring that both parties can achieve secure data transmission in a highly dynamic network environment, while preventing key leakage and impersonation attacks.

2. The decentralized authentication and key exchange method based on blockchain according to claim 1, characterized in that, The initialization phase specifically includes: Given a security parameter λ, TA generates an elliptic curve over the finite field Fz. Where z is a prime power; then, in Choose a subgroup G from the additive group, whose generator is P, where q is the prime order of P; the car manufacturer configures the associated secret parameters and records the secret parameters in the blockchain. The blockchain smart contract is used to store the vehicle and RSU registration information, including public and private keys, identity identifiers and reputation scores. TA chooses a safe hash function Create your own public / private key pair , , and select and For two prime-order subgroups on the curve, Define a bilinear mapping for the target group: Satisfy any , and ,have ; The TA pre-sets the range of reputation values ​​in the smart contract. Initial reputation value Historical decay factor Historical weight in reputation updates Reputation threshold Time unit .

3. The decentralized authentication and key exchange method based on blockchain according to claim 1, characterized in that, The registration phase specifically includes: Before the OBU is actually deployed, it must be registered with the TA. Step 1: Users first select their identity identifier. Key And enter the password Biological characteristics ,calculate , Users send messages through secure channels Send to TA; Step 2: TA Inspection The system verifies the legitimacy of the identity and checks its uniqueness in its database. If the uniqueness is not satisfied, the user is required to select a different identity. Legal and unique, TA chooses Generate random numbers ,challenge The TA runs the Groth16 Setup algorithm to generate common parameters and proof / verification keys for the vehicle. Initialize reputation status as ,in This represents the vehicle's current credit score. The last valid timestamp for reputation updates. This is a malicious behavior counter, initialized to... TA assigns an initial reputation value to the vehicle. value range And calculate the root identifier of the reputation mechanism. , , , , , , , and TA stores information { } to the blockchain and send the message The data is transmitted to the onboard unit of vehicle A via a secure channel. Step 3: After the user device receives the message, vehicle A generates the challenge. According to user input Generate relevant biometric parameters And generate a response to the challenge via PUF. . Simultaneously, the device uses a fuzz extractor to process the noise in the PUF response and generate... and calculate , .equipment storage{ }, assuming that Tamper-resistant data stored in vehicle A In, and will Stored in the TPM of vehicle A.

4. The decentralized authentication and key exchange method based on blockchain according to claim 1, characterized in that, The RSU registration and data synchronization phase specifically includes: Step 1: The TA first selects their identity identifier. key And generate The TA runs the Groth16 Setup algorithm to generate common parameters and proof / verification keys for the RSU. and calculate , ,in The public reference strings include information about the elliptic curve group G1, G2, the bilinear mapping e, the hash function h, etc. The proof key used for "generating proof" is only issued to the prover. The verification key used for "verification proof" is issued to all verifiers (RSU, Vehicle A / B). The TA transmits the message via a secure channel. Send to RSU; Step 2: RSU generates random numbers ,calculate , , , ; RSU will send information { Store the message in the blockchain and send it to the blockchain. The information is sent to the TA via a secure channel. At this point, before the vehicle participates in the mission, the RSU can verify the legitimacy of the vehicle by querying the stored vehicle information and assess its reputation score. Step 3: After receiving the message, the TA generates a random number. ,calculate , , , .storage{ And update the RSU information to the blockchain.

5. The decentralized authentication and key exchange method based on blockchain according to claim 1, characterized in that, The vehicle registration phase specifically includes: Step 1: During the login and authentication phase, the onboard unit obtains the timestamp message. Users first enter their identity information. ,password And verify biometrics Vehicle A retrieves information based on the information stored in the device. And use a blur extractor to restore Then use PUF to calculate the response. And check the restored result , Is it equal to the stored value? , and through ≟ Calculate and store values The comparison is used for verification; if the verification passes, the device calculates... , Vehicle A will Send to TA via a public channel; Step 2: After receiving the message, the TA first checks the validity of the timestamp, and then relies on the pseudo-identity of vehicle A. Index and retrieve stored information and calculate , Then verify ≟ ; If the verification is successful, TA confirms the legitimacy of vehicle A's identity; at this point, TA proceeds based on the vehicle's root identifier. Read its current reputation value from the blockchain. and last update timestamp And based on the reputation threshold set by the system. The login access determination process is executed. For vehicles with a reputation score below the threshold, the TA allows them to complete the login process but marks them as restricted for service level control in subsequent communication phases. After successful verification, the calculation is performed. , , And store { }; Step 3: TA will send the message The message is sent back to the vehicle-mounted equipment. After receiving the message, the vehicle-mounted equipment checks the validity of the timestamp again and calculates... ≟ Verify the integrity of the sent message and the reliability of the TA. Successful verification results in successful login. Calculate... , And store { Meanwhile, the normal or restricted login status of vehicle A will be saved as an attribute marker and used for selecting service priority and connection strategy during subsequent communication and key negotiation phases; after successful login, vehicle A will proactively broadcast its pseudo-identity information. It is assumed that all vehicles that meet can receive each other's updated pseudo-identity information, and that TA can also successfully receive the pseudo-identity information broadcast by the vehicle.

6. The decentralized authentication and key exchange method based on blockchain according to claim 1, characterized in that, The identity authentication and pseudo-identity update stages are specifically as follows: Step 1: In the identity authentication and pseudo-identity update stage, firstly, vehicle A obtains a timestamp. and generate random numbers. ,calculate , , , , Then vehicle A will Send to RSU via public channel; Step 2: The RSU receives communication request information M1 from vehicle A. Since vehicle A sent a broadcast message to the RSU, vehicle B, and TA after successful login, it broadcasts its own... If vehicle A's broadcast message is up-to-date. Then through Verify the timestamp; if the timestamps match, verify. ≟ Verify the identity of vehicle A. Once verification is successful, calculate... , The RSU calculates this information based on the false identity information broadcast by vehicles A and B. Determine if it is the latest If the vehicle broadcast is the previous one If this occurs, the vehicle may be at risk of desynchronization attacks. In this case, the RSU should use the previous method. Resend the login phase message M2 to the vehicle, assuming the RSU receives a message from vehicle A containing the previous login information. If so, vehicle A will be considered offline and notified to log in again. If it is the latest version... Then calculate , , and will Send to TA; Step 3: After TA receives the message, it retrieves... And verify the validity of the timestamp and the verification message. The integrity, when satisfy ≟ At that time, calculate , ,verify ≟ If the verification passes, then based on the false identity information broadcast by vehicle B, the updated PID and corresponding key are searched on the blockchain. , and obtain ,examine ; If the verification passes, the TA confirms the legitimacy of vehicle A's identity. At this point, the TA proceeds based on the vehicle's root identifier. Read its current reputation value from the blockchain. and last update timestamp And based on the reputation threshold set by the system. The system determines whether to allow pseudo-identity updates. For vehicles with a reputation value below the threshold, the system does not reject their identity authentication results, but delays or restricts their pseudo-identity update operations and marks them as restricted for service control in subsequent communication phases. TA maintains a pseudo-identity update queue Define the scheduling priority function. ,in When multiple vehicles are simultaneously restricted, it does not mean that the vehicle's identity authentication or communication request is rejected. After successful verification, the TA updates the vehicle's PID to the blockchain. If verification fails, the PID needs to be restored to its original value, and vehicle A needs to be notified to log in again. The RSU is also notified to restore the PID to its original value. Upon successful verification, the calculation... , , , Finally, TA will Send to vehicle A; Step 4: After receiving the message, vehicle A first obtains... And verify the validity and calculation of the timestamp. , ,examine ≟ If the verification passes, the update is successful. ; TA will return the last one Copying the old one to the blockchain In the field, the new one obtained based on the calculation Update the existing blockchain .

7. The decentralized authentication and key exchange method based on blockchain according to claim 1, characterized in that, The key exchange phase specifically includes: Step 1: During the key exchange phase, vehicle A obtains the timestamp message. Generate random numbers Equipment calculation , , Vehicle A will Send to vehicle B via a public channel; Step 2: After receiving the message, vehicle B first checks the validity of the timestamp, and then verifies... ≟ After successful verification, a common session key is calculated. After this phase, both vehicles A and B successfully established connections, ensuring secure communication for subsequent sessions.

Images