Internet of vehicles cross-domain identity authentication method based on PUF (Physical Unclonable Function) and certificateless

Abstract

The invention provides an Internet of Vehicles cross-domain identity authentication method based on PUF and certificateless, and the method comprises the steps: firstly generating a system master key and a master public key through a KGC, and disclosing system parameters; secondly, the vehicle generates a physical response and extracts a stable key, interacts with the KGC to complete generation of a certificateless key pair, and stores registration information to a block chain; then the edge server registers in the KGC, obtains a certificateless key pair, initiates an authentication request to the KGC, and obtains a block chain data reading authority; finally, bidirectional authentication is carried out between the vehicle and the edge server based on the certificateless signature and the PUF response, and a session key is generated; and the cross-domain vehicles are assisted by the edge server to complete mutual identity authentication and session key negotiation. According to the method, the key escrow and certificate management burden is eliminated by adopting a certificateless cryptosystem, the high computing load is released to the edge server in combination with the PUF hardware security characteristic and the block chain distributed trust, the computing and communication overhead is remarkably reduced, and the method is suitable for a large-scale Internet of Vehicles cross-domain authentication scene.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, specifically to a cross-domain identity authentication method for vehicle networking based on PUF and certificate-free authentication. Background Technology

[0002] As a crucial component of intelligent transportation systems, the Vehicle-to-Everything (VANET) network enables functions such as traffic information sharing, collaborative driving, and vehicle-to-infrastructure (V2I) communication through real-time communication between vehicles (V2V) and between vehicles and infrastructure (V2I). With the increasing prevalence of cross-domain vehicle movement, cross-domain authentication has become a critical element in ensuring the security of VANET communication. Cross-domain authentication requires vehicles to quickly and securely complete identity verification and establish trusted communication sessions when moving between different management domains.

[0003] Currently, identity authentication schemes in the Internet of Vehicles (IoV) primarily rely on the traditional Public Key Infrastructure (PKI) system, using digital certificates to achieve identity binding and authentication. However, this solution faces the following problems in practical deployment:

[0004] Certificate management is complex and costly: In scenarios with a large number of vehicles and frequent cross-domain operations, the management processes for certificate issuance, storage, renewal and revocation are complex and increase communication and storage overhead, which is not conducive to adapting to the highly dynamic vehicle environment.

[0005] Key security storage is difficult: Traditional solutions usually store private keys in the software environment or hardware security module of the vehicle unit. Although hardware security modules can improve key protection to some extent, it is still difficult to completely avoid the risk of key leakage when limited by cost or facing advanced physical and side-channel attacks.

[0006] Centralized trust dependency: Most solutions rely on centralized certificate authorities (CAs) or key generation centers (KGCs), which pose single points of failure and trust risks. Furthermore, cross-domain mutual recognition requires the establishment of complex trust chains, making implementation difficult.

[0007] Limited computing resources: As a mobile node with limited resources, the vehicle has limited computing power and cannot handle complex cryptographic operations. Existing security solutions have high computational loads, which leads to increased authentication delays and affects real-time performance.

[0008] To address these issues, some studies have proposed identity-based encryption (IBE) schemes to simplify certificate management. However, IBE schemes still suffer from key escrow problems, where the key generation center holds the user's private key, and an attack on this center could compromise the entire system's security. Furthermore, physically unclonable functions (PUFs), as hardware security primitives, have been introduced to generate device-unique and unclonable keys, but their responses are susceptible to environmental noise, leading to key inconsistencies.

[0009] In cross-domain information sharing and collaborative authentication, existing solutions mostly rely on a central server for information synchronization and verification, which presents problems such as single points of failure, data tampering, and difficulties in trust transfer. In cross-domain authentication scenarios, existing mechanisms still have shortcomings in terms of authentication latency, collaborative efficiency, and trust management.

[0010] In summary, existing cross-domain identity authentication schemes for connected vehicles still face a series of technical challenges in terms of certificate management, key security, centralization risks, resource constraints, and PUF noise tolerance. There is an urgent need for a cross-domain authentication mechanism that can balance security, efficiency, and lightweight design. Summary of the Invention

[0011] The technical problem to be solved:

[0012] Existing cross-domain identity authentication solutions for connected vehicles mainly suffer from the following technical problems: Traditional PKI systems face challenges such as complex certificate management and high communication and storage overhead in scenarios with massive numbers of vehicles and frequent cross-domain interactions. Furthermore, private keys are often stored in software or ordinary hardware modules, making them vulnerable to side-channel attacks or physical theft, posing a risk of identity forgery. Simultaneously, the authentication process relies on a single key generation center or certificate authority, easily creating a single point of failure, resulting in complex cross-domain trust chains and difficulties in mutual recognition. Vehicles, as resource-constrained nodes, have limited computing power in their onboard units, making it difficult to handle complex cryptographic operations, leading to increased authentication latency and failing to meet real-time communication requirements. While some solutions introduce PUF technology to enhance key security, PUF responses are sensitive to environmental noise, and direct use for key generation results in inconsistent outputs and low authentication success rates. In addition, the synchronization of registration information between multiple domains in cross-domain scenarios still relies on a central server, leading to data tampering, single points of failure, and trust transfer obstacles. Therefore, a cross-domain authentication mechanism that balances security, efficiency, and lightweight design is urgently needed.

[0013] Technical solution:

[0014] To address the problems existing in the prior art, this invention proposes a cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on PUF and certificate-free authentication, comprising the following steps:

[0015] Step 1: KGC selects elliptic curve parameters, generates the system master key and master public key, and publishes the system parameters, where KGC is the key generation center;

[0016] Step 2: The vehicle generates a physical response through the embedded PUF, extracts a stable key through a fuzz extractor, interacts with KGC to generate a certificateless key pair, and stores the registration information in the blockchain;

[0017] Step 3: The edge server registers with KGC to obtain a certificateless key pair for subsequent authentication and communication;

[0018] Step 4: The edge server sends an authentication request to KGC and obtains permission to read blockchain data through the batch authentication mechanism;

[0019] Step 5: The vehicle and the edge server perform two-way authentication based on certificateless signing and PUF response, and generate a session key;

[0020] Step 6: Cross-domain vehicles complete mutual identity authentication and session key negotiation with the assistance of the edge server.

[0021] Further preferred solutions, specifically including in step 1:

[0022] Step 1.1: KGC is defined in a finite field. Safety Elliptic Curve And select the base point on the elliptic curve. Its order is a large prime number q;

[0023] Step 1.2: KGC generates random numbers As the system master key, calculate the master public key. ;in, Let represent the multiplicative group consisting of all non-zero elements in the ring of integers modulo q;

[0024] Step 1.3: KGC Secure Storage and publish system parameters to all entities within the system. and KGC's unique identifier ,in It is a collision-resistant hash function.

[0025] Further optimization, step 2 specifically includes:

[0026] Step 2.1: Vehicle Randomly generated challenges The response is obtained by using the embedded PUF calculation. Algorithm generated by fuzz extractor calculate ,in, It is the generated stable key. It is auxiliary data; vehicles Randomly generate secret values Calculate part of the public key , parameters After being assembled with the registration request, it is sent to KGC, where It is a vehicle A unique identifier;

[0027] Step 2.2: KGC generates a partial private key and pseudonym for the vehicle:

[0028] KGC received the vehicle. Verification after registration request Check if it already exists; if not registered, KGC generates a random number. And calculate the temporary public key corresponding to KGC. and for vehicles Calculate kana KGC further provides vehicles Calculate part of the private key , parameters Assemble and store in the blockchain, and finally set the parameters Assembly and delivery to vehicles ;

[0029] Step 2.3: Vehicle After receiving the message returned by KGC, the first step is to calculate:

[0030]

[0031] Verify the validity of a portion of the private key in the message sent by KGC, including... This indicates whether the equation is true or false; if the verification is successful, the vehicle... Set public key Set private key ;vehicle Local secure storage , , and And publish the public key within the system. .

[0032] Further optimization, step 3 specifically includes:

[0033] Step 3.1: Edge server governing domain x Generate random numbers And compute edge servers Generated long-term public key components , parameters The registration request is sent to KGC, where It is an edge server A unique identifier;

[0034] Step 3.2: KGC receives data from the edge server. Verification after registration request Check if it already exists; if not registered, KGC generates a random number. KGC is used for edge servers. Generated long-term public key components and for edge servers Generate a partial private key KGC saves After reaching the local database, it is sent to the edge server. Send parameters ;

[0035] Step 3.3: Edge Server After receiving the message returned by KGC, the first step is to calculate:

[0036]

[0037] Verify part of the private key in the message sent by KGC The validity of the data is verified, and if the verification is successful, the edge server... Set private key Set public key And publish the public key within the system. .

[0038] Further preferred solutions, step 4 specifically includes:

[0039] Step 4.1: Edge Server Generate random numbers and current timestamp Computing edge servers The corresponding temporary public key and hash value ,in It is the unique identifier of KGC. It is the unique identifier of the edge server Elasticsearch. Using your own private key Generate signature and parameters Assemble and send to KGC;

[0040] Step 4.2: KGC receives data from the edge server. After receiving the message, verify the timestamp freshness. Once verification is successful, KGC calculates... ,in For edge servers The identifier recovery value, For edge servers The corresponding temporary public key recovery value; calculated as follows:

[0041]

[0042] Verify signature If the equation holds true, then a single edge server Authentication successful;

[0043] Step 4.3: After successful authentication, KGC generates a random number. KGC is used for edge servers. Generated temporary public key and hash value And design the corresponding signature. , will message Assemble and send to edge server ,in It is the current timestamp of when the message was sent;

[0044] Step 4.4: Edge Server Upon receiving a KGC message, the edge server verifies its freshness. If the verification passes, the edge server... calculate , KGC for edge servers The generated temporary public key recovery value; then calculated:

[0045]

[0046] Verify the signature; if the equation holds true, then the edge server... Complete KGC identity verification and officially obtain blockchain data reading permissions.

[0047] A further preferred approach, in step 4.2, is when KGC simultaneously receives data from n edge servers... When initiating an authentication request, the following calculation is performed:

[0048]

[0049] Verify all signatures in one batch; among them For edge servers signature, For edge servers The corresponding temporary public key recovery value, For edge servers The identifier recovery value, For edge servers The generated long-term public key component, KGC for edge servers The generated long-term public key component.

[0050] Further preferred solutions, specifically including in step 5:

[0051] Step 5.1: Vehicle Generate random numbers and current timestamp Calculate vehicles The corresponding temporary public key and hash value ;vehicle Using one's own private key Calculate signature :

[0052]

[0053] vehicle parameters The authentication request message is assembled and sent to the edge server via a public channel. ;

