A batch verification method and system for privacy protection in Internet of Vehicles

Abstract

This invention includes a method and system for batch verification of vehicle network privacy protection. The method includes: a trusted third party generating public parameters using a secure elliptic curve algorithm, and registering the identities of a first vehicle and a first RSU using the public parameters, generating a first identity and a first key corresponding to the first vehicle and the first RSU respectively; in response to a vehicle login command, the first vehicle performing verification using the first identity and the first key; in response to successful verification, the first vehicle and the first RSU, combining the first identity and the first key of the first vehicle and the first RSU, simultaneously completing initial authentication with each other using the trusted third party; and the first vehicle and a second RSU completing mutual authentication based on the authentication results of the first vehicle and the first RSU. The method provided by the embodiments of this invention can efficiently and accurately perform batch verification of vehicles and PSUs within the vehicle network, while ensuring that privacy is not leaked.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a batch verification method and system for privacy protection in the Internet of Vehicles. Background Art

[0002] With the application of 5G networks, their high transmission speed and low latency have significantly improved the communication performance of vehicle-to-everything (V2X) networks and supported real-time interconnection of large-scale devices, laying the foundation for the popularization of intelligent transportation systems. However, in the open communication environment, V2X devices generate massive amounts of data every day, making privacy leaks and security threats increasingly prominent issues.

[0003] When authenticating vehicles based on the Internet of Vehicles (IoV), authentication schemes are mainly divided into three-party authentication architectures and two-party authentication architectures. Three-party authentication relies on a trusted third party (TPA) as an intermediary for identity verification. The TPA manages keys and identity information, improving overall security. However, this method requires additional communication overhead and is susceptible to single-point-of-failure risks. If the TPA fails or is attacked, the authentication process cannot continue and may even result in the leakage of private data. In contrast, two-party authentication does not rely on a third party (e.g., self-certifying public-key cryptography). The two parties complete authentication through direct interaction, effectively avoiding single-point-of-failure issues and improving real-time authentication. However, two-party authentication requires both parties to independently undertake all computational tasks, resulting in high computational overhead, which can become a bottleneck, especially in resource-constrained devices.

[0004] Furthermore, batch verification technology can significantly improve efficiency by processing multiple authentication requests at once, making it suitable for scenarios where multiple vehicles communicate simultaneously in the Internet of Vehicles (IoV). However, its practical application is somewhat limited due to its high computational complexity (e.g., bilinear techniques).

[0005] In summary, existing authentication technologies struggle to achieve an ideal balance between communication overhead, real-time performance, and security, and are unable to meet the demands of connected vehicle devices for secure and efficient communication. Designing an efficient privacy-protecting authentication scheme remains a worthwhile research topic. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a method and system for batch verification of vehicle and PSU in the vehicle network that can perform efficient and accurate batch verification of vehicles and PSUs in the vehicle network, while ensuring that privacy is not leaked.

[0007] The present invention includes a batch verification method for privacy protection in vehicle networking, comprising:

[0008] A trusted third party uses the secure elliptic curve algorithm to generate public parameters, and combines the public parameters to register the identity of the first vehicle and the first RSU, thereby generating the first identity and first key corresponding to the first vehicle and the first RSU respectively.

[0009] In response to a vehicle login command, the first vehicle uses the first identity and the first password for verification;

[0010] In response to successful verification, the first vehicle and the first RSU combine the first identity and the first key of the first vehicle and the first RSU, and simultaneously use the trusted third party to complete the initial authentication with each other.

[0011] The first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU.

[0012] In one embodiment, the public parameters include a secure elliptic curve E, a base point P, a curve order q, and a public key P calculated from a private key formed based on random numbers. pub One-way collision-resistant hash function, shared key for RSU.

[0013] In one embodiment, registering the identity of the first vehicle in conjunction with the public parameters includes:

[0014] The first vehicle generates the first identity and the first password based on random numbers and sends them to a trusted third party through a secure channel.

[0015] The trusted third party verifies the first identity and first password of the first vehicle obtained by the third party. If the verification is successful, the third party generates the public key and private key corresponding to the first vehicle based on random number calculation.

[0016] The public key, private key, and public parameters are combined to perform encrypted calculations on the parameters of the first vehicle at the current timestamp, and the calculation results are stored in the target database. At the same time, the calculation results, public key, private key, and current timestamp representing the vehicle login information are sent to the first vehicle through a secure channel.

[0017] The first vehicle performs a hash calculation on the obtained vehicle login information to verify its legitimacy as vehicle login information. If it is legitimate, the hash calculation result is securely stored.

[0018] In one embodiment, registering the identity of the first RSU in conjunction with the public parameters includes:

[0019] The first RSU will send a first identity generated based on a random number to a trusted third party through a secure channel for registration;

[0020] When the trusted third party determines that the first identity is legitimate, it generates a signing key and a signing public key for the first RSU based on a random number, and simultaneously calculates and generates a private key for the first RSU based on the signing key, the signing public key, and the first identity.

[0021] The trusted third party stores the first identity of the first RSU and the private key of the first RSU, and sends the signing key, signing public key, private key of the first RSU, and shared key of the RSU to the first RSU through a secure channel;

[0022] The first RSU stores the signing key, the signing public key, the first RSU's private key, and the RSU's shared key, and publishes its first identity and signing public key to nearby vehicles and RSUs.

[0023] In one embodiment, the first vehicle verifies the first identity and the first key, including:

[0024] The on-board unit of the first vehicle decrypts the vehicle login information based on the second identity and password, and performs a hash calculation based on the vehicle login information to verify the legitimacy of the vehicle login information.

[0025] In one embodiment, the first RSU is the first RSU along the route of the first vehicle. The first vehicle and the first RSU, combined with the first identity and first key of the first vehicle and the first RSU, simultaneously complete initial authentication with each other using the trusted third party, including:

[0026] The first vehicle calculates and generates a vehicle verification request based on the first identity, the encrypted public key, the encrypted private key, the current timestamp, and the temporary key generated by the random number, and sends it to the first RSU;

[0027] The first RSU verifies the vehicle verification request in terms of time and information length;

[0028] If the verification is successful, the first RSU verifies the integrity of the information in the vehicle verification request based on the data in the vehicle verification request and the private key of the first RSU. If the verification is successful, the first verification message is generated by combining the current timestamp and the vehicle verification request and sent to a trusted third party.

[0029] The trusted third party verifies the time of the first verification message. If the verification is successful, the private key of the first RSU is determined based on the first identity in the first verification message, and the private key of the first RSU is used to assist in the execution of the data verification process in the first verification message.

[0030] If the verification passes, the trusted third party combines the current timestamp and the first verification message to generate a second verification message and sends it to the first RSU.

[0031] The first RSU verifies the time of the second verification message. If the verification passes, it verifies the reasonableness of the data in the second verification message. If the verification passes, it negotiates with the public and private keys of the first vehicle to determine the signature information to be used for the next round of authentication.

