Revocable Internet of Vehicles authentication method based on alliance chain

Abstract

The invention discloses a revocable Internet of Vehicles authentication method based on an alliance chain. The method comprises the following steps: initializing a system to establish a trust basis; the vehicle and road side unit registers to a trusted mechanism, the pseudo identity and PUF information are subjected to uplink storage, and an intelligent contract is deployed; after the vehicle initiates authentication, the road side unit verifies information from the chain and generates a new pseudo identity and a PUF challenge value; the vehicle generates a PUF response based on the challenge and calculates a session key, and the road side unit calls an on-chain contract to verify the response, completes bidirectional authentication and updates an on-chain identity state; and if the malicious vehicle is detected, the road side unit submits the chain revocation transaction, and the whole network refuses the authentication after consensus synchronization. According to the invention, a lightweight password technology, a physical unclonable function, an alliance block chain distributed account book and a dynamic identity management mechanism are integrated to construct an Internet of Vehicles authentication scheme considering high efficiency, safety, reliability and privacy protection, and effective support is provided for safe and reliable operation of an intelligent traffic system.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of Internet of Vehicles authentication, and particularly relates to a revocable Internet of Vehicles authentication method based on a consortium chain. BACKGROUND

[0002] With the rapid development of intelligent transportation systems (ITS), the Internet of Vehicles, as its core supporting technology, is widely used in real-time traffic push, automatic driving coordination, vehicle sharing services and other diversified scenarios. In this scenario, vehicles interact with infrastructure units (RSUs) deployed on the roadside through communication modes such as vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) to achieve efficient and safe traffic management and services. In this process, reliable identity authentication is the primary prerequisite for ensuring the legitimacy of communication entities, the authenticity of information, and the security of interaction.

[0003] However, existing Internet of Vehicles authentication schemes still have significant defects in dealing with the challenges of high mobility, open wireless channels, resource constraints, and physical security threats specific to the Internet of Vehicles:

[0004] First, traditional centralized authentication schemes generally rely on a single trusted authority (TA) for network-wide key management and identity verification. This architecture has a single point of failure risk. Once the central server is attacked or fails, the entire authentication system will be paralyzed. At the same time, vehicle identity information and authentication parameters are usually stored in the local database of RSU, which is vulnerable to tampering or theft. Attackers can use fake legitimate identities to launch false information injection attacks, posing a serious threat to road safety.

[0005] Second, to improve security, some schemes use strong authentication mechanisms based on public key cryptography systems (such as elliptic curve cryptography ECC). However, the large number of complex operations involved (such as point multiplication operations) place a heavy burden on the limited computing resources of vehicle terminals, making it difficult to meet the strict requirements of authentication real-time and low latency in high-speed mobile and dense access scenarios, affecting service experience and system efficiency.

[0006] Third, to address the problem of vehicles being vulnerable to physical capture, key extraction, and other hardware attacks, some schemes introduce physical unclonable functions (PUF) to enhance terminal security using their unclonable characteristics. However, most of these schemes still store the PUF challenge-response pair in a centralized server, failing to fundamentally address the tampering and single-point failure risks inherent in centralized storage.

[0007] In addition, other researchers have attempted to use the decentralized and tamper-proof nature of blockchain technology to build a distributed authentication system. However, such solutions typically use consensus mechanisms (such as proof of work) that have high transaction confirmation delays, making it difficult to meet the real-time authentication requirements of vehicle networking with millisecond-level responses. Moreover, most existing solutions fail to balance the computational efficiency, communication overhead, and overall security strength of the authentication process during design, making it difficult to achieve efficient and reliable deployment in resource-constrained and dynamically changing vehicle networking environments.

[0008] In summary, existing technical solutions often cannot meet the comprehensive needs of lightweight computing, high-strength security, decentralized and reliable storage, and real-time and efficient authentication in the specific application scenario of vehicle networking. Therefore, there is an urgent need to propose a new authentication method to ensure the security, reliability, and efficiency of vehicle networking communication. SUMMARY

[0009] To solve the above technical problems, the present application provides a revocable vehicle networking authentication method based on a consortium chain, comprising the following steps:

[0010] Based on the pre-generated security parameters of the vehicle networking system, a system trust foundation is established;

[0011] Based on the system trust foundation, entity registration is performed, and keys and pseudo-identity information for authentication are generated and stored, while the hash value of the pseudo-identity information and the physical unclonable function information are uploaded to the consortium blockchain, and the corresponding smart contract is deployed;

[0012] Based on the registered pseudo-identity information, an authentication request is generated and sent;

[0013] Based on the received authentication request, the registration information of the corresponding entity is retrieved and verified from the consortium blockchain, and after verification, new pseudo-identity information is generated, and a physical unclonable function challenge value is selected based on the smart contract and sent;

[0014] Based on the received challenge value, a response value is generated using the physical unclonable function, and a session key is calculated based on the response value;

[0015] Based on the smart contract, the correctness of the response value is verified to complete two-way authentication, and the updated pseudo-identity state information is uploaded to the consortium blockchain;

[0016] When malicious behavior is detected, a revocation transaction is generated and submitted based on the pseudo-identity state information recorded on the consortium blockchain;

[0017] Based on the blockchain consensus mechanism, the revocation state reached by the revocation transaction is synchronized across the network, preventing subsequent authentication of the corresponding entity.