[0054] Step 5.2: Edge Server Upon receiving the authentication request message, the edge server verifies the message's freshness. If the verification is successful, the edge server... calculate , For vehicles The corresponding temporary public key recovery value is calculated. Tracing true identity; through calculation:

[0055]

[0056] Verify signature If the equation holds true, then the vehicle Identity verification successful;

[0057] Step 5.3: Successfully Authenticate the Vehicle After that, edge server Generate random numbers and current timestamp Computing edge servers For vehicles Generated temporary public key and set the key ,pass Find vehicles on the blockchain The corresponding data Through PUF reconstruction algorithm Obtain the vehicle stable key And through calculation:

[0058]

[0059] Calculate signature It also utilizes stable keys. Through symmetric encryption algorithm Symmetric encryption is used to obtain Send messages through public channels Give the vehicle ;

[0060] Step 5.4: Vehicle Received from edge server After sending a message, verify its freshness. Once verification is successful, the vehicle... Challenges of leveraging local storage through its own PUF Calculate the response And through the generation algorithm in the fuzz extractor calculate Then, the received parameters are processed using a symmetric decryption algorithm. Symmetric decryption yields , For edge servers For vehicles The generated temporary public key recovery value; then calculated:

[0061]

[0062] Verify signature If the equation is true, it represents the vehicle. Completed edge server After identity authentication, a session key is finally generated between the vehicle and the edge server:

[0063]

[0064] Thus the vehicle With edge servers Complete two-way authentication.

[0065] Further preferred solutions, specifically including step 6:

[0066] Step 6.1: Vehicle Generate random numbers and current timestamp Calculate the response as well as And further calculate the vehicle Cross-domain temporary public key And vehicles Using one's own private key Calculate signature , where parameters Finally, a stable key is used. Symmetric encryption is obtained ; to convey information After assembly, it is sent to the edge server via a public channel. ;

[0067] Step 6.2: Edge Server Received vehicle After sending the information, verify its freshness. Once verification is successful, the edge server... calculate ,pass Read the corresponding vehicle from the blockchain. Data And the vehicle was calculated using the PUF reconstruction algorithm. stable key Use stable key Through symmetric decryption algorithm Symmetric decryption yields Then, through calculation:

[0068]

[0069] Verify signature If the equation is true, it represents the vehicle. Identity verification successful;

[0070] Step 6.3: Edge Server Generate random numbers and current timestamp And calculate parameters and Edge server Using one's own private key Design Signature , where parameters Edge server Read the target vehicle from the blockchain. Registration information And calculate the corresponding key. Edge server Using one's own private key Calculate signature , where parameters and using the key Symmetric encryption is obtained , encrypt the obtained Send to the target vehicle via public channel ;

[0071] Step 6.4: Target Vehicle Received from edge server After verifying the freshness of the message, the target vehicle... Response calculated using embedded PUF , For the target vehicle The generated challenge, and calculation Obtain the vehicle key ,use Symmetric decryption Get parameters Then, through calculation:

[0072]

[0073] Verify signature If the equation holds true, it represents an edge server. Identity verification successful;

[0074] Step 6.5: Target Vehicle Generate random numbers and timestamp And calculate parameters Generate session key and using its own private key Design Signature ,in Using session keys For signature Symmetric encryption is obtained Finally, the parameters Send to vehicle ;

[0075] Step 6.6: Vehicle Received from the target vehicle After sending a message, verify its freshness. Once verification is successful, the vehicle... Through calculation:

[0076]

[0077] Verify signature If the equation holds true, it represents an edge server. Identity authentication is successful, and a session key between vehicles is then generated. Using inter-vehicle session keys Symmetric decryption parameters get Then, through calculation:

[0078]

[0079] Verify signature If the equation holds true, it represents the target vehicle. Identity verification passed, vehicle With vehicles Implement two-way identity authentication.

[0080] Beneficial effects:

[0081] The cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on PUF and certificate-free authentication proposed in this invention has the following advantages:

[0082] 1) This invention proposes a blockchain-based cross-domain authentication scheme for vehicle-to-everything (V2X) communication. The scheme includes both V2V and V2I protocols and supports V2I batch authentication. This scheme is applicable not only to cross-domain vehicle scenarios but also to intra-domain authentication needs, and the two protocol structures are independent and do not interfere with each other.

[0083] 2) To avoid the complexity of traditional PKI certificate management and the key escrow issues in IBE schemes, this invention adopts a certificateless public-key cryptography system. Furthermore, each vehicle's OBU integrates a Physically Unclonable Function (PUF), improving security while reducing the device's computational load. To address the PUF's sensitivity to environmental noise, this invention introduces a fuzzy extractor to ensure key stability and consistency.

[0084] 3) This invention introduces blockchain technology to store registration information for vehicles and edge servers in different domains. The Key Generation Center (KGC) is only responsible for registering vehicles and edge servers, while authentication calculations are performed by edge servers with high-performance computing capabilities, thereby effectively reducing the computational burden on the KGC and avoiding the risk of single points of failure. Attached Figure Description

[0085] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0086] Figure 1 System model diagram;

[0087] Figure 2 Vehicle registration process;

[0088] Figure 3 Edge server registration process;

[0089] Figure 4 : Authorization authentication process;

[0090] Figure 5 V2I cross-domain authentication and key negotiation process;

[0091] Figure 6 V2V cross-domain authentication and key negotiation process. Detailed Implementation