[0032] The first RSU generates a third verification message based on the signature information and the current timestamp, and sends it to the first vehicle;

[0033] The first vehicle verifies the time and data validity of the third verification message. If the verification passes, it calculates and generates a first session key based on the information in the third verification message and stores the signature data in the third verification message for use in the next round of authentication.

[0034] In one embodiment, the first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU, including:

[0035] The first vehicle generates a fourth verification message based on a random number, the signature data from the previous round of authentication, and the current timestamp, and sends it to the second RSU via a public channel;

[0036] The second RSU verifies the time and information length of the fourth verification message. If the verification is successful, the validity of the signature data is calculated and verified based on the signature data, the public key of the first vehicle, and the first session key.

[0037] If the verification passes, the second RSU updates the signature data, generates a fifth verification message containing new signature data for the next round of authentication, and sends it to the first vehicle;

[0038] The first vehicle performs time verification on the fifth verification information. If the verification passes, it calculates the second session key based on the fifth verification information and verifies the new signature information in the fifth verification information in combination with the second session key and the fifth verification information. If the verification passes, the new verification information is included for use in the next round of authentication.

[0039] In one embodiment, the method further includes:

[0040] The second RSU is capable of simultaneously verifying the fourth verification message sent by the first vehicle and at least one fourth verification message sent by the second vehicle.

[0041] In one embodiment, the method further includes:

[0042] When the second RSU verifies and determines that the first vehicle has engaged in malicious behavior, it will send the initial authentication result to a trusted third party.

[0043] The trusted third party calculates and determines the first identity of the first vehicle based on the initial authentication result and public parameters.

[0044] Upon determining that the first vehicle has engaged in malicious behavior, the registration information of the first vehicle is revoked, a warning message about the first vehicle is issued, and the communication of the first vehicle is blocked.

[0045] Another embodiment of the present invention also provides a batch verification system for privacy protection in the Internet of Vehicles, comprising:

[0046] A trusted third party is used to generate public parameters using a secure elliptic curve algorithm, and to register the identity of the first vehicle and the first RSU in combination with the public parameters, thereby generating the first identity and the first key corresponding to the first vehicle and the first RSU respectively.

[0047] The first vehicle is used to respond to a vehicle login command, and the first vehicle uses the first identity and the first password for verification;

[0048] The first RSU is used to complete the initial authentication in response to successful verification, in conjunction with the first vehicle, the trusted third party, and the first identity and first key of the first vehicle and the first RSU.

[0049] The second RSU and the first vehicle complete mutual authentication based on the authentication results of the first vehicle and the first RSU.

[0050] The beneficial effect of this invention is its ability to be used for secure authentication between vehicles and their roadside units (RSUs) in a connected vehicle environment. The authentication process between a vehicle and the first RSU it passes includes two authentication phases. The first phase employs a three-party architecture, utilizing the proposed credential-assisted authentication with the help of a Trusted Third Party (TPA). This scheme not only avoids significant computational overhead but also eliminates the need to store sensitive vehicle information on the TPA and RSUs. The second phase is the authentication between the vehicle and other RSUs passing along the route. This phase employs a two-party architecture, using a signature from the previous RSU for authentication, thereby reducing computational and communication overhead and alleviating the pressure on the single TPA node. Furthermore, the second phase can also perform batch authentication of vehicles, effectively improving the authentication efficiency of RSUs. Additionally, the use of lightweight cryptographic operations during the authentication process further reduces the computational and communication overhead of batch authentication, making this scheme suitable for resource-constrained connected vehicle environments. Attached Figure Description

[0051] Figure 1This is a flowchart illustrating the batch verification method for vehicle network privacy protection in an embodiment of the present invention.

[0052] Figure 2 This is a flowchart illustrating a batch verification method for vehicle network privacy protection according to another embodiment of the present invention.

[0053] Figure 3 This is a flowchart illustrating a batch verification method for vehicle network privacy protection in another embodiment of the present invention.

[0054] Figure 4 This is a structural diagram of the vehicle network privacy protection batch verification system in an embodiment of the present invention. Detailed Implementation

[0055] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings, but these are not intended to limit the scope of the invention.

[0056] It should be understood that various modifications can be made to the embodiments disclosed herein. Therefore, the following description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope of this invention will be apparent to those skilled in the art.

[0057] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the invention and, together with the general description of the invention given above and the detailed description of the embodiments given below, serve to explain the principles of the invention.

[0058] These and other features of the invention will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.

[0059] It should also be understood that although the invention has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of the invention, which have the features described in the claims and are therefore all within the scope of protection defined herein.

[0060] The above and other aspects, features and advantages of the invention will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.

[0061] Specific embodiments of the invention are described below with reference to the accompanying drawings; however, it should be understood that the disclosed embodiments are merely examples of the invention, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the invention. Therefore, the specific structural and functional details disclosed herein are not intended to be limiting, but merely to serve as the basis and representative basis for the claims to teach those skilled in the art to use the invention in various ways with substantially any suitable detailed structure.

[0062] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments of the present invention.

[0063] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0064] like Figure 1 As shown, this embodiment of the invention provides a batch verification method for privacy protection in the Internet of Vehicles, including:

[0065] S1: A trusted third party uses the secure elliptic curve algorithm to generate public parameters, and combines the public parameters to register the identity of the first vehicle and the first RSU, respectively generating the first identity and the first key corresponding to the first vehicle and the first RSU;

[0066] S2: In response to the vehicle login command, the first vehicle uses the first identity and the first password for verification;

[0067] S3: In response to successful verification, the first vehicle and the first RSU combine the first identity and the first key of the first vehicle and the first RSU, and simultaneously use the trusted third party to complete the initial authentication with each other.

[0068] S4: The first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU.

[0069] Based on the above, this embodiment provides a secure authentication method for vehicles and their roadside units (RSUs) in a vehicle-to-everything (V2X) environment. The authentication between the vehicle and the first RSU it passes includes two stages. The first stage employs a three-party architecture, utilizing the proposed credential-assisted authentication with the help of a Trusted Third Party (TPA). This scheme not only avoids significant computational overhead but also eliminates the need to store sensitive vehicle information on the TPA and RSU. The second stage is the authentication between the vehicle and other RSUs passing along the route. This stage employs a two-party architecture, using a signature from the previous RSU for authentication, thereby reducing computational and communication overhead and alleviating the pressure on the single TPA node.

[0070] For step S1, firstly, during the system initialization phase, after inputting the safety parameter λ, TPA selects a safety elliptic curve E. p :y 2 =x 3 +ax+b(mod p), where a,b∈F p And 4a 3 +27b 2≠0. G is an elliptic curve additive group of order q generated by the base point P. Next, TPA needs to randomly select a number s∈Z. q * Used as its system private key, and generate system public key P pub =s·P. Similarly, sk is from Z. q * The key is randomly selected from the pool and used as the shared key for each RSU. h is a one-way collision-resistant hash function. Finally, the TPA publishes the public parameter {E}. q ,q,P,P pub ,h}, that is, the common parameters include the safety elliptic curve E q The base point P, the curve order q, and the public key P calculated from the private key generated by random numbers. pub A one-way collision-resistant hash function h.