[0018] Optionally, a system trust foundation is established based on pre-generated vehicle-to-everything (V2X) system security parameters, including:

[0019] Generate the vehicle network system's identity identifier and secret key, and set the elliptic curve parameters and one-way hash function;

[0020] Based on the vehicle network system's identity identifier and secret key, a shared key for use by entities within the network is calculated;

[0021] The system publishes public parameters including the vehicle-to-everything (V2X) system identifier, elliptic curve parameters, and one-way hash function.

[0022] Optionally, based on the system's trust foundation, entity registration is performed, and keys and pseudo-identity information for authentication are generated and stored, including:

[0023] Assign a unique identifier to the infrastructure entity and generate a first random number, and securely transmit the identifier, the first random number and the corresponding shared key;

[0024] Receive the real identity identifier and a set of physically unclonable function challenge-response pairs sent by the mobile entity;

[0025] After verifying the uniqueness of the identity, a second random number and a third random number are generated;

[0026] Based on the real identity identifier, secret key, second random number and shared key, the registration authentication code, first pseudo identity identifier and second pseudo identity identifier of the mobile entity are calculated.

[0027] Optionally, the hash value and physical unclonable function information of the pseudo-identity information are uploaded to the consortium blockchain, and a corresponding verification smart contract is deployed, including:

[0028] The hash value of the first pseudo-identity identifier, the second pseudo-identity identifier, and the second random number, as well as the second random number and its signature data, are uploaded to the consortium blockchain.

[0029] Deploy smart contracts on a consortium blockchain that are associated with mobile entities and include physically unclonable function reference information;

[0030] The first pseudo-identity, the second random number, the second pseudo-identity, and an associated parameter are sent to the mobile entity storage via a secure channel.

[0031] Optionally, based on the received authentication request, the registration information of the corresponding entity is retrieved and verified from the consortium blockchain. Upon successful verification, new pseudo-identity information is generated, including:

[0032] Receive an authentication request including a first timestamp, encryption parameters, and a first verification message;

[0033] Verify the validity of the first timestamp and calculate the second pseudo-identity identifier of the entity that sent the request;

[0034] Based on the calculated second pseudo-identity identifier, the corresponding registration record is retrieved from the consortium blockchain;

[0035] Based on the retrieved records and information from the request, restore the associated parameters stored locally;

[0036] The correctness of the first verification message is verified using the recovered associated parameters.

[0037] Optionally, sending a physically unclonable function challenge value based on the smart contract includes:

[0038] After successful verification, the corresponding smart contract deployed on the consortium blockchain is retrieved using the recovered associated parameters;

[0039] Select a challenge value for a physically unclonable function from the smart contract;

[0040] Generate a fourth random number, a fifth random number, and a second timestamp;

[0041] Calculate the new first pseudo-identity and the new second pseudo-identity based on the current first pseudo-identity of the requesting entity, the fourth random number, and the shared key;

[0042] Based on the identity identifier of the infrastructure entity, the current identity information of the entity sending the request, and the second timestamp, the new first pseudo-identity identifier and the new second pseudo-identity identifier are encrypted to obtain the first encryption parameter;

[0043] Based on the second timestamp, the new first pseudo-identity identifier, and the new second pseudo-identity identifier, the fifth random number and the challenge value are encrypted to obtain the second encryption parameter;

[0044] The calculation includes a new first pseudo-identity identifier, a new second pseudo-identity identifier, a challenge value, a fifth random number, and a second verification message with a second timestamp.

[0045] Send a response message that includes a first encryption parameter, a second encryption parameter, a second verification message, and a second timestamp.

[0046] Optionally, based on the received challenge value, a response value is generated using a physically non-cloning function, and a session key is calculated based on the response value, including:

[0047] Receive the response message from the infrastructure entity and decrypt it to obtain the new first pseudo-identity, the new second pseudo-identity, the fifth random number, and the challenge value;

[0048] Verify the second verification message in the response message;

[0049] Once verification is successful, update the locally stored identity information;

[0050] Generate a third timestamp and generate a response value using a physically unclonable function based on the challenge value;

[0051] The encrypted response, session key, and third verification message are calculated based on the response value, the old and new identity parameters, and the third timestamp.

[0052] Optionally, verifying the correctness of the response value based on the smart contract to complete two-way authentication, and uploading the updated pseudo-identity status information to the consortium blockchain, includes:

[0053] Receive a response message from the mobile entity, which includes a third verification message and a third timestamp;

[0054] Verify the validity of the third timestamp and decrypt to obtain the response value generated by the moving entity;

[0055] Invoke the smart contract to retrieve the corresponding reference response value based on the challenge value;

[0056] The validity of the response value is verified by comparing the hash value of the response value generated by the mobile entity with the hash value of the reference response value.

[0057] After successful verification, the session key is calculated based on the same parameters and verified against the third verification message;

[0058] The updated data, including the new pseudo-identity hash of the mobile entity, is signed and uploaded to the consortium blockchain.

[0059] The present invention also provides a revocable vehicle network authentication system based on a consortium blockchain for implementing the method, comprising: a trusted institution, at least one roadside unit, at least one vehicle, and a consortium blockchain network;