[0092] The embodiments of the present invention are described in detail below. These embodiments are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0093] This embodiment provides a cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on PUF and certificate-free authentication. Its system model is as follows: Figure 1As shown, the system model mainly includes four core entities: Key Generation Center (KGC), Vehicle, Edge Server (ES), and Blockchain Network (BC).

[0094] Key Generation Center (KGC): Responsible for initializing the entire system, generating the system master key and master public key; responsible for registering vehicles and edge servers, generating partial private keys for registered entities; responsible for authenticating the permissions of edge servers, authorizing them to access blockchain data; KGC does not participate in real-time authentication calculations to avoid becoming a performance bottleneck and single point of failure.

[0095] Vehicle: The On-Board Unit (OBU) embeds a Physically Unclonable Function (PUF) and a fuzz extractor to generate localized and unclonable stable keys; the vehicle adopts a certificateless public-key cryptography system, interacts with the KGC to generate public-private key pairs, and registers public key information with the blockchain; the vehicle has lightweight signature and key negotiation capabilities, and can complete two-way authentication with edge servers or other vehicles.

[0096] Edge Server (ES): Deployed in various management domains, it has strong computing and storage capabilities; the edge server registers with KGC and obtains a certificateless public-private key pair, and obtains the right to read blockchain data after authorization; the edge server undertakes the main cryptographic operation tasks in the cross-domain authentication process, including vehicle signature verification, temporary key generation, session key negotiation and message forwarding, effectively reducing the computing load of the vehicle unit.

[0097] Blockchain Network (BC): Employs distributed ledger technology to store vehicle and edge server registration information, including pseudonyms, public key components, etc.; the blockchain only provides query services to edge servers authorized by KGC, ensuring the security and controllability of data access; the decentralized nature of the blockchain eliminates the dependence of traditional cross-domain authentication on centralized trust anchors.

[0098] The following is combined Figures 2 to 6 The core steps of this embodiment are described in detail.

[0099] Step 1: System Initialization:

[0100] The system initialization process is executed by the Key Generation Center (KGC), which selects elliptic curve parameters, generates the system master key and master public key, and publishes the system parameters. This embodiment includes the following sub-steps:

[0101] Step 1.1: KGC selects a definition in a finite field Safety Elliptic Curve And select a base point on the elliptic curve. Its order is a large prime number q;

[0102] Step 1.2: KGC generates random numbers Used as the system master key, and the master public key is calculated. ;in, Let represent the multiplicative group consisting of all non-zero elements in the ring of integers modulo q;

[0103] Step 1.3: KGC Secure Storage and publish system parameters to all entities within the system. and KGC's unique identifier ,in It is a collision-resistant hash function.

[0104] Once the system initialization is complete, KGC will be able to provide registration services for vehicles and edge servers.

[0105] Step 2: Vehicle Registration: The vehicle generates a physical response through the embedded PUF, extracts a stable key through a fuzz extractor, interacts with KGC to generate a certificateless key pair, and stores the registration information in the blockchain.

[0106] like Figure 2 The diagram shown illustrates the vehicle registration process of this invention. This embodiment uses a vehicle... Taking the registration process with KGC as an example, the specific steps include the following:

[0107] Step 2.1: Vehicle Generate PUF response and stable key:

[0108] vehicle Randomly generated and stored locally challenge Input it into the PUF module to calculate the response. Since the PUF response is susceptible to environmental noise interference, this embodiment introduces a fuzz extractor for stability processing. (Vehicle) Through the generation algorithm in the fuzz extractor calculate ,in, It is a stable key generated by a fuzz extractor. This is auxiliary data. Vehicle Randomly generate secret values Calculate part of the public key , parameters After being assembled with the registration request, it is sent to KGC, where It is a vehicle A unique identifier;

[0109] Step 2.2: KGC generates a partial private key and pseudonym for the vehicle:

[0110] KGC received the vehicle. After receiving the registration request, the system first queries the local database. Check if the registration already exists. If it does, refuse registration; otherwise, continue the registration process.

[0111] KGC generates random numbers. And calculate the temporary public key corresponding to KGC. and for vehicles Calculate kana ,in, For connection operations, As an XOR operation, this pseudonym is used to anonymously identify the vehicle during subsequent authentication processes, preventing the leakage of its true identity; KGC further... Calculate part of the private key , parameters The parameters are assembled and stored in a distributed blockchain ledger, and finally... Assembly and delivery to vehicles ;

[0112] Step 2.3: Generate a certificateless public / private key pair for the vehicle:

[0113] vehicle After receiving the message returned by KGC, the first step is to calculate:

[0114]

[0115] Verify the validity of a portion of the private key in the message sent by KGC, including... This indicates whether the equation is true; if verification fails, the registration process is aborted; if verification succeeds, it proves that the private key generated by KGC is valid and the message has not been tampered with. (Vehicle) set up Use your public key to set Use it as your private key. Finally, the vehicle... Local secure storage , , and And publish the public key within the system. Other vehicles, such as They also register with KGC through the same process.

[0116] Step 3: Edge Server Registration: The edge server registers with KGC to obtain a certificateless key pair for subsequent authentication and communication.

[0117] like Figure 3 The diagram illustrates the edge server registration process of this invention. In this embodiment, the edge server governing domain x is used. Taking the registration process with KGC as an example, the specific steps include the following:

[0118] Step 3.1: The edge server sends a registration request:

[0119] Edge servers governing the x domain Generate random numbers And compute edge servers Generated long-term public key components , parameters The registration request is sent to KGC, where It is an edge server A unique identifier;

[0120] Step 3.2: KGC generates a partial private key for the edge server:

[0121] KGC received edge server After receiving the registration request, query the local database. Check if the registration already exists. If it does, refuse registration; otherwise, continue the registration process.

[0122] KGC generates random numbers. KGC is used for edge servers. Generated long-term public key components and for edge servers Generate a partial private key KGC saves After reaching the local database, it is sent to the edge server. Send parameters ;

[0123] Step 3.3: The edge server generates a certificateless public / private key pair:

[0124] Edge server After receiving the message returned by KGC, the first step is to calculate:

[0125]

[0126] Verify the validity of a portion of the private key in the message sent by KGC, including... This indicates whether the equation is true; if the verification fails, the registration process is aborted; if the verification succeeds, the edge server... set up Set as your own private key Store it securely locally as your own public key. and And publish the public key within the system. Edge servers that govern other domains Complete the registration process using the same steps.

[0127] Step 4: Authentication: The edge server sends an authentication request to KGC and obtains the permission to read blockchain data through the batch authentication mechanism.

[0128] like Figure 4 The diagram shown illustrates the authorization authentication process of this invention.

[0129] To prevent unauthorized entities from reading vehicle registration information on the blockchain, this embodiment designs an edge server permission authentication mechanism. Only edge servers authenticated by KGC can be granted the permission to read data on the blockchain and authenticate vehicles. Furthermore, to improve authentication efficiency, this embodiment also introduces a high-efficiency batch authentication mechanism, supporting KGC to perform batch authentication on multiple edge servers, including the following sub-steps:

[0130] Step 4.1: The edge server initiates an authentication request:

[0131] Edge server Generate random numbers and current timestamp Computing edge servers The corresponding temporary public key and hash value ,in It is the unique identifier of KGC. It is an edge server Unique identifier, edge server Use your own private key Generate signature Then the edge server Will Assemble and send to KGC;

[0132] Step 4.2: KGC verifies signatures in a single transaction or in batches:

[0133] KGC received edge server After receiving the message, first through Verify the freshness of the timestamp, among which It is the current timestamp. This is the maximum time deviation allowed by the system. After verification, KGC calculates... ,in and The apostrophe indicates that the value is recovered from the received data and is used to distinguish it from the original value. and To distinguish, all the words below marked with an apostrophe have this meaning, so here... For edge servers The identifier recovery value, For edge servers The corresponding temporary public key recovery value. Calculated as follows:

[0134]

[0135] Verify signature If the equation holds true, then a single edge server Authentication successful;

[0136] When KGC receives data from n edge servers simultaneously When initiating an authentication request, it is calculated

[0137]

[0138] Verify all signatures in one batch; among them For edge servers signature, For edge servers The corresponding temporary public key recovery value, For edge servers The identifier recovery value, For edge servers The generated long-term public key component, KGC for edge servers The generated long-term public key component. This batch authentication equation is based on the linear property of elliptic curve point addition, combining n point multiplication operations into two, significantly reducing the computational overhead of KGC.

[0139] Step 4.3: KGC returns authentication confirmation:

[0140] After successful authentication, KGC generates a random number. KGC is used for edge servers. Generated temporary public key and hash value And design the corresponding signature. , will message Assemble and send to edge server ,in This is the current timestamp of when the message was sent. If authentication fails, the edge server... The subsequent authentication process will be suspended, and the user will not be granted permission to read data on the blockchain.

[0141] Step 4.4: Edge Server Verify KGC identity:

[0142] Edge server After receiving the KGC message, calculate To verify the freshness of the message, among which It is the current timestamp of the received message. After successful verification, the edge server... calculate , KGC for edge servers The generated temporary public key recovery value; then calculated:

[0143]

[0144] Verify the signature; if the equation holds true, then the edge server... Complete KGC identity authentication and officially obtain blockchain data read permissions. If authentication fails, the edge server... The subsequent authentication process will be suspended, and the user will not be granted permission to read data on the blockchain.

[0145] Step 5: V2I cross-domain authentication and key negotiation: The vehicle and the edge server authenticate each other based on certificateless signature and PUF response, and generate a session key.

[0146] like Figure 5 The diagram shown illustrates the V2I cross-domain authentication and key negotiation process of this invention. (Vehicle) It can perform mutual authentication with edge servers that have been authorized and certified. If it's domain authentication, the vehicle... Will select local domain server If it's cross-domain authentication, then select another domain edge server. Here we assume the vehicle... With x domain Performing cross-domain authentication includes the following sub-steps:

[0147] Step 5.1: Vehicle Initiate an authentication request:

[0148] vehicle Generate random numbers and current timestamp Calculate the vehicle The corresponding temporary public key and hash value ;vehicle Using one's own private key Calculate signature :

[0149]

[0150] Then the vehicle parameters The authentication request message is assembled and sent to the edge server via a public channel. ;

[0151] Step 5.2: Edge Server Verify vehicle identity:

[0152] Edge server Upon receiving the authentication request message, first pass Verify the freshness of the message, among which It is the current timestamp of the received message. After successful verification, the edge server... calculate , For vehicles The corresponding temporary public key recovery value is calculated. Tracing true identity; through calculation:

[0153]

[0154] Verify signature If the equation holds true, then the vehicle Identity verification successful;