[0071] like Figure 2 As shown, the first vehicle is registered using the aforementioned public parameters, including:

[0072] S5: The first vehicle generates the first identity and the first password based on a random number, and sends them to a trusted third party through a secure channel;

[0073] S6: The trusted third party verifies the first identity and first password of the first vehicle obtained by the third party. If the verification is successful, the third party generates the public key and private key corresponding to the first vehicle based on random number calculation.

[0074] S7: Combine the public key, private key and public parameters to perform encrypted calculation of parameters of the first vehicle at the current timestamp, and store the calculation result in the target database. At the same time, use a secure channel to send the calculation result, public key, private key and current timestamp representing vehicle login information to the first vehicle.

[0075] S8: The first vehicle performs a hash calculation on the obtained vehicle login information to verify its legitimacy as vehicle login information. If it is legitimate, the hash calculation result is stored securely.

[0076] For example, the first vehicle V i For any vehicle, a random ID can be generated for the first vehicle during the registration process. i and PW i ∈Z q * Each of these serves as its real identity and password, and then its ID is transmitted through a secure channel. i Send to TPA for registration. When TPA receives a message from V... i When receiving a message, the ID will be checked. iIs the user on the deregistration list? If yes, reject the registration request. Otherwise, for V... i TPA generates a random number r i ∈Z q * And calculate a i =h(ID) i ||s||r i ) as V i The private key, where A i =a i P is V i The corresponding public key. To achieve authentication, TPA calculates the following parameters: E i =Enc s {ID i ||r i ||T i},B i =a i ⊕h(ID i ),PA i =Enc sk {A i}, where T i Indicates the current timestamp, the E i PA is used to verify credentials for subsequent authentication. i This indicates that the TPA uses the shared key sk of all RSUs as the vehicle's public key A. i The generated ciphertext is encrypted to ensure that messages sent during each authentication and key negotiation process do not directly expose A. i To avoid attacks. i It is a credential that stores encrypted information such as vehicle identity. When a vehicle is subjected to malicious behavior, the TPA can use this vehicle credential submitted by the RSU and its own system private key to decrypt the vehicle's identity ID. i Privacy information, etc. To prevent the leakage of vehicle privacy data due to internal attacks, TPA only stores {B} in its database. i Even under privileged insider attacks, vehicle privacy data will not be leaked. TPA transmits parameter {a} through a secure channel. i A i PA i E i ,T i}Sent to V i When V i After receiving, calculate: H i =h(a i ||A i ||PA i ||E i ||T i), and generate To verify the legitimacy of the vehicle login information. Finally, V i Will The registration process is completed by securely storing the data in its TPD (Trusted Storage Device). H i These are important parameters generated during the vehicle registration process, including the vehicle's identity ID. i Password PW i This information, including personal details, serves to verify the vehicle's identity during login. Only after successful login verification can the user proceed. Decryption The vehicle's private key and other privacy data are calculated and used for the next stage of authentication and key negotiation.

[0077] like Figure 3 As shown, the identity registration of the first RSU in conjunction with the aforementioned public parameters includes:

[0078] S9: The first RSU will send the first identity generated based on a random number to a trusted third party for registration through a secure channel;

[0079] S10: When the trusted third party determines that the first identity is legitimate, it generates a signature key and a signature public key for the first RSU based on a random number, and simultaneously calculates and generates a private key for the first RSU based on the signature key, the signature public key, and the first identity.

[0080] S11: The trusted third party saves the first identity of the first RSU and the private key of the first RSU, and sends the signing key, signing public key, private key of the first RSU and shared key of the RSU to the first RSU through a secure channel;

[0081] S12: The first RSU stores the signing key, signing public key, first RSU private key, and RSU shared key, and publishes its first identity and signing public key to nearby vehicles and RSUs.

[0082] For example, during the RSU registration phase, the TPA completes the registration of the RSU and issues public and private keys, with all RSUs sharing a single key sk. Specifically, the first RSU (R j This is the first RSU that the first vehicle passes along the route. The first RSU generates a random number ID. j As its true identity, and then through a secure channel its ID j Send to TPA for registration; upon receiving from R j After the registration request, TPA verifies the ID. j The legality of the ID. jIf invalid, the registration request will be rejected. Otherwise, TPA generates a random number d. j ∈Z q * Used as the signing key for RSU, and the public key D is calculated. j =d j ·P. Furthermore, TPA is for R j Generate private key sk j =d j +h(ID j ||D j )*s (mod q) . d j R j This signature is used to generate a signature after vehicle authentication, and this signature will support authentication between the vehicle and the next RSU. Finally, the TPA will use {ID} j ,sk j} is saved to its database, and {d} is simultaneously transmitted through a secure channel. j D j ,sk j ,sk} is sent to R j The sk is the key issued by TPA to all registered vehicles. This key is uniform, meaning that the key issued to each registered vehicle is the same. After receiving the message, R j Secure storage {d j D j ,sk j ,sk}, and publish its identity ID to nearby vehicles and RSUs. j and public key D j .

[0083] The first vehicle verifies the first identity and the first key, including:

[0084] S13: The on-board unit of the first vehicle decrypts the vehicle login information based on the second identity and password, and performs a hash calculation based on the vehicle login information to verify the legality of the vehicle login information.

[0085] For example, in V i During the login phase, the OBU (On-Board Unit) receives V i Identity and password {ID i PW i}, and calculate accordingly. Used as the decryption key, and decrypted to obtain Then, the OBU checks condition H. i =h(a i ′||A i ′||PA i ′||E i′||T i Does ′) hold true? H i These are the data a i ′||A i ′||PA i ′||E i ′||T i The hash value of ' is used to verify the integrity of the data on the right side of the equation. Due to the collision resistance of hash algorithms, attackers cannot tamper with this value. The above process is also the process by which vehicle login requires inputting an ID. i and PW i By calculating Decrypt Output a series of parameters {a i ′||A i ′||PA i ′||E i ′||T i To calculate h(a) using ′} i ′||A i ′||PA i ′||E i ′||T i (′), by comparing with the H generated during vehicle registration i The system checks if the vehicles are identical to confirm successful vehicle login. If the condition is met, then V... i The login information is considered valid. Otherwise, the OBU will reject further requests until V... i Login successful. Once login is complete, further steps will be taken. i The authentication and key negotiation phase.