[0060] The trusted mechanism is used to generate security parameters for the vehicle network system, perform registration for roadside units and vehicles, and generate pseudo-identities and long-term keys for vehicles.

[0061] The consortium blockchain network consists of multiple authorized roadside units as nodes, used for decentralized storage of vehicle registration information, pseudo-identity status and revocation list, and deployment and execution of smart contracts for verification logic;

[0062] The vehicle is equipped with a physically unclonable function (PUF) for initiating authentication requests to the roadside unit and generating a PUF response and session key based on the challenge issued by the roadside unit.

[0063] The roadside unit is connected to the trusted institution, the vehicle, and the consortium blockchain network to verify the vehicle's identity, call the smart contract to complete two-way authentication, update the vehicle status on the blockchain after authentication, and initiate a transaction reversal when a malicious vehicle is detected.

[0064] Optionally, the vehicle and the trusted institution transmit registration information via a secure channel; the vehicle and the roadside unit transmit authentication and negotiation messages via a public wireless channel.

[0065] The revocable vehicle network authentication method based on consortium blockchain provided by this invention effectively solves the comprehensive security and efficiency problems existing in the prior art, such as single point of failure, heavy computational burden, easy storage tampering, easy privacy leakage, and difficulty in revoking malicious nodes, through a series of synergistic technical means, and achieves significant technical results, specifically reflected in:

[0066] First, by using hash functions and XOR operations to replace complex public-key cryptographic operations, lightweight computation on the vehicle side is achieved during the authentication process. This technique significantly reduces the computational overhead and energy consumption of resource-constrained in-vehicle terminals, making the authentication process fast and efficient. This meets the stringent requirements for real-time performance and low latency in high-speed mobile scenarios of the Internet of Vehicles, ensuring a superior service experience.

[0067] Second, by employing consortium blockchain technology to distribute and store the core authentication information of vehicles and deploy verification logic, a decentralized and tamper-proof trust infrastructure is constructed. This technology fundamentally avoids the single point of failure and tampering risks of centralized servers or a single RSU database. Even if some roadside unit nodes are compromised, the system can still restore a trusted state based on the blockchain ledger, thereby greatly enhancing the overall security, reliability, and fault tolerance of the entire authentication system.

[0068] Third, a dynamic identity management mechanism is established by generating and synchronously updating a pseudo-identity for the vehicle on the blockchain after each successful authentication. This technology enables vehicles to use different temporary identities for conversations at different times and locations, effectively severing the connection between communication data and the vehicle's real identity and long-term driving trajectory. This effectively protects the privacy of both the vehicle and the user, achieving anonymity and untraceability of communication.

[0069] Fourth, by designing and implementing a transaction reversal mechanism initiated by roadside units based on blockchain, and utilizing consensus algorithms to achieve rapid network-wide synchronization of reversal status, an efficient and consistent malicious node isolation capability is formed. This technical approach ensures that any vehicle judged to be malicious will be immediately and collaboratively denied service by all legitimate roadside units, thereby effectively curbing the spread of internal attacks and maintaining the long-term security and stable operation of the vehicle-to-everything (V2X) system.

[0070] In summary, this invention organically integrates lightweight cryptography, the hardware characteristics of physically unclonable functions, consortium blockchain distributed ledger, and dynamic identity management mechanism to construct a vehicle network authentication scheme that balances efficiency, security, reliability, and privacy protection, providing effective support for the safe and reliable operation of intelligent transportation systems. Attached Figure Description

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

[0072] Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention;

[0073] Figure 2 This is a schematic diagram of the system structure according to an embodiment of the present invention. Detailed Implementation

[0074] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0075] 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, and 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.

[0076] Example 1

[0077] like Figure 1 As shown, this embodiment provides a revocable vehicle network authentication method based on a consortium blockchain, including the following steps:

[0078] Establish a system trust foundation based on pre-generated vehicle-to-everything (V2X) system security parameters;

[0079] Based on the system's trust foundation, entity registration is performed, keys and pseudo-identity information for authentication are generated and stored, and the hash value and physical unclonable function information of the pseudo-identity information are uploaded to the consortium blockchain and the corresponding smart contract is deployed.

[0080] Generate and send an authentication request based on the registered pseudo-identity information;

[0081] Based on the received authentication request, the registration information of the corresponding entity is retrieved and verified from the consortium blockchain. After successful verification, new pseudo identity information is generated and sent based on the physical unclonable function challenge value selected by the smart contract.

[0082] Based on the received challenge value, a response value is generated using a physically unclonable function, and the session key is calculated based on the response value.

[0083] The smart contract verifies the correctness of the response value to complete two-way authentication, and the updated pseudo-identity status information is uploaded to the consortium blockchain.

[0084] When malicious behavior is detected, a reversal transaction is generated and submitted based on the pseudo-identity status information recorded on the consortium blockchain;

[0085] Based on the blockchain consensus mechanism, the revocation status reached by the revocation transaction is synchronized across the entire network to prevent subsequent authentication by the corresponding entity.

[0086] Implementable methods for establishing a system trust foundation based on pre-generated vehicle-to-everything (V2X) system security parameters include:

[0087] Generate the vehicle network system identity identifier and secret key, and set the elliptic curve parameters and one-way hash function; calculate the shared key for use by entities within the network based on the vehicle network system identity identifier and secret key; publish the public parameters including the vehicle network system identity identifier, elliptic curve parameters and one-way hash function.