[0155] Step 5.3: Edge Server Respond and generate a stable key:

[0156] Successfully certified vehicle After that, edge server Generate random numbers and current timestamp Calculate the edge server For vehicles Generated temporary public key and set the key ,pass Find vehicles on the blockchain The corresponding data Through PUF reconstruction algorithm Obtain the vehicle stable key And through calculation:

[0157]

[0158] Calculate signature It also utilizes stable keys. Through symmetric encryption algorithm The parameters are obtained by symmetric encryption. Send messages through public channels Give the vehicle ;

[0159] Step 5.4: Vehicle Verify the identity of the edge server:

[0160] vehicle Received from edge server After the message is sent, it is calculated Verify the freshness of the message. It is the current timestamp of the received message. After verification, the vehicle... Challenges of leveraging local storage through its own PUF calculate And through the generation algorithm in the fuzz extractor calculate Then, the received parameters are processed using a symmetric decryption algorithm. Symmetric decryption yields , For edge servers For vehicles The generated temporary public key recovery value; then calculated:

[0161]

[0162] Verify signature If the equation is true, it represents the vehicle. Completed edge server After identity authentication, a session key is finally generated between the vehicle and the edge server:

[0163]

[0164] At this point, the vehicle With edge servers Complete two-way authentication and negotiate a session key between the vehicle and the edge server. Subsequent communications can be encrypted using this key.

[0165] Step 6: V2V cross-domain authentication and key negotiation: Cross-domain vehicles complete mutual identity authentication and session key negotiation with the assistance of edge servers.

[0166] like Figure 6 The diagram illustrates the V2V cross-domain authentication and key negotiation process of this invention. If the vehicle... Want to interact with other vehicles in the same domain To communicate, one can communicate with the edge servers that govern this domain. Initiate a request, Vehicles will be certified first. The identity is then used to locate the vehicle through data on the blockchain. Registration information, to vehicles Send relevant parameters, vehicle Certification After identifying the vehicle, generate a vehicle-related identifier. Session key Send relevant parameters to the vehicle ,vehicle Confirm vehicle and edge servers A corresponding session key will also be generated after the identity is confirmed. To complete cross-domain authentication, the following sub-steps are required:

[0167] Step 6.1: Vehicle Initiate a cross-domain V2V communication request:

[0168] vehicle Generate random numbers and current timestamp ,vehicle Calculate the response using an embedded PUF And through the generation algorithm in the fuzz extractor calculate And further calculate the vehicle Cross-domain temporary public key And vehicles Using one's own private key Calculate signature , where parameters Finally, a stable key is used. Symmetric encryption is obtained ,in For the target vehicle A unique identifier; to transmit information After assembly, it is sent to the edge server via a public channel. ;

[0169] Step 6.2: Edge Server Vehicle verification identity:

[0170] Edge server Upon receiving the information, the edge server verifies its freshness by calculating the timestamp. Once verification is successful, the edge server... calculate ,pass Read the corresponding vehicle from the blockchain. Data And the vehicle was calculated using the PUF reconstruction algorithm. stable key Use stable key Through symmetric decryption algorithm Symmetric decryption yields Then, through calculation:

[0171]

[0172] Verify signature If the equation is true, it represents the vehicle. Identity verification is successful, thus ensuring vehicle... The legitimacy of identity; conversely, the vehicle. Identity verification failed; the agreement is terminated.

[0173] Step 6.3: Edge Server Generate forwarding parameters:

[0174] Edge server Generate random numbers and current timestamp And calculate the parameters and Edge server Using one's own private key Design Signature , where parameters Edge server Read the target vehicle from the blockchain. Registration information And through PUF reconstruction algorithm Calculate the corresponding key Edge server Using one's own private key Calculate signature , where parameters Finally, use the key. Symmetric encryption is obtained , encrypt the obtained Send to the target vehicle via public channel ;

[0175] Step 6.4: Target Vehicle Verify Edge Server identity:

[0176] Target vehicle Received from edge server After receiving the message, the freshness of the information is verified by calculating the timestamp. Once verification is successful, the message is sent to the target vehicle. Embedded PUF Response Calculation , For the target vehicle Randomly generated challenge, target vehicle Also through the generation algorithm in the fuzz extractor calculate Obtain the vehicle key ,use Symmetric decryption Get parameters Then, through calculation:

[0177]

[0178] Verify signature If the equation holds true, it represents an edge server. Successful identity authentication ensures the edge server's security. The legitimacy of one's identity.

[0179] Step 6.5: Target Vehicle Generate session key and respond:

[0180] Target vehicle Generate random numbers and timestamp And calculate the parameters Generate session key and using its own private key Design Signature ,in Using session keys For signature Symmetric encryption is obtained Finally, the parameters Send to vehicle ;

[0181] Step 6.6: Vehicle Complete two-way authentication and generate a session key:

[0182] vehicle Received from the target vehicle After a message is sent, its freshness is verified using a timestamp. Once verification is successful, the vehicle... Through calculation:

[0183]

[0184] Verify signature If the equation holds true, it represents an edge server. Successful identity authentication ensures the edge server's security. Verify the legitimacy of the identity and further generate inter-vehicle session keys. Decrypt parameters using the inter-vehicle session key symmetric decryption get Then, through calculation:

[0185]

[0186] Verify signature If the equation holds true, it represents the target vehicle. Identity verification is successful, thus ensuring the target vehicle The vehicle's identity and legality have been verified. With vehicles Implement two-way authentication and negotiate a session key between vehicles. .