[0086] Furthermore, the authentication and key negotiation between the vehicle and the RSU (Roadside Unit) proposed in this embodiment includes two phases. The first phase, denoted as P1, is a three-party architecture scheme for initial authentication between the vehicle and the first RSU, in which TPA is included. The second phase, denoted as P2, is a two-party architecture scheme (j≥2) between the vehicle and the j-th RSU (not the first RSU) on the path, which relies on the signature of the previous RSU in the (j-1)-th round of authentication without the need for TPA communication. This scheme leverages the advantages of classic three-party and two-party authentication architectures to meet the security requirements of vehicle-to-everything (IoV) networks, resisting common attacks while maintaining low performance overhead. Notably, the batch verification in P2 significantly improves the authentication efficiency of the RSU.

[0087] Specifically, in the first phase, the first RSU is the first RSU along the route of the first vehicle. The first vehicle and the first RSU, combined with their first identities and first keys, simultaneously complete initial authentication with the trusted third party, including:

[0088] S14: The first vehicle calculates and generates a vehicle verification request based on the first identity, the encrypted public key, the encrypted private key, the current timestamp, and the temporary key generated by the random number, and sends it to the first RSU;

[0089] S15: The first RSU verifies the time and information length of the vehicle verification request;

[0090] S16: If the verification is successful, the first RSU verifies the integrity of the information in the vehicle verification request based on the data in the vehicle verification request and the private key of the first RSU. If the verification is successful, the first verification message is generated by combining the current timestamp and the vehicle verification request and sent to a trusted third party.

[0091] S17: The trusted third party verifies the time of the first verification message. If the verification is successful, the private key of the first RSU is determined based on the first identity in the first verification message, and the private key of the first RSU is used to assist in the execution of the data verification process in the first verification message.

[0092] S18: If the verification passes, the trusted third party combines the current timestamp and the first verification message to generate a second verification message and sends it to the first RSU;

[0093] S19: The first RSU verifies the time of the second verification message. If the verification passes, it verifies the reasonableness of the data in the second verification message. If the verification passes, it negotiates with the public and private keys of the first vehicle to determine the signature information to be used for the next round of authentication.

[0094] S20: The first RSU generates a third verification message based on the signature information and the current timestamp, and sends it to the first vehicle;

[0095] S21: The first vehicle verifies the time and data validity of the third verification message. If the verification is successful, it calculates and generates a first session key based on the information in the third verification message and stores the signature data in the third verification message for the next round of authentication.

[0096] In one embodiment, when vehicle V i Before sending an authentication request to the nearest RSU, a number x will be randomly selected first. i,1 ∈Z q * Calculate X i,1 =x i,1 ·P, and generate a temporary key C i,1 =(a i ·(D1+h(ID1||D1)·Ppub )||T i,1,1 ), where T i,1,1 This is the current timestamp. The X... i,1 C is the parameter used to generate the session key for key negotiation. i,1 The intermediate key is used to encrypt the credential information; only the correct RSU can calculate C. i,1 Because this is the first round of authentication—that is, authentication between the first vehicle and the first RSU in the procession—the RSU cannot complete the authentication using the previous round's signature provided by the vehicle. Therefore, the RSU can only use the E certificate. i Submitted to a trusted third party for auxiliary authentication. The x i,1 The subscript indicates the first vehicle V i And the first RSU R1 it passes along its route. i,1,1 Indicates vehicle V i The first timestamp generated during the authentication and key negotiation process with the first RSU R1 it passes through on its driving path. The other subscript symbols are of similar types, each representing the vehicle, the RSU number, and the number of non-subscript symbol subjects, such as the number of Ts and the number of M (messages).