[0088] Implementable, based on the system's trust foundation, entity registration is performed, and keys and pseudo-identity information for authentication are generated and stored, including:

[0089] Assign a unique identity to the infrastructure entity and generate a first random number, and securely transmit the identity, the first random number and the corresponding shared key; receive the real identity sent by the mobile entity and a set of physically unclonable function challenge response pairs; after verifying the uniqueness of the identity, generate a second random number and a third random number; calculate the mobile entity's registration authentication code, first pseudo identity, and second pseudo identity based on the real identity, secret key, second random number and shared key.

[0090] Implementably, the hash value and physical unclonable function information of the pseudo-identity information are uploaded to the consortium blockchain, and the corresponding verification smart contract is deployed, including:

[0091] The hash value of the first pseudo-identity identifier, the second pseudo-identity identifier, and the second random number, as well as the second random number and its signature data, are uploaded to the consortium blockchain; a smart contract associated with the mobile entity, including physically unclonable function reference information, is deployed on the consortium blockchain; and the first pseudo-identity identifier, the second random number, the second pseudo-identity identifier, and an associated parameter are sent to the mobile entity storage via a secure channel.

[0092] Implementable, based on the received authentication request, retrieving and verifying the registration information of the corresponding entity from the consortium blockchain, and generating new pseudo-identity information upon successful verification, including:

[0093] Receive an authentication request including a first timestamp, encrypted parameters, and a first verification message; verify the validity of the first timestamp and calculate a second pseudo-identity identifier of the entity sending the request; based on the calculated second pseudo-identity identifier, retrieve and obtain the corresponding registration record from the consortium blockchain; restore the locally stored association parameters according to the retrieved record and the information in the request; and use the restored association parameters to verify the correctness of the first verification message.

[0094] Implementable methods include selecting and sending a physically unclonable function challenge value based on the smart contract, including:

[0095] After successful verification, the corresponding smart contract deployed on the consortium blockchain is retrieved using the recovered association parameters; a challenge value for a physically unclonable function is selected from the smart contract; a fourth random number, a fifth random number, and a second timestamp are generated; a new first pseudo-identity and a new second pseudo-identity are calculated based on the current first pseudo-identity of the requesting entity, the fourth random number, and the shared key; the new first pseudo-identity and the new second pseudo-identity are encrypted based on the identity of the infrastructure entity, the current identity information of the requesting entity, and the second timestamp to obtain a first encryption parameter; the fifth random number and the challenge value are encrypted based on the second timestamp, the new first pseudo-identity, and the new second pseudo-identity to obtain a second encryption parameter; a second verification message including the new first pseudo-identity, the new second pseudo-identity, the challenge value, the fifth random number, and the second timestamp is calculated; and a response message including the first encryption parameter, the second encryption parameter, the second verification message, and the second timestamp is sent.

[0096] The feasible method involves generating a response value based on the received challenge value using a physically non-cloning function, and calculating a session key based on that response value, including:

[0097] Receive a response message from an infrastructure entity and decrypt it to obtain a new first pseudo-identity, a new second pseudo-identity, a fifth random number, and a challenge value; verify the second verification message in the response message; after successful verification, update the locally stored identity information; generate a third timestamp and generate a response value using a physically unclonable function based on the challenge value; calculate an encrypted response, a session key, and a third verification message based on the response value, the new and old identity parameters, and the third timestamp.

[0098] Implementable steps include verifying the correctness of the response value based on the smart contract to complete two-way authentication, and uploading the updated pseudo-identity status information to the consortium blockchain, including:

[0099] The system receives a response message from a mobile entity, including a third verification message and a third timestamp; verifies the validity of the third timestamp and decrypts it to obtain the response value generated by the mobile entity; invokes a smart contract to retrieve the corresponding reference response value based on the challenge value; verifies the legality of the response value by comparing the hash value of the response value generated by the mobile entity with the hash value of the reference response value; after successful verification, calculates a session key based on the same parameters and verifies the third verification message; and uploads the updated data, including the hash value of the mobile entity's new pseudo-identity, to the consortium blockchain after signing it.

[0100] On the other hand, this embodiment also provides a revocable vehicle network authentication system based on a consortium blockchain for implementing the method, including: a trusted institution, at least one roadside unit, at least one vehicle, and a consortium blockchain network;

[0101] The trusted mechanism is used to generate security parameters for the vehicle network system, perform registration for roadside units and vehicles, and generate pseudo-identities and long-term keys for vehicles.

[0102] The consortium blockchain network consists of multiple authorized roadside units as nodes, used for decentralized storage of vehicle registration information, pseudo-identity status and revocation list, and deployment and execution of smart contracts for verification logic;

[0103] The vehicle is equipped with a physically unclonable function (PUF) for initiating authentication requests to the roadside unit and generating a PUF response and session key based on the challenge issued by the roadside unit.

[0104] The roadside unit is connected to the trusted institution, the vehicle, and the consortium blockchain network to verify the vehicle's identity, call the smart contract to complete two-way authentication, update the vehicle status on the blockchain after authentication, and initiate a transaction reversal when a malicious vehicle is detected.

[0105] Furthermore, the vehicle and the trusted institution transmit registration information via a secure channel; the vehicle and the roadside unit transmit authentication and negotiation messages via a public wireless channel.