[0187] It should be noted that the edge server in the Y domain where the target vehicle is located in the above process... Although the character was not elaborated on, its operation and... Basic Symmetry: Edge Server Responsible for verifying vehicles Identity, to vehicle The relevant parameters are forwarded and the necessary signatures are generated. This invention's V2V cross-domain authentication protocol, through the collaborative cooperation of edge servers, enables cross-domain trust transfer and key negotiation between vehicles without direct interaction, and the vehicle only performs lightweight cryptographic operations.

[0188] Through simulation testing and actual deployment verification, this embodiment generates a unique and stable hardware fingerprint for each device by integrating PUF and a fuzzy extractor. It eliminates key escrow risks by combining a certificateless cryptography system, utilizes blockchain distributed storage for registration information to avoid single points of failure, and introduces timestamps and two-way signature mechanisms. This effectively resists common threats such as physical cloning attacks, replay attacks, man-in-the-middle attacks, and impersonation attacks, possessing strong security attributes such as forward and backward confidentiality. In terms of efficiency, the vehicle-side only needs to perform a small number of elliptic curve multiplication and hash operations, eliminating the need for high-overhead computations such as bilinear pairing. The edge server bears the main authentication load, and the KGC employs a batch authentication mechanism. This invention can significantly reduce signature verification overhead. Compared with existing cross-domain authentication schemes based on PKI or bilinear pairing, the computational and communication overheads of this invention are greatly reduced. In terms of scalability, this embodiment supports a unified protocol framework for intra-domain and cross-domain authentication. Edge servers can be dynamically deployed on demand, and the blockchain network has good horizontal scalability, which can support large-scale vehicle networking scenarios. In terms of compatibility and engineering feasibility, this embodiment requires minimal modification to the existing vehicle networking infrastructure. Vehicles only need to add PUF chips and corresponding software modules. Edge servers and KGC can be upgraded through software, making it highly feasible to deploy and valuable for widespread application.

[0189] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various improvements, substitutions, and modifications can be made without departing from the spirit and principles of the present invention, and these improvements, substitutions, and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A cross-domain identity authentication method for vehicle-to-everything (V2X) networks based on PUF and certificate-free authentication, characterized in that: Includes the following steps: Step 1: KGC selects elliptic curve parameters, generates the system master key and master public key, and publishes the system parameters, where KGC is the key generation center; Step 2: The vehicle generates a physical response through the embedded PUF, extracts a stable key through a fuzz extractor, interacts with KGC to generate a certificateless key pair, and stores the registration information in the blockchain; Step 3: The edge server registers with KGC to obtain a certificateless key pair for subsequent authentication and communication; Step 4: The edge server sends an authentication request to KGC and obtains permission to read blockchain data through the batch authentication mechanism; Step 5: The vehicle and the edge server perform two-way authentication based on certificateless signing and PUF response, and generate a session key; Step 6: Cross-domain vehicles complete mutual identity authentication and session key negotiation with the assistance of the edge server.

2. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 1, characterized in that: Step 1 specifically includes: Step 1.1: KGC is defined in a finite field. Safety Elliptic Curve And select the base point on the elliptic curve. Its order is a large prime number q; Step 1.2: KGC generates random numbers As the system master key, calculate the master public key. ;in, Let represent the multiplicative group consisting of all non-zero elements in the ring of integers modulo q; Step 1.3: KGC Secure Storage and publish system parameters to all entities within the system. and KGC's unique identifier ,in It is a collision-resistant hash function.

3. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 2, characterized in that: Step 2 specifically includes: Step 2.1: Vehicle Randomly generated challenges The response is obtained by using the embedded PUF calculation. Algorithm generated by fuzz extractor calculate ,in, It is the generated stable key. It is auxiliary data; vehicles Randomly generate secret values Calculate part of the public key , parameters After being assembled with the registration request, it is sent to KGC, where It is a vehicle A unique identifier; Step 2.2: KGC generates a partial private key and pseudonym for the vehicle: KGC received the vehicle. Verification after registration request Check if it already exists; if not registered, KGC generates a random number. And calculate the temporary public key corresponding to KGC. and for vehicles Calculate kana KGC further provides vehicles Calculate part of the private key , parameters Assemble and store in the blockchain, and finally set the parameters Assembly and delivery to vehicles ; Step 2.3: Vehicle After receiving the message from KGC, the first step is to calculate: Verify the validity of a portion of the private key in the message sent by KGC, including... This indicates whether the equation is true or false; if the verification is successful, the vehicle... Set public key Set private key ;vehicle Local secure storage , , and And publish the public key within the system. .

4. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 3, characterized in that: Step 3 specifically includes: Step 3.1: Edge server governing domain x Generate random numbers And compute edge servers Generated long-term public key components , parameters The registration request is sent to KGC, where It is an edge server A unique identifier; Step 3.2: KGC receives data from the edge server. Verification after registration request Check if it already exists; if not registered, KGC generates a random number. KGC is used for edge servers. Generated long-term public key components and for edge servers Generate a partial private key KGC saves After reaching the local database, it is sent to the edge server. Send parameters ; Step 3.3: Edge Server After receiving the message from KGC, the first step is to calculate: Verify part of the private key in the message sent by KGC The validity of the data is verified, and if the verification is successful, the edge server... Set private key Set public key And publish the public key within the system. .

5. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 4, characterized in that: Step 4 specifically includes: Step 4.1: Edge Server Generate random numbers and current timestamp Computing edge servers The corresponding temporary public key and hash value ,in It is the unique identifier of KGC. It is the unique identifier of the edge server Elasticsearch. Using your own private key Generate signature and parameters Assemble and send to KGC; Step 4.2: KGC receives data from the edge server. After receiving the message, verify the timestamp freshness. Once verification is successful, KGC calculates... ,in For edge servers The identifier recovery value, For edge servers The corresponding temporary public key recovery value; calculated as follows: Verify signature If the equation holds true, then a single edge server Authentication successful; Step 4.3: After successful authentication, KGC generates a random number. KGC is used for edge servers. Generated temporary public key and hash value And design the corresponding signature. , will message Assemble and send to edge server ,in It is the current timestamp of when the message was sent; Step 4.4: Edge Server Upon receiving a KGC message, the edge server verifies its freshness. If the verification passes, the edge server... calculate , KGC for edge servers The generated temporary public key recovery value; then calculated: Verify the signature; if the equation holds true, then the edge server... Complete the identity verification for KGC and obtain access to read blockchain data.

6. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 5, characterized in that: In step 4.2, when KGC simultaneously receives data from n edge servers... When initiating an authentication request, the following calculation is performed: Verify all signatures in one batch; among them For edge servers signature, For edge servers The corresponding temporary public key recovery value, For edge servers The identifier recovery value, For edge servers The generated long-term public key component, KGC for edge servers The generated long-term public key component.

7. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 5, characterized in that: Step 5 specifically includes: Step 5.1: Vehicle Generate random numbers and current timestamp Calculate vehicles The corresponding temporary public key and hash value ;vehicle Using one's own private key Calculate signature : vehicle parameters The authentication request message is assembled and sent to the edge server via a public channel. ; Step 5.2: Edge Server Upon receiving the authentication request message, the edge server verifies the message's freshness. If the verification is successful, the edge server... calculate , For vehicles The corresponding temporary public key recovery value is calculated. Tracing true identity; through calculation: Verify signature If the equation holds true, then the vehicle Identity verification successful; Step 5.3: Successfully Authenticate the Vehicle After that, edge server Generate random numbers and current timestamp Computing edge servers For vehicles Generated temporary public key and set the key ,pass Find vehicles on the blockchain The corresponding data Through PUF reconstruction algorithm Obtain the vehicle stable key And through calculation: Calculate signature It also utilizes stable keys. Through symmetric encryption algorithm Symmetric encryption is used to obtain Send messages via public channels Give the vehicle ; Step 5.4: Vehicle Received from edge server After sending a message, verify its freshness. Once verification is successful, the vehicle... Challenges of leveraging local storage through its own PUF Calculate the response And through the generation algorithm in the fuzz extractor calculate Then, the received parameters are processed using a symmetric decryption algorithm. Symmetric decryption yields , For edge servers For vehicles The generated temporary public key recovery value; then calculated: Verify signature If the equation is true, it represents the vehicle. Completed edge server After identity authentication, a session key is finally generated between the vehicle and the edge server: Thus the vehicle With edge servers Complete two-way authentication.

8. The cross-domain identity authentication method for vehicle networking based on PUF and certificateless authentication as described in claim 5, characterized in that: Step 6 specifically includes: Step 6.1: Vehicle Generate random numbers and current timestamp Calculate the response as well as And further calculate the vehicle Cross-domain temporary public key And vehicles Using one's own private key Calculate signature , where parameters Finally, a stable key is used. Symmetric encryption is obtained ; to convey information After assembly, it is sent to the edge server via a public channel. ; Step 6.2: Edge Server Received vehicle After sending the information, verify its freshness. Once verification is successful, the edge server... calculate ,pass Read the corresponding vehicle from the blockchain. Data And the vehicle was calculated using the PUF reconstruction algorithm. stable key Use stable key Through symmetric decryption algorithm Symmetric decryption yields Then, through calculation: Verify signature If the equation is true, it represents the vehicle. Identity verification successful; Step 6.3: Edge Server Generate random numbers and current timestamp And calculate parameters and Edge server Using one's own private key Design Signature , where parameters Edge server Read the target vehicle from the blockchain. Registration information And calculate the corresponding key. Edge server Using one's own private key Calculate signature , where parameters and using the key Symmetric encryption is obtained , encrypt the obtained Send to the target vehicle via public channel ; Step 6.4: Target Vehicle Received from edge server After verifying the freshness of the message, the target vehicle... Response calculated using embedded PUF , For the target vehicle The generated challenge, and calculation Obtain the vehicle key ,use Symmetric decryption Get parameters Then, through calculation: Verify signature If the equation holds true, it represents an edge server. Identity verification successful; Step 6.5: Target Vehicle Generate random numbers and timestamp And calculate parameters Generate session key and using its own private key Design Signature ,in Using session keys For signature Symmetric encryption is obtained Finally, the parameters Send to vehicle ; Step 6.6: Vehicle Received from the target vehicle After sending a message, verify its freshness. Once verification is successful, the vehicle... Through calculation: Verify signature If the equation holds true, it represents an edge server. Identity authentication is successful, and a session key between vehicles is then generated. Using inter-vehicle session keys Symmetric decryption parameters get Then, through calculation: Verify signature If the equation holds true, it represents the target vehicle. Identity verification passed, vehicle With vehicles Implement two-way identity authentication.

Images