[0097] Next, V i Calculate PE i,1 =h(C i,1 )⊕E i PID i,1 =h(E i ), and calculate α i,1,1 =h(X) i,1 ||C i,1 ||E i ||A i ||T i,1,1 Finally, V i Send message M through the public channel to RSU i,1,1 ={X i,1 PE i,1 PA i ,α i,1,1 ,T i,1,1 (Vehicle authentication request). Without loss of generality, the symbol R1 is defined as V. i The first RSU in the process. Further, upon receiving the message, R1 first checks the timestamp T. i,1,1 Does it exceed the threshold? If it does, the process terminates; otherwise, R1 checks if the message length meets the requirement. If it does, R1 calculates A. i =Dec sk {PA i} and generate a temporary key C i,1 ′=(sk1·A||T i,1,1), where sk1 is R1's private key. Then, R1 calculates E. i =PE i,1 ⊕h(C i,1 ′) and pseudo-identity PID i,1 =h(E i ), and verify the signature α i,1,1 ′=h(X i,1 ||C i,1 ||E i ||A i ||T i,1,1 If true, the integrity of the message has been verified. At this point, R1 calculates the encrypted message PE. i =Enc sk1 {E i ||A i} and message verification code δ i,1,1 =h(ID1||E i ||A i ||T i,1,3 Based on this, the first verification message M is generated. i,1,3 ={ID1,PE i ,δ i,1,1 ,T i,1,3}, and simultaneously send it to TPA for further verification of V. i The identity of the TPA. When the TPA receives M i,1,3 Then, first check the timestamp T. i,1,3 Does it exceed the threshold? If it does, the process terminates; otherwise, TPA uses the first identity ID1 to query the database to obtain the private key sk1 corresponding to R1, and then calculates {E}. i ||A i}=Dec sk1 {PE i Next, TPA verifies equation δ. i,1,1 = h(ID1||E i ||A i ||T i,1,3 Does the condition hold true? If true, TPA calculates {ID}. i ||r i ||T i}=Dec s {E i} and a i ′=h(ID i ||s||r i Then verify A. i ′=a i Does P hold true? If the condition is met, TPA calculates B. i ′=a i ⊕h(ID i And check Bi Does it exist in its own database? Then, TPA calculates δ. i,1,2 =h(ID1||E i ||A i ||sk1||T i ||T i,1,4 ), and send message M i,1,4 ={δ i,1,2 ,T i ,T i,1,4} is sent to R1. Finally, TPA will send {B} i ,ID1} is securely stored in the database to replace the original data {B i Upon receiving message M i,1,4 Then, R1 first checks the timestamp T. i,1,4 Does it exceed the threshold? If it does, the process terminates; otherwise, R1 verifies equation δ. i,1,2 =h(ID1||E i ||A i ||sk1||T i,1,4 Does the condition hold true? If the condition is met, this indicates that V... i It has successfully passed TPA certification. Subsequently, R1 continued with V... i The key is negotiated, and a signature is generated for the next round of authentication. For example, R1 randomly selects a number y. i,1 ∈Z q * And calculate Y i,1 =y i,1 ·P,Hm i,1 =h(A i ||PID i,1 ||ID1||E i ||T i,1,2 ),β i,1 =y i,1 -1 *(Hm i,1 +d1*χ i,1 ), where χ i,1 It is point Y i,1 x-coordinate, y-coordinate i,1 -1 It is y i,1 The inverse element, T i,1,2 This is the current timestamp. Next, calculate the first session key SK. i,1,1 =h(y i,1 ·X i,1 ||PID i,1 ||ID1||C i,1 ′||T i Finally, R1 updates PA. i，1 =Enc sk (Ai ||β i,1 ), calculate α i,1,2 =h(SK i,1,1 ||PA i，1 ||Y i,1 ||T i,1,2 ), and V i Send message M i,1,2 ={Y i,1 PA i，1 ,α i,1,2 ,T i,1,2 Upon receiving message M i,1,2 Afterwards, V i First, check the timestamp T. i,1,2 Has the threshold been exceeded? If it has, the process terminates; otherwise, V i Calculate and update the first session key SK i,1,2 =h(x i,1 ·Y i,1 ||PID i,1 ||ID1||C i,1 ′||T i And verify equation α i,1,2 ′=h(SK i,1,1 ||PA i，1 ||Y i,1 ||h(C i,1 ′)||T i,1,2 This checks whether the signature equality holds true. If it does, then V... i The authentication and key negotiation process with the first RSU (R1) is complete, and both parties can use the updated session key SK. i,1,2 To conduct secure communication. Finally, V i Secure storage {Y i,1 PA i，1} for use in the next round of certification, and securely store {PID} i,1 ID1,T i,1,2} is used as a path record.

[0098] In the second authentication phase, the first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU, including:

[0099] S22: The first vehicle generates a fourth verification message based on a random number, the signature data from the previous round of authentication, and the current timestamp, and sends it to the second RSU via a public channel;

[0100] S23: The second RSU verifies the time and information length of the fourth verification message. If the verification is successful, the validity of the signature data is calculated and verified based on the signature data, the public key of the first vehicle, and the first session key.

[0101] S24: If the verification passes, the second RSU updates the signature data, generates a fifth verification message containing new signature data for the next round of authentication, and sends it to the first vehicle;

[0102] S25: The first vehicle performs time verification on the fifth verification information. If the verification passes, it calculates the second session key based on the fifth verification information and verifies the new signature information in the fifth verification information in combination with the second session key and the fifth verification information. If the verification passes, the new verification information is included for use in the next round of authentication.

[0103] For example, in stage P2, assume vehicle V i The system is entering the jurisdiction of the j-th RSU along the path. If it is the second RSU, this RSU is denoted as R. j The first vehicle carried a signature {Y} i,(j-1) ,β i,(j-1) This is from the previous round of certification from RSU(R) j-1 ) obtained. First, V i Randomly select a number x i,j ∈Z q * Calculate X i,j =x i,j ·P, then calculate the temporary key C i,j =(a i ·(D j +

[0104] h(ID j ||D j )·P pub )||T i,j,1 ), and PE i,j =Ench(C i,j ){E i,j} = Ench(C i,j ){ID j-1 ||E i ||T i,(j-1),2 The pseudo-identity is PID. i,j =PID i,(j-1) ⊕h(E i,j Then calculate: α i,j,1 =h(PID) i,j ||X i,j ||A i ||C i,j ||PE i,j ||Y i,(j-1) ||T i,j,1 Finally, V ivia public channel to R j Send message M i,j,1 ={PID i,j ,X i,j PA i,j PE i,j ,Y i,(j-1) ,α i,j,1 ,T i,j,1 Upon receiving message M i,j,1 After that, R j First, check the timestamp T. i,j,1 Has the threshold been exceeded? If it has, the process terminates; otherwise, R... j Verify message length to determine V i Is this the first time an authentication request has been made? If not, R j Continue implementing the proposed phase P2 plan. j Calculate {A i ||β i,(j-1)}=Decsk{PA i,(j-1)}, Temporary key C i,j′ =(sk j ·A i ||T i,j,1 ),as well as

[0105] E i,j ={ID j-1 ||E i ||T i,(j-1),2}=Dech(C i,j′ ){PE i,j}. If ID j-1 It is R j The true identity of one of the neighbors of RSU, R j Calculate vehicle V i The pseudo-identity PID generated during the previous round of authentication (i.e., round j-1) i,(j-1) =PID i,j ⊕h(E i,j ), and the hash value Hm generated during the previous authentication process. i,(j-1) =h(A i ||PID i,(j-1) ||ID j-1 ||E i ||T i,(j-1),2 Then R j Verify equation (1)(Hm) i,(j-1) *β i,(j-1) -1 )·P+(χ i,(j-1) *β i,(j-1) -1 )·D j-1 =Y i,(j-1)and α i,j,1′ =

[0106] h(PID i,j ||X i,j ||A i ||C i,j ||PE i,j ||Y i,(j-1) ||T i,j,1 Does V hold true? Equation (1) is used to verify V. i Is the provided signature generated by the RSU from the previous round of authentication? If all conditions are met, then V is complete. i Identity authentication and message integrity verification; otherwise, the request terminates. Next, R... j Update V i The signature, which will be used for V i Next round of certification. R j Randomly generate a number y i,j ∈Z q * Calculate Y i,j =y i,j ·P,Hm i,j =h(A i ||PID i,j ||ID j ||E i ||T i,j,2 The signature β generated by the vehicle in round j. i,j =y i,j -1 *(Hm i,j +d j *χ i,j ), where χ i,j It is point Y i,j x-coordinate, d j This is the key used for signing. First session key SK i,j,1 =h(y i,j ·X i,j ||PID i,j ||ID j ||C i,j Finally, R j Update PA i,j =Encsk{A i ||β i,j}, Count signature α i,j,2 =h(SK i,j,1 ||PA i,j ||Y i,j ||h(C i,j ′)||T i,j,2 ), and to V i Send message Mi,j,2 ={Y i,j PA i,j ,α i,j,2 ,T i,j,2 Upon receiving message M i,j,2 Afterwards, V i First, check the timestamp T. i,j,2 Has the threshold been exceeded? If it has, the process terminates; otherwise, V i Calculate session key SK i,j,2 =h(x i,j ·Y i,j ||PID i,j ||ID j ||C i,j And verify whether the following signature equation holds true: α i,j,2 ′=h(SK i,j,1 ||PA i,j ||Y i,j ||h(C i,j ′)||T i,j,2 If true, then V i With R j Once the authentication and key negotiation process is complete, both parties can use the second session key SK. i,j,2 To communicate. Finally, V i {Y i,j PA i,j The PID is securely stored in the on-board unit (OBU) for use in the next round of authentication. i,j ||ID j ||T i,j,2 Securely store the path record.

[0107] Furthermore, the method also includes:

[0108] S26: The second RSU is capable of simultaneously verifying the fourth verification message sent by the first vehicle and at least one fourth verification message sent by the second vehicle.

[0109] For example, in phase P2 of the scheme, the RSU supports batch verification, which can simultaneously verify multiple authentication messages sent by multiple vehicles within a certain time period. Preprocessing is performed before the batch verification process; the RSU first verifies the timestamps of all messages sequentially and rejects authentication requests exceeding a threshold. For the remaining authentication requests, the RSU uses a calculated temporary key C. i,j The data is decrypted to obtain the encrypted information. Finally, the RSU verifies the validity of the signature through batch verification.

[0110] For example, in the first scenario, when a large number of vehicles enter the RSU (R j When within the jurisdiction of ), Rj The authentication request messages from all vehicles are preprocessed, and then their signatures are batch-processed. Assume R... j Regardless of whether these vehicles come from the same RSU, only Hm i,ji *β i,ji -1 Partially execute the batch process, as shown in equation (2):

[0111]

[0112] Among them, D ji R represents ji The public key, and R ji In the previous round, V was completed. i Authentication and signature;

[0113] In the second scenario, in a real-world vehicle-to-everything (IoV) environment, R j The number of neighboring RSUs is finite, therefore R j The certified vehicles may come from several neighboring RSUs, i.e., R ji =R ji′ The situation may apply to vehicle V i and V i′ The batch processing efficiency in equation (2) can be further improved. For vehicles that passed through the same RSU in the previous time step, the processing method is shown in equation (3):

[0114]

[0115] Where n′ represents coming from the same RSU(R r The number of vehicles. Since equation (3) is similar to equation (2), the detailed proof is omitted. In the event of a signature verification failure, a binary search method can be used to quickly locate the signature of the problematic vehicle.

[0116] In another embodiment, the method further includes:

[0117] S27: When the second RSU verifies and determines that the first vehicle has engaged in malicious behavior, it sends the initial authentication result to a trusted third party;

[0118] S28: The trusted third party calculates and determines the first identity of the first vehicle based on the initial authentication result and public parameters;

[0119] S29: When it is determined that the first vehicle has engaged in malicious behavior, the registration information of the first vehicle is revoked, a warning message about the first vehicle is issued, and the communication of the first vehicle is blocked.

[0120] For example, when vehicle Vi When malicious behavior occurs, its credential E i It can be determined by the current RSU(R) j Submitted to TPA. TPA can calculate {ID} using the system private key. i ||r i ||T i}=Dec s (E i (E) i It is ciphertext generated by encrypting vehicle privacy information. Only TPAs ​​with the system private key s can decrypt it to obtain the vehicle privacy information (V). i Real identity ID i Then calculate B i =h(ID) i ||s||r i )+h(ID i This is used to check if the information exists in the database, thereby determining V. i The TPA will verify the vehicle's true identity. If the TPA confirms that the vehicle has committed a violation, it will revoke its current credentials and broadcast a warning message about the credential, thereby preventing other entities from communicating with the vehicle.

[0121] As can be seen from the solutions proposed in the above embodiments, according to stage P1, the first vehicle V i The initial authentication between the roadside unit R1 (the first RSU along the route) needs to be completed with the assistance of a trusted third party, TPA. Temporary key C i,1 V i This is used to verify R1's identity, and R1 then sends the encrypted credential E to TPA. i To verify V i The legitimacy of the identity. Similarly, in subsequent authentication rounds during the usage phase P2, C... i,j V i Used to verify R j V's identity, and V i To R j Provided by RSU(R) from the previous round j-1 The signature generated by R j Used to verify V i The identity of V. The parameters generated throughout this phase include those from V. i R j R j-1 The secret parameters of TPA make it difficult for attackers to effectively forge or tamper with V. i R j The message sent by TPA. Therefore, two-way authentication is implemented in this embodiment.

[0122] Regarding confidentiality, a second session key, SK, is generated after authentication and key negotiation are completed. i,j,2 =

[0123] h(x i,j ·Y i,j ||PID i,j ||ID j ||C i,j ), and by participant V i and R j Know. Attackers can intercept X i,j ,Y i,j ID j These parameters, but the correct SK cannot be determined. i,j,2 The reason is that only participant V... i (or R) j Able to calculate temporary key C i,j and session key x i,j ·Y i,j (or y) i,j ·X i,j Other entities cannot access X. i,j and Y i,j Get x from i,j ,y i,j Unless they can resolve the ECCDH assumptions in probabilistic multinomial time, the scheme in this embodiment ensures the confidentiality of the session key.

[0124] Regarding conditional privacy-preserving, firstly during the registration process, the TPA provides credentials E i Protect V i Real identity ID i In each subsequent round of authentication, a series of modified pseudo-identities are used to ensure security. Even if an attacker guesses the temporary key C... i,j And decrypt PE i,j Obtaining credential E i Attackers also cannot access the system's private key to decrypt E. i Thus obtaining V i His true identity. Only when R... j V provided for TPA i E i Only then can TPA calculate V. i V's true identity. Therefore, V i The true identity is anonymous to any other entity (and even to some extent to TPA itself).

[0125] Regarding traceability: when vehicle V i When you exhibit malicious behavior, you are subject to the current RSU(R) j Submitted to TPA. TPA can calculate V using the following formula. i Real identity ID i :{ID i ||r i ||T i}=Dec s (E i Then calculate: B i =h(ID) i ||s||

[0126] r i )+h(ID i This is to check if this information exists in the database, thereby verifying the ID. i The legitimacy of it.

[0127] For non-linkability, in each round of authentication and key negotiation, the messages sent by the vehicle consist of a timestamp and a random value. This ensures that each intercepted message is unique, thus preventing attackers from associating any message with the same vehicle.

[0128] For perfect forward secrecy, in this scheme, the session key SK i,j,1 =SK i,j,2

[0129] =h(x i,j y i,j ·P||PID i,j ||ID j ||a i sk j ·P), it is through vehicle V i private key a i False identity PID i,j R j private key sk j Identity ID j , and V i and R j Selected random number x i,j ,y i,j It was calculated. Assume vehicle V... i (or R) j Private key a) i (or sk) jThe data was leaked, and communication messages were intercepted from all previous authentication and key negotiations. Due to the difficulty of solving the ECCDH assumption, no attacker with a probabilistic multinomial time capability could obtain X. i,j and Y i,j y is calculated from i,j ·X i,j or x i,j ·Y i,j Therefore, it is impossible to calculate previous session keys. Thus, the scheme in this embodiment achieves complete forward confidentiality.

[0130] For resistance to replay attacks, when R j (or V) i ) Received from V i (or R) j When a message is received, the condition |T will be checked first. cur -T i,j,k The validity of a message is determined by whether |≤ΔT is satisfied. If not, the message is considered expired and the request is rejected. If the condition is satisfied, message integrity is verified via a message authentication code to prevent timestamp tampering. Satisfying both conditions helps the scheme effectively resist replay attacks.

[0131] Regarding resistance to man-in-the-middle (MITM) attacks, messages generated during authentication and key negotiation include information using vehicle V. i (or R) j The secret parameter {ID} i PW i ,a i}(or {d j ,sk j The data is encrypted, along with the message authentication code. Because these secret parameters cannot be obtained by any attacker with probabilistic multinomial time, an attacker cannot forge a legitimate V. i (or R) j The system uses the user's identity information to send valid messages and cannot tamper with the content of valid messages.

[0132] Regarding resistance to privileged insider attacks, even if the TPA suffers an insider attack resulting in database information leakage, the attacker will still be unable to obtain vehicle V information through the leaked information. i The true identity. This is because during the registration phase, TPA only stores parameter B. i Furthermore, due to the one-way nature and collision resistance of hash functions, attackers cannot deduce V. iReal identity ID i .

[0133] like Figure 4 As shown, another embodiment of the present invention also provides a vehicle network privacy protection batch verification system, including:

[0134] A trusted third party is used to generate public parameters using a secure elliptic curve algorithm, and to register the identity of the first vehicle and the first RSU in combination with the public parameters, thereby generating the first identity and the first key corresponding to the first vehicle and the first RSU respectively.

[0135] The first vehicle is used to respond to a vehicle login command, and the first vehicle uses the first identity and the first password for verification;

[0136] The first RSU is used to complete the initial authentication in response to successful verification, in conjunction with the first vehicle, the trusted third party, and the first identity and first key of the first vehicle and the first RSU.

[0137] The second RSU and the first vehicle complete mutual authentication based on the authentication results of the first vehicle and the first RSU.

[0138] In one embodiment, the public parameters include a secure elliptic curve E, a base point P, a curve order q, and a public key P calculated from a private key formed based on random numbers. pub One-way collision-resistant hash function, shared key for RSU.

[0139] In one embodiment, registering the identity of the first vehicle in conjunction with the public parameters includes:

[0140] The first vehicle generates the first identity and the first password based on random numbers and sends them to a trusted third party through a secure channel.

[0141] The trusted third party verifies the first identity and first password of the first vehicle obtained by the third party. If the verification is successful, the third party generates the public key and private key corresponding to the first vehicle based on random number calculation.

[0142] The public key, private key, and public parameters are combined to perform encrypted calculations on the parameters of the first vehicle at the current timestamp, and the calculation results are stored in the target database. At the same time, the calculation results, public key, private key, and current timestamp representing the vehicle login information are sent to the first vehicle through a secure channel.

[0143] The first vehicle performs a hash calculation on the obtained vehicle login information to verify its legitimacy as vehicle login information. If it is legitimate, the hash calculation result is securely stored.

[0144] In one embodiment, registering the identity of the first RSU in conjunction with the public parameters includes:

[0145] The first RSU will send a first identity generated based on a random number to a trusted third party through a secure channel for registration;

[0146] When the trusted third party determines that the first identity is legitimate, it generates a signing key and a signing public key for the first RSU based on a random number, and simultaneously calculates and generates a private key for the first RSU based on the signing key, the signing public key, and the first identity.

[0147] The trusted third party stores the first identity of the first RSU and the private key of the first RSU, and sends the signing key, signing public key, private key of the first RSU, and shared key of the RSU to the first RSU through a secure channel;

[0148] The first RSU stores the signing key, the signing public key, the first RSU's private key, and the RSU's shared key, and publishes its first identity and signing public key to nearby vehicles and RSUs.

[0149] In one embodiment, the first vehicle verifies the first identity and the first key, including:

[0150] The on-board unit of the first vehicle decrypts the vehicle login information based on the second identity and password, and performs a hash calculation based on the vehicle login information to verify the legitimacy of the vehicle login information.

[0151] In one embodiment, the first RSU is the first RSU along the route of the first vehicle. The first vehicle and the first RSU, combined with the first identity and first key of the first vehicle and the first RSU, simultaneously complete initial authentication with each other using the trusted third party, including:

[0152] The first vehicle calculates and generates a vehicle verification request based on the first identity, the encrypted public key, the encrypted private key, the current timestamp, and the temporary key generated by the random number, and sends it to the first RSU;

[0153] The first RSU verifies the vehicle verification request in terms of time and information length;

[0154] If the verification is successful, the first RSU verifies the integrity of the information in the vehicle verification request based on the data in the vehicle verification request and the private key of the first RSU. If the verification is successful, the first verification message is generated by combining the current timestamp and the vehicle verification request and sent to a trusted third party.

[0155] The trusted third party verifies the time of the first verification message. If the verification is successful, the private key of the first RSU is determined based on the first identity in the first verification message, and the private key of the first RSU is used to assist in the execution of the data verification process in the first verification message.

[0156] If the verification passes, the trusted third party combines the current timestamp and the first verification message to generate a second verification message and sends it to the first RSU.

[0157] The first RSU verifies the time of the second verification message. If the verification passes, it verifies the reasonableness of the data in the second verification message. If the verification passes, it negotiates with the public and private keys of the first vehicle to determine the signature information to be used for the next round of authentication.

[0158] The first RSU generates a third verification message based on the signature information and the current timestamp, and sends it to the first vehicle;

[0159] The first vehicle verifies the time and data validity of the third verification message. If the verification passes, it calculates and generates a first session key based on the information in the third verification message and stores the signature data in the third verification message for use in the next round of authentication.

[0160] In one embodiment, the first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU, including:

[0161] The first vehicle generates a fourth verification message based on a random number, the signature data from the previous round of authentication, and the current timestamp, and sends it to the second RSU via a public channel;

[0162] The second RSU verifies the time and information length of the fourth verification message. If the verification is successful, the validity of the signature data is calculated and verified based on the signature data, the public key of the first vehicle, and the first session key.

[0163] If the verification passes, the second RSU updates the signature data, generates a fifth verification message containing new signature data for the next round of authentication, and sends it to the first vehicle;

[0164] The first vehicle performs time verification on the fifth verification information. If the verification passes, it calculates the second session key based on the fifth verification information and verifies the new signature information in the fifth verification information in combination with the second session key and the fifth verification information. If the verification passes, the new verification information is included for use in the next round of authentication.

[0165] In one embodiment, the second RSU is capable of simultaneously verifying the fourth verification message sent by the first vehicle and at least one fourth verification message sent by the second vehicle.

[0166] In one embodiment, when the second RSU verifies and determines that the first vehicle has engaged in malicious behavior, it sends the initial authentication result to a trusted third party; the trusted third party calculates and determines the first identity of the first vehicle based on the initial authentication result and public parameters; when it is determined that the first vehicle has engaged in malicious behavior, it revokes the registration information of the first vehicle, publishes warning information about the first vehicle, and blocks the communication of the first vehicle.

[0167] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of protection of this application is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of one or more embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0168] One or more embodiments in this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments in this application should be included within the protection scope of this application.

Claims

1. A batch verification method for privacy protection in vehicle networking, characterized in that, include: A trusted third party uses the secure elliptic curve algorithm to generate public parameters, and combines the public parameters to register the identity of the first vehicle and the first RSU, thereby generating the first identity and first key corresponding to the first vehicle and the first RSU respectively. In response to a vehicle login command, the first vehicle uses the first identity and the first key for verification. In response to successful verification, the first vehicle and the first RSU combine the first identity and the first key of the first vehicle and the first RSU, and simultaneously use the trusted third party to complete the initial authentication with each other. The first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU; The first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU, including: The first vehicle generates a fourth verification message based on a random number, the signature data from the previous round of authentication, and the current timestamp, and sends it to the second RSU via a public channel; The second RSU verifies the time and information length of the fourth verification message. If the verification passes, it calculates and verifies the validity of the signature data based on the signature data, the public key of the first vehicle, and the first session key. If the verification passes, the second RSU updates the signature data, generates a fifth verification message containing new signature data for the next round of authentication, and sends it to the first vehicle; The first vehicle performs time verification on the fifth verification message. If the verification passes, it calculates the second session key based on the fifth verification message and verifies the new signature data in the fifth verification message in combination with the second session key and the fifth verification message. If the verification passes, the new verification information is saved for the next round of authentication.

2. The batch verification method for privacy protection in the Internet of Vehicles according to claim 1, characterized in that, The public parameters include the secure elliptic curve E, the base point P, the curve order q, and the public key P calculated from the private key formed based on random numbers. pub One-way collision-resistant hash function, shared key for RSU.

3. The batch verification method for privacy protection in the Internet of Vehicles according to claim 2, characterized in that, The first vehicle is registered using the aforementioned public parameters, including: The first vehicle generates the first identity and the first password based on random numbers and sends them to a trusted third party through a secure channel. The trusted third party verifies the first identity and first password of the first vehicle obtained by the third party. If the verification is successful, the third party generates the public key and private key corresponding to the first vehicle based on random number calculation. The public key, private key, and public parameters are combined to perform encrypted calculations on the parameters of the first vehicle at the current timestamp, and the calculation results are stored in the target database. At the same time, the calculation results, public key, private key, and current timestamp representing the vehicle login information are sent to the first vehicle through a secure channel. The first vehicle performs a hash calculation on the obtained vehicle login information to verify its legitimacy as vehicle login information. If it is legitimate, the hash calculation result is securely stored.

4. The batch verification method for privacy protection in the Internet of Vehicles according to claim 3, characterized in that, The first RSU is registered using the aforementioned public parameters, including: The first RSU will send a first identity generated based on a random number to a trusted third party through a secure channel for registration; When the trusted third party determines that the first identity is legitimate, it generates a signing key and a signing public key for the first RSU based on a random number, and simultaneously calculates and generates a private key for the first RSU based on the signing key, the signing public key, and the first identity. The trusted third party stores the first identity of the first RSU and the private key of the first RSU, and sends the signing key, signing public key, private key of the first RSU, and shared key of the RSU to the first RSU through a secure channel; The first RSU stores the signing key, the signing public key, the first RSU's private key, and the RSU's shared key, and publishes its first identity and signing public key to nearby vehicles and RSUs.

5. The batch verification method for privacy protection in the Internet of Vehicles according to claim 3, characterized in that, The first vehicle verifies the first identity and the first key, including: The on-board unit of the first vehicle decrypts the vehicle login information based on the first identity and password, and performs a hash calculation based on the vehicle login information to verify the legitimacy of the vehicle login information.

6. The batch verification method for privacy protection in the Internet of Vehicles according to claim 4, characterized in that, The first RSU is the first RSU along the route of the first vehicle. The first vehicle and the first RSU, combined with the first identity and first key of the first vehicle and the first RSU, simultaneously complete initial authentication with each other using the trusted third party, including: The first vehicle calculates and generates a vehicle verification request based on the first identity, the encrypted public key, the encrypted private key, the current timestamp, and the temporary key generated by the random number, and sends it to the first RSU; The first RSU verifies the vehicle verification request in terms of time and information length; If the verification is successful, the first RSU verifies the integrity of the information in the vehicle verification request based on the data in the vehicle verification request and the private key of the first RSU. If the verification is successful, the first verification message is generated by combining the current timestamp and the vehicle verification request and sent to a trusted third party. The trusted third party verifies the time of the first verification message. If the verification is successful, the private key of the first RSU is determined based on the first identity in the first verification message, and the private key of the first RSU is used to assist in the execution of the data verification process in the first verification message. If the verification passes, the trusted third party combines the current timestamp and the first verification message to generate a second verification message and sends it to the first RSU. The first RSU verifies the time of the second verification message. If the verification passes, it verifies the reasonableness of the data in the second verification message. If the verification passes, it negotiates with the public and private keys of the first vehicle to determine the signature information to be used for the next round of authentication. The first RSU generates a third verification message based on the signature information and the current timestamp, and sends it to the first vehicle; The first vehicle verifies the time and data validity of the third verification message. If the verification passes, it calculates and generates a first session key based on the information in the third verification message and stores the signature data in the third verification message for use in the next round of authentication.

7. The batch verification method for privacy protection in the Internet of Vehicles according to claim 1, characterized in that, The method further includes: The second RSU is capable of simultaneously verifying the fourth verification message sent by the first vehicle and at least one fourth verification message sent by the second vehicle.

8. The batch verification method for privacy protection in the Internet of Vehicles according to claim 1, characterized in that, The method further includes: When the second RSU verifies and determines that the first vehicle has engaged in malicious behavior, it will send the initial authentication result to a trusted third party. The trusted third party calculates and determines the first identity of the first vehicle based on the initial authentication result and public parameters. Upon determining that the first vehicle has engaged in malicious behavior, the registration information of the first vehicle is revoked, a warning message about the first vehicle is issued, and the communication of the first vehicle is blocked.

9. A batch verification system for privacy protection in the Internet of Vehicles, characterized in that, include: A trusted third party is used to generate public parameters using a secure elliptic curve algorithm, and to register the identity of the first vehicle and the first RSU in combination with the public parameters, thereby generating the first identity and the first key corresponding to the first vehicle and the first RSU respectively. The first vehicle is used to respond to a vehicle login command, and the first vehicle uses the first identity and the first key for verification; The first RSU is used to complete the initial authentication in response to successful verification, in conjunction with the first vehicle, the trusted third party, and the first identity and first key of the first vehicle and the first RSU. The second RSU and the first vehicle complete mutual authentication based on the authentication results of the first vehicle and the first RSU; The first vehicle and the second RSU complete mutual authentication based on the authentication results of the first vehicle and the first RSU, including: The first vehicle generates a fourth verification message based on a random number, the signature data from the previous round of authentication, and the current timestamp, and sends it to the second RSU via a public channel; The second RSU verifies the time and information length of the fourth verification message. If the verification passes, it calculates and verifies the validity of the signature data based on the signature data, the public key of the first vehicle, and the first session key. If the verification passes, the second RSU updates the signature data, generates a fifth verification message containing new signature data for the next round of authentication, and sends it to the first vehicle; The first vehicle performs time verification on the fifth verification message. If the verification passes, it calculates the second session key based on the fifth verification message and verifies the new signature data in the fifth verification message in combination with the second session key and the fifth verification message. If the verification passes, the new verification information is saved for the next round of authentication.

Images