[0106] The beneficial effects achieved by this embodiment are as follows:

[0107] This embodiment does not require public-key cryptography operations on the vehicle side, but only uses lightweight operations such as hash functions and XOR operations, which significantly reduces the computational burden on vehicle nodes. It can meet the stringent requirements of vehicle networking for real-time performance and low latency, and is particularly suitable for deployment in resource-constrained vehicle environments.

[0108] This embodiment employs consortium blockchain technology to store vehicle hash pseudo-identities and physically unclonable function challenge response pairs. Leveraging the distributed ledger and immutability of blockchain, it effectively prevents malicious modification of the roadside unit database. Even if a single roadside unit is compromised or its database is damaged, the system can recover correct authentication data from the blockchain, significantly improving the overall security, reliability, and fault tolerance of the system, and avoiding the single point of failure risk of traditional centralized storage models.

[0109] This embodiment employs a dynamic pseudo-identity update mechanism. After each authentication, the roadside unit generates and updates a new pseudo-identity for the vehicle, and the status is synchronously updated across the entire network via blockchain. Vehicles use different pseudo-identities in different authentication sessions, ensuring that attackers cannot associate authentication requests from different times and locations with the same vehicle by analyzing intercepted communication messages. This effectively protects user privacy and vehicle trajectory, achieving anonymity and untraceability.

[0110] This embodiment provides a robust vehicle revocation mechanism. When a roadside unit detects malicious behavior, illegal operation, or safety hazards in a vehicle, it can upload a revocation transaction via the blockchain, marking the vehicle's false identity as invalid and deactivating its related smart contracts. After the revocation information is agreed upon among roadside units using a practical Byzantine fault-tolerant consensus algorithm, all roadside units across the network synchronously update the revocation status. A revoked vehicle will no longer be able to pass authentication requests from any roadside unit in the network, effectively isolating malicious nodes and maintaining the safe and stable operation of the entire vehicle-to-everything (V2X) system.

[0111] Example 2

[0112] This embodiment provides a revocable vehicle-to-everything (V2X) authentication method based on a consortium blockchain. During system initialization, a Trusted Authority (TA) is responsible for establishing the basic operating environment of the entire V2X authentication system, generating the system master key and related security parameters, and selecting a secure hash function for subsequent identity spoofing, authentication, and key generation processes. During entity registration, the TA assigns unique identifiers to Roadside Units (RSUs) and vehicles and generates corresponding authentication parameters. Vehicles generate challenge-response pairs using a Physically Unclonable Function (PUF). The TA uploads the vehicle's hash pseudo-identity and PUF-related information to the blockchain and deploys a smart contract. During the authentication and key negotiation phase… The vehicle sends an authentication request to the RSU. The RSU retrieves the vehicle's registration information from the blockchain and verifies its legitimacy. After successful verification, the RSU generates a new pseudo-identity for the vehicle and sends it to the vehicle via a PUF challenge value selected through a smart contract. The vehicle uses the PUF to generate a response and calculates a session key. The RSU verifies the correctness of the PUF response through a smart contract and completes two-way authentication. Finally, the RSU uploads the updated pseudo-identity status of the vehicle to the blockchain. During the vehicle revocation phase, if malicious behavior is detected, the RSU uploads the revocation transaction to the blockchain, invalidating the vehicle's pseudo-identity and smart contract. Other RSUs will then update synchronously and reject subsequent authentication requests from that vehicle.

[0113] In practical applications, this embodiment helps to enhance the reliability of vehicle authentication and the privacy of vehicle identity in the Internet of Vehicles (IoV), thereby achieving more efficient, secure, and faster IoV authentication.

[0114] like Figure 2 As shown, this embodiment involves the following four types of entities:

[0115] Trusted Authority (TA): The Trusted Authority is the root of trust and management core of the entire vehicle-to-everything (V2X) authentication system, and is considered a completely trusted entity within the system. The Trusted Authority is responsible for the initialization of the entire authentication system, entity registration management, and the establishment of trust relationships, providing a unified trust foundation for all network entities.

[0116] Blockchain: Consortium blockchain is the decentralized storage and trust management infrastructure adopted in this invention. Unlike fully public blockchains, consortium blockchains are semi-open blockchain networks, where only authorized nodes (roadside units in this invention) can join the network, participate in consensus, and maintain the ledger. Consortium blockchains combine the efficiency of centralized systems with the security of decentralized systems, making them suitable for applications like the Internet of Vehicles (IoV) that require high efficiency, reliability, and control.

[0117] Vehicle: A vehicle node is a mobile entity equipped with an onboard communication unit and physically non-cloning function hardware. It serves as both a service requester and an authentication participant in the vehicle-to-everything (V2X) authentication system. Vehicle nodes are highly mobile and require frequent authentication switching with roadside units in different areas during operation.

[0118] Roadside Units (RSUs): Roadside units are fixed infrastructure nodes deployed on both sides of roads or at specific locations, possessing strong computing, storage, and communication capabilities. In the vehicle-to-everything (V2X) authentication system, roadside units play a dual role as both authentication service providers and blockchain network nodes, serving as a bridge connecting vehicles and the blockchain.

[0119] The revocable vehicle network authentication method based on consortium blockchain described in this embodiment includes the following steps:

[0120] S1. System Initialization. TA generates the system master key and related security parameters, and selects a secure one-time hash function. It is used for subsequent identity spoofing, authentication, and key generation processes. Simultaneously, TA establishes a unified trust foundation for the registration, authentication, and revocation mechanisms of Roadside Units (RSUs) and vehicle nodes, providing security support for subsequent decentralized authentication and identity management.

[0121] S2. Entity Registration. The entity registration phase includes RSU registration and vehicle registration. The TA assigns a unique identifier to each RSU and generates a random number, which is sent to the RSU storage via a secure channel. During vehicle registration, the vehicle generates a real identity, collects a PUF challenge-response pair, and sends a registration request to the TA. After verification, the TA generates a random number, a pseudo-identity, and a long-term authentication key. The relevant hash information and PUF parameters are written to the blockchain, and the key parameters are returned to the vehicle for storage via a secure channel.

[0122] S3, Authentication and Key Negotiation Phase. The vehicle performs two-way authentication with the nearest RSU. A timestamp is generated for the vehicle. The RSU sends an authentication request, verifies the information, and retrieves the vehicle registration information from the blockchain. Once authentication is successful, the RSU generates a new pseudo-identity and selects a PUF challenge value. Vehicle verification A third timestamp is then generated. The response value is calculated by PUF. This generates a session key and sends it to the RSU. The RSU then calculates... And by comparing h( ) and h( Complete the authentication.

[0123] S4. Revocation Phase. When a vehicle is determined to be malicious or illegal, the RSU writes its revocation information to the blockchain and reaches consensus. After the vehicle's identity status is synchronized and updated in the blockchain, other RSUs can promptly learn of the vehicle's revocation status and reject its subsequent authentication requests. Because the revocation information is immutable and synchronized across the entire network, the revoked vehicle will be unable to authenticate and communicate with any RSU again, thus effectively preventing it from posing a continuous security threat to the system.

[0124] Furthermore, the specific steps of S1 are as follows:

[0125] S1-1: TA generates an identity and the network's secret key And set a step as Elliptic curve and a one-way hash function Then, TA chose generator and calculate This value is used as a shared key among the RSUs in the network. TA publishes... and store .

[0126] Furthermore, the specific steps of S2 are as follows:

[0127] S2-1: For registering roadside units TA assigns it a unique identifier. And generate a first random number. Subsequently, TA transmitted via a secure channel Send to After receiving the above information, Calculate its public key And It is securely stored in a local database.

[0128] S2-2 vehicles Generate your own identity identifier And generate a set of PUF challenge-response pairs Subsequently, the vehicle Will Send to a trusted authority (TA). The TA first verifies the identity. Has the user already registered? If not, TA will generate a second random number. and the third random number And calculate the registration authentication code, first pseudo-identity identifier, and second pseudo-identity identifier of the mobile entity, which correspond to: Then, TA will Uploaded to the blockchain, generating a record containing information about the mobile entity. The smart contract contains the relevant Physically Unclonable Function (PUF) information. Finally, TA transmits the information via a secure channel. Send to vehicle The vehicle will Stored in local memory.

[0129] Furthermore, the specific steps of S3 are as follows:

[0130] S3-1: When the vehicle When deployed in a specific area, it should first be integrated with nearby roadside units. Certification is performed. During this phase, the vehicle... Generate first timestamp And calculate encryption parameters And the authentication request of the first verification message

[0131] S3-2: Subsequently, Verify first timestamp The validity of the second pseudo-identity is determined, and the second pseudo-identity is calculated. Simultaneously, retrieve and obtain the corresponding registration records from the blockchain. Next, Calculate the associated parameters of local storage And check the correctness of the first verification message, that is Subsequently, Using the recovered correlation parameters Retrieve the corresponding smart contract and select a challenge value for a physically unclonable function. And generate new fourth and fifth random numbers, corresponding to... , and the second timestamp .then, The new first pseudo-identity identifier, the new second pseudo-identity identifier, the first encryption parameter, the second encryption parameter, and the second verification message are calculated as follows: as well as

[0132] S3-3 then, To vehicles via public channels Send message vehicle After receiving the message, calculate And calculate the second verification message Subsequently, the vehicle inspection confirmed the second verification message. If the verification is successful, the vehicle In local storage Updated to Next, the vehicle generates a third timestamp. And based on the challenge value Generate PUF response value Subsequently, the vehicle calculates the encrypted response, session key, and third-party verification message, which correspond to:

[0133] S3-4 then, vehicles Towards Send message After receiving the message, First, verify the third timestamp. The validity of the data is determined, and the response value generated by the moving entity is calculated. Subsequently, Call the smart contract deployed in the blockchain to check the challenge value With response value The validity of the smart contract is verified, with the smart contract first being evaluated based on the challenge value. Retrieve the corresponding reference PUF response If no corresponding record is found, the verification is deemed a failure and the authentication process is terminated; otherwise, the smart contract calculates separately. and The system compares the two responses; if they are equal, the PUF response returned by the vehicle is considered valid; otherwise, the verification fails. If the above verification passes, Further calculate the session key And check the third verification message. If all the above checks are true, then Successfully certified vehicle .at last, Delete the temporary response in this session and update the data of the new pseudo-identity hash of the moving entity. Uploaded to the blockchain to complete the secure update of vehicle identity and PUF status.

[0134] Furthermore, the specific steps of S4 are as follows:

[0135] S4-1: When a vehicle If identified as engaging in malicious behavior, it will be prohibited from communicating with other entities on the network. Once a vehicle is detected... Abnormal or malicious behavior, roadside unit A reversal transaction will be uploaded to the blockchain to revoke the false identity associated with the vehicle. and will be based on The deployed smart contract was marked as invalid. Subsequently, other... The system will unanimously consider the vehicle's false identity to have been revoked, thus rejecting any subsequent authentication requests. Since its identity status has been synchronized and updated across the entire blockchain, the revoked vehicle... It will no longer be able to communicate with any network. Authentication and communication completed successfully.

[0136] The key terms and constraints of this embodiment are as follows:

[0137] Lightweight cryptographic techniques: This embodiment uses only lightweight cryptographic operations such as hash functions and XOR operations on the vehicle side. A hash function is a one-way function that can quickly map data of arbitrary length to a fixed-length digest, and it is collision-resistant and irreversible. XOR operation is one of the simplest encryption operations, with extremely fast computation speed, making it suitable for resource-constrained devices. By cleverly combining these lightweight operations, this embodiment significantly reduces the computational burden on the vehicle without sacrificing security.

[0138] Blockchain: This embodiment adopts a consortium blockchain architecture, with a blockchain network composed of authorized roadside unit nodes. The blockchain organizes transaction data into an immutable chain structure through cryptographic hash links, and any modification to historical data will be detected immediately. The blockchain uses a practical Byzantine fault-tolerant consensus algorithm, allowing it to continue operating normally even if some nodes fail or are attacked. Transaction confirmation time reaches the second level, meeting the real-time requirements of vehicle-to-everything (V2X) communication.

[0139] In this embodiment, a trusted institution generates security parameters such as the system master key, elliptic curve parameters, and hash functions, and establishes a trust foundation. Roadside units and vehicles register with the trusted institution, which assigns identity identifiers and keys to the roadside units, generates pseudo-identities and long-term authentication keys for the vehicles, and uploads the vehicle's hash pseudo-identity and physical unclonable function (PUC) information to the blockchain. Simultaneously, a smart contract containing PUC verification logic is deployed. The vehicle sends an authentication request to the roadside unit, which retrieves the vehicle's registration information from the blockchain and verifies its legitimacy. Upon successful verification, a new pseudo-identity is generated for the vehicle, and a PUC challenge value is selected and sent to the vehicle via the smart contract. The vehicle uses the PUC hardware to generate a response value and calculate a session key. The roadside unit calls the smart contract to verify the correctness of the PUC response and complete two-way authentication. Finally, the updated pseudo-identity status of the vehicle is uploaded to the blockchain. When malicious behavior by a vehicle is detected, the roadside unit uploads a transaction reversal to invalidate the vehicle, and other roadside units update synchronously and reject subsequent authentication requests.

[0140] This embodiment employs physically unclonable functions and consortium blockchain technology, combined with lightweight hash functions and XOR operations, to support rapid vehicle authentication and dynamic identity updates, ensuring that vehicle data privacy is not leaked in connected vehicle scenarios. Utilizing the decentralized storage and immutability of blockchain helps enhance the reliability of vehicle authentication, the privacy of vehicle identities, and the system's resistance to attacks, thus achieving more efficient, secure, and faster connected vehicle authentication.

[0141] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A revocable vehicle-to-everything (V2X) authentication method based on a consortium blockchain, characterized in that, Includes the following steps: Establish a system trust foundation based on pre-generated vehicle-to-everything (V2X) system security parameters; Based on the system's trust foundation, entity registration is performed, and keys and pseudo-identity information for authentication are generated and stored. At the same time, the hash value and physical unclonable function information of the pseudo-identity information are uploaded to the consortium blockchain, and the corresponding smart contract is deployed. Generate and send an authentication request based on the registered pseudo-identity information; Based on the received authentication request, the registration information of the corresponding entity is retrieved and verified from the consortium blockchain. After successful verification, new pseudo identity information is generated and sent based on the physical unclonable function challenge value selected by the smart contract. Based on the received challenge value, a response value is generated using a physically unclonable function, and the session key is calculated based on the response value. The smart contract verifies the correctness of the response value to complete two-way authentication, and the updated pseudo-identity status information is uploaded to the consortium blockchain. When malicious behavior is detected, a reversal transaction is generated and submitted based on the pseudo-identity status information recorded on the consortium blockchain; Based on the blockchain consensus mechanism, the revocation status reached by the revocation transaction is synchronized across the entire network to prevent subsequent authentication by the corresponding entity.

2. The method according to claim 1, characterized in that, Establish a system trust foundation based on pre-generated vehicle-to-everything (V2X) system security parameters, including: Generate the vehicle network system's identity identifier and secret key, and set the elliptic curve parameters and one-way hash function; Based on the vehicle network system's identity identifier and secret key, a shared key for use by entities within the network is calculated; The system publishes public parameters including the vehicle-to-everything (V2X) system identifier, elliptic curve parameters, and one-way hash function.

3. The method according to claim 1, characterized in that, Based on the system's trust foundation, entity registration is performed, and keys and pseudo-identity information for authentication are generated and stored, including: Assign a unique identifier to the infrastructure entity and generate a first random number, and securely transmit the identifier, the first random number and the corresponding shared key; Receive the real identity identifier and a set of physically unclonable function challenge-response pairs sent by the mobile entity; After verifying the uniqueness of the identity, a second random number and a third random number are generated; Based on the real identity identifier, secret key, second random number and shared key, the registration authentication code, first pseudo identity identifier and second pseudo identity identifier of the mobile entity are calculated.

4. The method according to claim 3, characterized in that, The hash value and physical unclonable function information of the pseudo-identity information are uploaded to the consortium blockchain, and the corresponding verification smart contract is deployed, including: The hash value of the first pseudo-identity identifier, the second pseudo-identity identifier, and the second random number, as well as the second random number and its signature data, are uploaded to the consortium blockchain. Deploy smart contracts on a consortium blockchain that are associated with mobile entities and include physically unclonable function reference information; The first pseudo-identity, the second random number, the second pseudo-identity, and an associated parameter are sent to the mobile entity storage via a secure channel.

5. The method according to claim 1, characterized in that, Based on the received authentication request, the registration information of the corresponding entity is retrieved and verified from the consortium blockchain. Upon successful verification, new pseudo-identity information is generated, including: Receive an authentication request including a first timestamp, encryption parameters, and a first verification message; Verify the validity of the first timestamp and calculate the second pseudo-identity identifier of the entity that sent the request; Based on the calculated second pseudo-identity identifier, the corresponding registration record is retrieved from the consortium blockchain; Based on the retrieved records and information from the request, restore the associated parameters stored locally; The correctness of the first verification message is verified using the recovered associated parameters.

6. The method according to claim 5, characterized in that, Based on the smart contract, a physically unclonable function challenge value is selected and sent, including: After successful verification, the corresponding smart contract deployed on the consortium blockchain is retrieved using the recovered associated parameters; Select a challenge value for a physically unclonable function from the smart contract; Generate a fourth random number, a fifth random number, and a second timestamp; Calculate the new first pseudo-identity and the new second pseudo-identity based on the current first pseudo-identity of the requesting entity, the fourth random number, and the shared key; Based on the identity identifier of the infrastructure entity, the current identity information of the entity sending the request, and the second timestamp, the new first pseudo-identity identifier and the new second pseudo-identity identifier are encrypted to obtain the first encryption parameter; Based on the second timestamp, the new first pseudo-identity identifier, and the new second pseudo-identity identifier, the fifth random number and the challenge value are encrypted to obtain the second encryption parameter; The calculation includes a new first pseudo-identity identifier, a new second pseudo-identity identifier, a challenge value, a fifth random number, and a second verification message with a second timestamp. Send a response message that includes a first encryption parameter, a second encryption parameter, a second verification message, and a second timestamp.

7. The method according to claim 1, characterized in that, Based on the received challenge value, a response value is generated using a physically non-cloning function, and a session key is calculated based on this response value, including: Receive the response message from the infrastructure entity and decrypt it to obtain the new first pseudo-identity, the new second pseudo-identity, the fifth random number, and the challenge value; Verify the second verification message in the response message; Once verification is successful, update the locally stored identity information; Generate a third timestamp and generate a response value using a physically unclonable function based on the challenge value; The encrypted response, session key, and third verification message are calculated based on the response value, the old and new identity parameters, and the third timestamp.

8. The method according to claim 7, characterized in that, The smart contract verifies the correctness of the response value to complete two-way authentication, and uploads the updated pseudo-identity status information to the consortium blockchain, including: Receive a response message from the mobile entity, which includes a third verification message and a third timestamp; Verify the validity of the third timestamp and decrypt to obtain the response value generated by the moving entity; Invoke the smart contract to retrieve the corresponding reference response value based on the challenge value; The validity of the response value is verified by comparing the hash value of the response value generated by the mobile entity with the hash value of the reference response value. After successful verification, the session key is calculated based on the same parameters and verified against the third verification message; The updated data, including the new pseudo-identity hash of the mobile entity, is signed and uploaded to the consortium blockchain.

9. A revocable vehicle-to-everything (V2X) authentication system based on a consortium blockchain, characterized in that, The method for implementing any one of claims 1-8 comprises: a trusted institution, at least one roadside unit, at least one vehicle, and a consortium blockchain network; The trusted mechanism is used to generate security parameters for the vehicle network system, perform registration for roadside units and vehicles, and generate pseudo-identities and long-term keys for vehicles. The consortium blockchain network consists of multiple authorized roadside units as nodes, used for decentralized storage of vehicle registration information, pseudo-identity status and revocation list, and deployment and execution of smart contracts for verification logic; The vehicle is equipped with a physically unclonable function (PUF) for initiating an authentication request to the roadside unit and generating a PUF response and session key based on the challenge issued by the roadside unit. The roadside unit is connected to the trusted institution, the vehicle, and the consortium blockchain network to verify the vehicle's identity, call the smart contract to complete two-way authentication, update the vehicle status on the blockchain after authentication, and initiate a transaction reversal when a malicious vehicle is detected.

10. The system according to claim 9, characterized in that, The vehicle and the trusted institution transmit registration information through a secure channel; the vehicle and the roadside unit transmit authentication and negotiation messages through a public wireless channel.

Images