A signature-based efficient batch authentication key agreement method for internet of vehicles

Abstract

The present application relates to the field of authentication key agreement in Internet of Vehicles, in particular to a signature-based efficient batch authentication key agreement method for Internet of Vehicles, comprising constructing an Internet of Vehicles system comprising three entities of TA, roadside unit and vehicle; the vehicle and roadside unit apply for identity registration to the TA, and if the identity registration is successful, the TA assigns corresponding identity authentication key parameters; when the vehicle drives into the coverage range of the roadside unit, the vehicle user first logs in the vehicle for authentication, and if the authentication is successful, the vehicle initiates an authentication request to the roadside unit, the roadside unit performs identity authentication on the vehicle, and if the authentication is successful, the roadside unit sends negotiation information to the vehicle, the vehicle performs mutual authentication on the roadside unit and calculates a session key according to the negotiation information to complete key agreement; when a malicious attacker sends false information, identity tracing and revocation processing are performed on the malicious attacker; the present application can improve authentication efficiency while ensuring the privacy and security of communication entities.

Description

Technical Field

[0001] This invention relates to the field of authentication key negotiation in the Internet of Vehicles (IoV), and particularly to a signature-based method for efficient batch authentication key negotiation in IoV. Background Technology

[0002] The Internet of Vehicles (IoV) can be defined as an open, integrated network system composed of multiple vehicles, users, things, and networks, possessing high controllability, manageability, and trustworthiness. The emergence of IoV has reduced social costs and improved traffic efficiency and safety. However, because IoV utilizes multiple communication methods, all conducted on open communication channels, it is vulnerable to attacks from malicious nodes, potentially leading to leaks of driver privacy or even endangering the lives and property of drivers and passengers.

[0003] Authentication key negotiation protocols, as a communication privacy and security protection technology, help communicating parties complete identity authentication while negotiating a session key, ensuring secure communication. However, in high-density vehicular network environments, the RSU may sometimes receive 1000-2000 authentication messages per second within its communication range. The traditional scheme where the RSU authenticates individual vehicles sequentially results in excessively long response times for vehicle nodes submitting authentication requests later, failing to meet the real-time service requirements of vehicular networks. To address this issue, identity-based batch authentication schemes and trusted center-based message authentication schemes have emerged. In identity-based batch authentication schemes, regardless of the number of messages received per second, only bilinear pairing and elliptic curve multiplication operations are required, resulting in lower communication latency and message drop rate. In trusted center-based message authentication schemes, messages sent by vehicle nodes are confirmed by the RSU. Once the RSU completes message authentication, the authentication details of each confirmation message are consistently disclosed, reducing message latency to some extent. While these schemes reduce message latency to some extent, their authentication efficiency remains low, and they do not fully consider the issue of session key negotiation after identity authentication, nor do they adequately address security issues such as vehicle node identity traceability. Summary of the Invention

[0004] To address the above problems, this invention provides a signature-based method for efficient batch authentication key negotiation in vehicle-to-everything (V2X) networks, comprising the following steps:

[0005] S1. Construct a vehicle-to-everything (V2X) system that includes three entities: TA (Transportation Controller), roadside units, and vehicles. Initialize the V2X system and generate common parameters.

[0006] S2. Vehicles and roadside units apply for identity registration with TA offline through reliable channels. If the identity registration is successful, TA assigns the corresponding key authentication parameters and backs them up.

[0007] S3. When a vehicle enters the coverage area of ​​a roadside unit, if the vehicle user requests media services from the roadside unit, the vehicle will first perform login authentication. If the authentication is successful, proceed to step S4; otherwise, access will be denied.

[0008] S4. The vehicle initiates an authentication request to the roadside unit. The roadside unit authenticates the vehicle's identity. If the authentication is successful, proceed to step S5; otherwise, reject the vehicle's authentication request.

[0009] S5. The roadside unit sends negotiation information to the vehicle, and the vehicle performs mutual authentication with the roadside unit. If the authentication is successful, the vehicle calculates the session key based on the negotiation information to complete the key negotiation; otherwise, the request fails.

[0010] S6. When it is discovered that a malicious attacker is sending false information, the malicious attacker's identity will be traced and their status revoked.

[0011] Further, step S1 involves initializing the vehicle-to-everything (V2X) system and generating common parameters, including:

[0012] TA chooses two large prime numbers p and q, where p is 512 bits and q is 160 bits, and q satisfies q|(p-1);

[0013] TA selects two different random numbers and Each is used as its own master key and private key, and the private key s is calculated. TA The corresponding public key ,in = P is a generating point of the p-order multiplicative group G;

[0014] TA selects a random number Calculation parameters , where g is a semigroup Generators;

[0015] TA selects two collision-resistant one-way hash functions In this case, both one-way hash functions take binary sequences of arbitrary length as input and output sequences of length 1. binary sequence;

[0016] Finally, the common parameters are obtained. And made public.

[0017] Furthermore, the vehicle-to-everything (V2X) system includes multiple vehicles, denoted by N, with each vehicle corresponding to one vehicle user, where V is the number of vehicles.i The process of obtaining key authentication parameters for identity registration for i=1,2,…,N is as follows:

[0018] S201. Vehicle User U i Set your user identity And the corresponding login password PW i And select a random number α i ;

[0019] S202. Vehicle V i According to identity And login password PW i calculate Then combine with random number α i calculate Then generate registration request information. Send to TA; where H1 is a one-way hash function. It is a vehicle Its unique and true identity, also known as vehicle identity;

[0020] S203.TA receives vehicle V i Registration request information sent And check the vehicle identity database T VID Does vehicle V exist in the middle? i identity information If it exists, the registration application is rejected; otherwise, proceed to step S204; where s is the master key of TA and H0 is a one-way hash function.

[0021] S204.TA selects a random number d i Calculate vehicle V i private key Combined with s i calculate ;TA selects random numbers calculate And according to the calculation formula Get ;TA will collect Send to all roadside units registered with TA identity, and set Transmitted to vehicle V i In the installed Trusted Platform module, the final TA will collect... Save to vehicle identity database T VID In the middle; where g is a semigroup The generators are p and q, which are large prime numbers, and params are common parameters.

[0022] S205. Vehicle V i Receive set And according to Ai Calculate the TA assigned to vehicle V i private key Simultaneously calculate , Then the vehicle use replace Will Save the information to the vehicle's OBU to complete the identity registration.

[0023] Furthermore, the vehicle-to-everything (V2X) system includes multiple roadside units, denoted by M, which represents the total number of roadside units (RSUs). j The process of obtaining key authentication parameters for identity registration for j=1,2,…,M is as follows:

[0024] S211 Roadside Unit (RSU) j Choose your unique real identity, RID j And select a random number. calculate Registration request information is transmitted through a trusted channel. Submit to TA;

[0025] S212.TA receives roadside unit (RSU) j Send the registration request information and check the roadside unit identity database T. RID Does the roadside unit (RSU) exist? j identity information If it exists, the registration application is rejected; otherwise, proceed to step S213; where s is the master key of TA and H0 is a one-way hash function.

[0026] S213.TA selects a random number. calculate Combined with W j calculate Then the set Transmitted to Roadside Unit (RSU) j and the set Stored in the roadside unit identity database T RID middle;

[0027] S214 Roadside Unit (RSU) j Receive the set sent by TA Calculate your own private key and public key And save it.

[0028] Furthermore, when vehicle V i Drive into the roadside unit RSU j When covering the area, if its vehicle user U iRoadside Unit (RSU) j Requesting access to media services, vehicle V i First, you need to complete login authentication, including:

[0029] S31. Vehicle User U i To vehicle V i Enter your user identity And login password PW i Vehicle V i Calculate based on input information and Where H1 is a one-way hash function;

[0030] S32. Determine if there is an equality. If true, then vehicle V i I have registered my identity with TA, vehicle user U i If the user is a legitimate user, then vehicle user U is considered a legitimate user. i Login failed.

[0031] Furthermore, in step S4, vehicle V i Roadside Unit (RSU) j The process of initiating an authentication request includes:

[0032] S401. Vehicle V i Select the current timestamp calculate And select a random number. calculate ;

[0033] S402. Vehicle V i According to parameters and calculate Generate authentication request Send to roadside unit (RSU) j .

[0034] Furthermore, roadside units (RSUs) j Receive vehicle authentication requests and perform identity authentication, including:

[0035] S411. If the roadside unit RSU j At the current timestamp TR j If only one vehicle authentication request is received, proceed to step S412. If the roadside unit (RSU) is... j At the current timestamp TR j If authentication requests for two or more vehicles are received, proceed to step S415.

[0036] S412 Roadside Unit (RSU) j Receiving vehicle Vi authentication request And determine whether the timestamp is valid. ,in, Minimum time limit; if not met, vehicle V is rejected. i If the authentication request is satisfied, proceed to step S413;

[0037] S413. Based on the authentication request Perform XOR operation calculation Obtain identity information Roadside Unit (RSU) j Query vehicle identity database Does vehicle V exist in the middle? i identity information If it does not exist, then vehicle V is rejected. i If an authentication request exists, proceed to step S414;

[0038] S414. Determine if there are equalities Is it valid? If not, reject vehicle V. i The authentication request is submitted; if successful, the identity authentication is completed, and the Roadside Unit (RSU) is activated. j Select random number calculate , and Finally, the roadside unit Select the current timestamp Negotiation information Return to vehicle V i ;

[0039] S415 Roadside Unit (RSU) j Receiving vehicles authentication request And determine whether each authentication request meets the timestamp validity condition, obtain all vehicles that meet the timestamp validity condition and execute step S416;

[0040] S416 Roadside Unit (RSU) j Calculate and query the vehicle identity database If vehicle identification information is found, obtain all vehicles with identification information and execute step S417;

[0041] S417 Roadside Unit (RSU) j Judgment Equation Whether it is true or not, among which, This indicates that among n vehicles, those meeting the timestamp validity condition and listed in the vehicle identity database... The system determines the number of vehicles with valid identity information; if this is not the case, all vehicle authentication requests are rejected; if it is valid, the corresponding negotiation information is calculated and returned.

[0042] Furthermore, the vehicles receive negotiation information returned by the roadside unit and perform mutual authentication, including:

[0043] S51. Vehicle V i Receiver Roadside Unit (RSU) j Returned negotiation information Determine if the second timestamp condition is met. If not, then vehicle V... i Roadside Unit (RSU) j Mutual authentication fails; if satisfied, proceed to step S52.

[0044] S52. Calculate based on negotiated information , And determine the equation. If the condition is not met, then vehicle V... i With roadside unit RSU j Mutual authentication failed; if successful, vehicle V... i With roadside unit RSU j Mutual authentication successful, calculate temporary session key. Complete key negotiation.

[0045] Furthermore, if a vehicle registered through identity verification V i Turn into a malicious attacker in the roadside unit RSU j Sending false information within its coverage area, roadside unit (RSU) j Identification and revocation of malicious attackers include:

[0046] S61. Roadside Unit (RSU) j Detect malicious attacker V i The parameter r used for authentication i and in the vehicle identity database Searching for parameter r i Corresponding identity information ;

[0047] S62. Roadside Unit (RSU) j identity information Send to TA and in the vehicle identity database Delete identity information and related data;

[0048] S63.TA in vehicle identity database T VID Retrieving identity information The corresponding random number k i, random number k i Modified to ;

[0049] S64. Based on the modified random number The parameters were recalculated. And send it to all roadside units that have registered with TA through their identities, each roadside unit will have the vehicle identity database Chinese identity information The corresponding parameter r i Modified to After TA's actions, the malicious attacker V... i You will not have a legitimate identity in the system and will be unable to pass. The identity verification process completes the tracing and revocation of the legitimate identity of malicious vehicles.

[0050] The beneficial effects of this invention are:

[0051] This invention considers constructing a system model using three entities: TA, RSU, and vehicle. Addressing the issue that multiple vehicle requests in traditional one-to-one authentication key negotiation schemes can place enormous authentication pressure on the RSU, and the problem of malicious vehicle attacks affecting the security of vehicle-to-everything (V2X) communication, this invention proposes a signature-based, efficient batch authentication key negotiation protocol.

[0052] This invention presents a signature-based high-efficiency batch authentication key negotiation protocol, which, compared to existing batch authentication schemes based on bilinear pairing operations, is more suitable for scenarios with high computational overhead and high latency requirements. It also improves authentication efficiency and enhances the vehicle network's defense capabilities against various malicious node attack methods. Attached Figure Description

[0053] Figure 1 This is a flowchart of the signature-based high-efficiency batch authentication key negotiation protocol of the present invention;

[0054] Figure 2 This is a system model diagram of the bulk authentication key negotiation protocol in an embodiment of the present invention;

[0055] Figure 3 This is a schematic diagram of the batch authentication key negotiation protocol in an embodiment of the present invention. Detailed Implementation

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

[0057] This invention provides a signature-based, efficient batch authentication key negotiation method for vehicle-to-everything (V2X) systems. This method constructs a V2X system involving three entities: a Trusted Authority (TA), Roadside Units (RSUs), and moving vehicles. Roadside Units and moving vehicles need to register with the TA before participating in the Internet of Vehicles (IoV). The TA, as a trusted authority, issues and backs up corresponding authentication key parameters for each vehicle and Roadside Unit. Furthermore, in the event of illegal vehicle behavior, the TA can use the vehicle's authentication key parameters to trace the vehicle's true identity, protecting the communication security of the V2X. When multiple vehicles initiate authentication requests, the RSU first determines the timeliness of each request and then performs batch authentication on multiple vehicles that meet the criteria.

[0058] In one embodiment, considering the communication security requirements in an IoV context, the following measures were formulated: Figure 2 The vehicle-to-everything (V2X) system model shown includes:

[0059] The TA (Transportation Authority) is a fully trusted entity with powerful computing and storage capabilities, typically handled by government transportation departments. In the vehicle-to-everything (V2X) system, the TA is responsible for registering all vehicles and roadside units. After successful registration, roadside units and vehicles receive a registered identity assigned by the TA. When a malicious vehicle publishes false information, the TA can trace the vehicle's true identity using the authentication parameters assigned during registration, and then implement appropriate punitive measures.

[0060] A roadside unit (Roadside Unit) is a semi-trusted entity that communicates with the TA (Traffic Agent) via wired communication and with the vehicle via wireless communication. The Roadside Unit has limited coverage and can only communicate with vehicles within its coverage area. In a vehicle-to-everything (V2X) system, the Roadside Unit is responsible for sending location-based information to authenticated vehicles that are within its coverage area.

[0061] Vehicles are the main operating entities in the vehicle-to-everything (V2X) system. In the V2X system, each vehicle is equipped with an On-Board Unit (OBU). The OBU is responsible for wireless communication with other vehicles or roadside units. At the same time, each OBU has basic computing and storage capabilities.

[0062] Specifically, the method proposed in this invention is as follows: Figure 1 As shown, it includes the following steps:

[0063] S1. Construct a vehicle-to-everything (V2X) system that includes three entities: TA (Transportation Controller), roadside units, and vehicles. Initialize the V2X system and generate common parameters.

[0064] Specifically, the initialization of a vehicle-to-everything (V2X) system mainly includes the following processes:

[0065] TA chooses two large prime numbers p and q, where p is 512 bits and q is 160 bits, and q satisfies q|(p-1);

[0066] TA selects two different random numbers and Each is used as its own master key and private key, and the private key s is calculated. TA The corresponding public key ,in = P is a generating point of the p-order multiplicative group G;

[0067] TA selects a random number Calculation parameters , where g is a semigroup Generators;

[0068] TA selects two collision-resistant one-way hash functions In this case, both one-way hash functions take binary sequences of arbitrary length as input and output sequences of length 1. binary sequence;

[0069] Finally, the common parameters are obtained. And made public.

[0070] S2. Vehicles and roadside units apply for identity registration with TA offline through reliable channels. If the identity registration is successful, TA assigns the corresponding key authentication parameters and backs them up.

[0071] Specifically, the vehicle-to-everything (V2X) system contains multiple moving vehicles. In this embodiment, it is assumed that there are N vehicles in the V2X system, and each vehicle corresponds to one vehicle user; any vehicle V i The identity registration process for i=1,2,…,N is as follows:

[0072] S201. Vehicle User U i Set your user identity And the corresponding login password PW i And select a random number α i ;

[0073] S202. Vehicle V i Based on user identity And login password PW i calculate Then combine with random number α i calculate Then generate registration request information. Send to TA; where H1 is a one-way hash function. It is a vehicle Its unique and true identity, also known as vehicle identity;

[0074] S203.TA receives vehicle V i Registration request information sent And check the vehicle identity database T VID Does vehicle V exist in the middle? i identity information If it exists, then reject vehicle V. i If the registration application is not accepted, proceed to step S204; where s is the master key of TA and H0 is a one-way hash function.

[0075] S204.TA selects a random number d i Calculate vehicle V i private key Combined with s i calculate ;TA selects random numbers calculate And according to the calculation formula Get ;TA will collect Send to all roadside units registered with TA identity, and set up Transmitted to vehicle V i In the installed Trusted Platform module, TA will finally collect... Save to vehicle identity database T VID In the middle; where g is a semigroup The generators are p and q, which are large prime numbers, and params are common parameters.

[0076] S205. Vehicle V i Receive set And according to A i Calculate the TA assigned to vehicle V i private key Simultaneously calculate , Then the vehicle use replace Will Save the information to the vehicle's OBU to complete the identity registration.

[0077] In step S205, because TA returns to vehicle V i The set does not include vehicle V. i private key i Therefore, vehicle V i You need to deduce the private key s yourself based on the set. iBecause TA calculates the vehicle V i private key i satisfy And vehicle V i Know UPW i A i and α i ,and Then it can be determined by the XOR operation. Derive vehicle V i private key i The reason why the TA does not directly send the private key to the vehicle, but instead uses this self-derived method, is to prevent information from being intercepted and stolen by malicious nodes during transmission, thus preventing the leakage of critical content.

[0078] Specifically, the vehicle-to-everything (V2X) system includes multiple roadside units (RSUs). Assuming there are M roadside units in total, any one of these RSUs... j The identity registration process for j=1,2,…,M is as follows:

[0079] S211 Roadside Unit (RSU) j Choose your unique real identity, RID j And select a random number. calculate Registration request information is transmitted through a trusted channel. Submit to TA;

[0080] S212.TA receives roadside unit (RSU) j Send the registration request information and check the roadside unit identity database T. RID Does the roadside unit (RSU) exist? j identity information If it exists, the registration application is rejected; otherwise, proceed to step S213; where s is the master key of TA and H0 is a one-way hash function.

[0081] S213.TA selects a random number. calculate Combined with W j calculate Then the set Transmitted to Roadside Unit (RSU) j and the set Stored in the roadside unit identity database T RID middle;

[0082] S214 Roadside Unit (RSU) j Receive the set sent by TA Calculate your own private key and public key ,save and , The entire registration process was then completed.

[0083] S3. When a vehicle enters the coverage area of ​​a roadside unit, if the vehicle user wants to access media services through the roadside unit, the vehicle will first perform login authentication. If the authentication is successful, proceed to step S4; otherwise, access will be denied.

[0084] Specifically, when vehicle V i Drive into the roadside unit RSU j When covering the area, if its vehicle user U i Roadside Unit (RSU) j To request access to media services, you must first contact vehicle V. i Login authentication includes:

[0085] S31. Vehicle User U i To vehicle V i Enter your user identity And login password PW i Vehicle V i Calculate based on input information and Where H1 is a one-way hash function;

[0086] S32. Determine if there is an equality. If true, then vehicle V i I have registered my identity with TA, vehicle user U i If the user is a legitimate user, then vehicle user U is considered a legitimate user. i Login failed.

[0087] S4. The vehicle initiates an authentication request to the roadside unit. The roadside unit authenticates the vehicle's identity. If the authentication is successful, proceed to step S5; otherwise, reject the vehicle's authentication request.

[0088] Specifically, vehicle V i After completing login authentication, send the information to the roadside unit (RSU). j Initiating an authentication request includes:

[0089] S401. Vehicle V i Based on the current timestamp calculate And select a random number. calculate ; Set the current timestamp Vehicle V i The vehicle that initiated the authentication request sends a timestamp;

[0090] S402. Vehicle V i Extract the random number k obtained when you registered your identity with TA.i Based on the random number k i calculate and Finally, an authentication request is generated. Send to roadside unit (RSU) j .

[0091] Specifically, roadside unit (RSU) j Receive vehicle authentication requests and perform identity authentication, including:

[0092] S411. If the roadside unit RSU j At the current timestamp TR j If only one vehicle authentication request is received, proceed to step S412. If the roadside unit (RSU) is... j At the current timestamp TR j If authentication requests are received from two or more vehicles, proceed to step S415; change the current timestamp TR. j Designated as Roadside Unit (RSU) j RSU reception timestamp for receiving authentication request;

[0093] S412 Roadside Unit (RSU) j Receiving vehicle V i authentication request And determine whether the timestamp is valid. ,in, Minimum time limit; if not met, vehicle V is rejected. i If the authentication request is satisfied, proceed to step S413;

[0094] S413. Based on the authentication request calculate Obtain identity information Roadside Unit (RSU) j Check vehicle identity database Does vehicle V exist in the middle? i identity information If it does not exist, then vehicle V is rejected. i If an authentication request exists, proceed to step S414;

[0095] S414. Determine if there are equalities Is it valid? If not, reject vehicle V. i The authentication request is submitted; if successful, the identity authentication is completed, and the Roadside Unit (RSU) is activated. j Select random number calculate , and and subsequent temporary session keys ; Last roadside unit Select the current timestamp Negotiation information Return to vehicle V i ;

[0096] S415 Roadside Unit (RSU) j Receiving vehicles authentication request And determine whether each authentication request meets the timestamp validity condition, obtain all vehicles that meet the timestamp validity condition and execute step S416;

[0097] S416 Roadside Unit (RSU) j Calculate and check the vehicle identity database If vehicle identification information is found, obtain all vehicles with identification information and execute step S417;

[0098] S417 Roadside Unit (RSU) j Judgment Equation Whether it is true or not, among which, This indicates that among n vehicles, those meeting the timestamp validity condition and listed in the vehicle identity database... The system determines the number of vehicles with valid identity information; if this is not the case, all vehicle authentication requests are rejected; if it is valid, the corresponding negotiation information is calculated and returned.

[0099] S5. The roadside unit sends negotiation information to the vehicle, and the vehicle performs mutual authentication with the roadside unit. If the authentication is successful, the vehicle calculates the session key based on the negotiation information to complete the key negotiation; otherwise, the request fails.

[0100] Specifically, the vehicles receive negotiation information returned by the roadside unit and perform mutual authentication, including:

[0101] S51. Vehicle V i Receiver Roadside Unit (RSU) j Returned negotiation information Determine whether the second timestamp condition is met. If the conditions are not met, then vehicle V i With roadside unit RSU j Mutual authentication fails; if successful, proceed to step S52. For vehicle V i The timestamp of receiving the negotiation information. Roadside Unit (RSU) j The timestamp of the returned negotiation information;

[0102] S52. Calculate based on negotiated information , And determine the equation. If the condition is not met, then vehicle V... i With roadside unit RSU j Mutual authentication failed; if successful, vehicle V... i With roadside unit RSU j Mutual authentication successful, calculate session key. Complete key negotiation.

[0103] S6. When it is discovered that a malicious attacker is sending false information, the malicious attacker's identity will be traced and their status revoked.

[0104] Specifically, if a malicious attacker is at the roadside unit (RSU) j Sending false information within its coverage area, roadside unit (RSU) j The system will first verify the attacker's identity. If the malicious attacker is a vehicle that has not been registered, the attacker will fail the identity verification and will be unable to spread messages in the vehicle network.

[0105] Specifically, if a vehicle registered through identity V i Turn into a malicious attacker in the roadside unit RSU j Sending false information within its coverage area, roadside unit (RSU) j Identification and revocation of malicious attackers include:

[0106] S61. Roadside Unit (RSU) j Detect malicious attacker V i The parameter r used for authentication i and in the vehicle identity database Searching for parameter r i Corresponding identity information ;

[0107] S62. Roadside Unit (RSU) j identity information Send to TA and in the vehicle identity database Delete identity information and related data;

[0108] S63.TA in vehicle identity database T VID Retrieving identity information The corresponding random number k i , random number k i Modified to ;

[0109] S64. Based on the modified random number The parameters were recalculated. And send it to all roadside units that have registered with TA through their identities, each roadside unit will have the vehicle identity database Chinese identity information The corresponding parameter r i Modified to After TA's actions, the malicious attacker V... i You will not have a legitimate identity in the system and will be unable to pass. The identity verification process completes the tracing and revocation of the legitimate identity of malicious vehicles.

[0110] Specifically, the roadside unit identity database T RID This refers to the library stored at TA (Transportation Target) used to verify the identity information of roadside units; the vehicle identity library T. VID It refers to the database stored at the TA (Transfer Agent) used to verify vehicle identity information, while the vehicle identity database... This means that after a vehicle completes registration at the TA (Traffic Agent), the TA sends the vehicle information to the roadside unit, which then stores it locally in a database used to verify the vehicle's identity and determine whether the current vehicle authentication request is approved. Essentially, it is a local database of the roadside unit itself, so the roadside unit does not need to frequently send requests to the TA to verify the vehicle's identity.

[0111] In one embodiment, the semantic safety of the scheme was proved using a BAN logic model, and the model flowchart is as follows. Figure 3 As shown, the specific model description is as follows:

[0112] 1) BAN logical symbol

[0113] In proving the security of the method presented in this paper, the following BAN logic notation is used:

[0114] P believes that message X is true and credible.

[0115] :P found a message containing X.

[0116] P sent a message containing X during a certain period of time.

[0117] P has jurisdiction over message X.

[0118] Message X is fresh.

[0119] X and Y are messages Part of it.

[0120] : Encrypt message X using key Y.

[0121] K is the key shared by P and Q.

[0122] 2) BAN logic rules

[0123] This paper uses four BAN logic rules R1-R4 to formally prove the security of the protocol:

[0124] Message-meaning rules:

[0125] R1: R1 means that if P trusts the key K shared between entities P and Q, and finds that K encrypts message X, P will believe that Q once sent X.

[0126] Nonce-verification rules:

[0127] R2: R2 means that if P believes X is fresh and P believes Q has sent X, then P believes Q believes X.

[0128] Jurisdiction rules:

[0129] R3: R3 means that if P believes Q has jurisdiction over X, and P believes Q believes X, then P will believe X.

[0130] Freshness rules:

[0131] R4: R4 indicates that if P believes the message. Part of If it's fresh, then P believes... It's also fresh.

[0132] 3) Establish two schemes to prove the objective.

[0133] To demonstrate the semantic security of the bulk authentication key negotiation protocol, two security objectives need to be achieved. and .

[0134] . believe The authentication request message sent.

[0135] . believe The session key negotiation information sent.

[0136] 4) Establish an idealized model of the theoretical protocol

[0137] Original Agreement:

[0138] : Send message Give r here i Generated by a trusted center and sent to the vehicle via a trusted channel. and roadside units If the authentication request is for a legitimate vehicle, it will be successful. Authentication.

[0139] When the vehicle pass After verifying their identity, Return key negotiation message Give ,in If it is legal. The returned message, Can pass The test.

[0140] Idealized protocol model:

[0141]

[0142]

[0143] 5) Premise

[0144] Based on the analysis of the protocol, the following assumptions are made:

[0145]

[0146]

[0147]

[0148]

[0149]

[0150]

[0151] 6) Formal proof

[0152] Through formal semantic security analysis, we prove the semantic security of the proposed authentication key negotiation protocol.

[0153] :

[0154] According to the assumption and Message-meaning rules ,when Discovered from V i When making a request, you can get . Verification timestamp After that, I received Then according to the Freshness rule and Nonce-verification rules It can be deduced that Finally, according to and Jurisdiction rules It can be deduced that This is now achieved. Right now When V i After the request message is authenticated, Then it returns a key negotiation message.

[0155] :

[0156] Similarly, based on the assumption and rules When V i Received from When receiving the key negotiation message, one can obtain V i First, check the timestamp. ,when After testing, it can be obtained Based on the Freshness rule and the Nonce-verification rule, we can deduce that... Finally, according to the Jurisdiction rule and You can get , deduced Right now Therefore, V i and Not only was identity authentication completed, but session key negotiation was also completed.

[0157] from and The proof process demonstrates that the proposed scheme effectively achieves secure proof for batch authentication key negotiation. Using the BAN logic model, all messages sent in the actual protocol are simulated, establishing the objectives required to complete mutual authentication key negotiation. Verification of all message sources, message freshness, and message source credibility are performed. Finally, the two predetermined objectives of mutual authentication key negotiation are proven. and This completes the formal security proof of the protocol.

[0158] This invention addresses the problem in IoT networks where traditional RSU single authentication results in excessively long response times for vehicle nodes submitting later authentication requests, hindering real-time service provision. It utilizes a batch authentication protocol to achieve batch authentication and key negotiation for multiple vehicle requests. For malicious vehicles, a pseudonym mechanism is used to trace and revoke their identities. The semantic security of the invented authentication key negotiation scheme is formally proven using a BAN logic model, ensuring secure communication even under malicious attacks. This invention improves authentication efficiency while guaranteeing the privacy and security of communicating entities.

[0159] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "setting," "connection," "fixing," "rotation," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Unless otherwise explicitly limited, those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0160] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A signature-based, efficient batch authentication key negotiation method for vehicle-to-everything (V2X) networks, characterized in that, Includes the following steps: S1. Construct a vehicle-to-everything (V2X) system that includes three entities: TA (Transportation Controller), roadside units, and vehicles. Initialize the V2X system and generate common parameters. Step S1: Initialize the vehicle-to-everything (V2X) system and generate common parameters, including: TA chooses two large prime numbers p and q, where p is 512 bits and q is 160 bits, and q satisfies q|(p-1); TA selects two different random numbers and Each is used as its own master key and private key, and the private key s is calculated. TA The corresponding public key ,in = P is a generating point of the p-order multiplicative group G; TA selects a random number Calculation parameters , where g is a semigroup Generators; TA selects two collision-resistant one-way hash functions In this case, both one-way hash functions take binary sequences of arbitrary length as input and output sequences of length 1. binary sequence; Finally, the common parameters are obtained. And make it public; S2. Vehicles and roadside units apply for identity registration with TA offline through reliable channels. If the identity registration is successful, TA assigns the corresponding key authentication parameters and backs them up. The vehicle-to-everything (V2X) system includes multiple vehicles, denoted by N, with each vehicle corresponding to one vehicle user, where V is the number of vehicles. i The process of obtaining key authentication parameters for identity registration for i=1,2,…,N is as follows: S201. Vehicle User U i Set your user identity And the corresponding login password PW i And select a random number α i ; S202. Vehicle V i Based on user identity And login password PW i calculate Then combine with random number α i calculate Then generate registration request information. Send to TA; where H1 is a one-way hash function, VID i For vehicle V i Vehicle identification; S203.TA receives vehicle V i Registration request information sent And check the vehicle identity database T VID Does vehicle V exist in the middle? i identity information If it exists, the registration application is rejected; otherwise, proceed to step S204; where s is the master key of TA and H0 is a one-way hash function. S204.TA selects a random number d i Calculate vehicle V i private key Combined with s i calculate ;TA selects random numbers calculate And according to the calculation formula Get ;TA will collect Send to all roadside units registered with TA identity, and set Transmitted to vehicle V i In the installed Trusted Platform module, the final TA will collect... Save to vehicle identity database T VID In the middle; where g is a semigroup The generators are p and q, which are large prime numbers, and params are common parameters. S205. Vehicle V i Receive set And according to A i Calculate the TA assigned to vehicle V i private key Simultaneously calculate , Then the vehicle use replace Will Save the information to the vehicle's OBU to complete the identity registration; The vehicle-to-everything (V2X) system includes multiple roadside units, denoted by M, which represents the total number of roadside units (RSUs). j The process of obtaining key authentication parameters for identity registration for j=1,2,…,M is as follows: S211 Roadside Unit (RSU) j Choose your unique real identity, RID j And select a random number. calculate Registration request information is transmitted through a trusted channel. Submit to TA; P is a generating point of the p-order multiplicative group G, where p is a large prime number; S212.TA receives roadside unit (RSU) j Registration request information sent And check the roadside unit identity database T RID Does the roadside unit (RSU) exist? j identity information If it exists, the registration application is rejected; otherwise, proceed to step S213; where s is the master key of TA and H0 is a one-way hash function. S213.TA selects a random number. calculate Combined with W j calculate Then the set Transmitted to Roadside Unit (RSU) j and the set Stored in the roadside unit identity database T RID middle; S214 Roadside Unit (RSU) j Receive the set sent by TA Calculate your own private key and public key And save; S3. When a vehicle enters the coverage area of ​​a roadside unit, if the vehicle user requests media services from the roadside unit, the vehicle will first perform login authentication. If the authentication is successful, proceed to step S4; otherwise, access will be denied. S4. The vehicle initiates an authentication request to the roadside unit. The roadside unit authenticates the vehicle's identity. If the authentication is successful, proceed to step S5; otherwise, reject the vehicle's authentication request. Step S4 Vehicle V i Roadside Unit (RSU) j The process of initiating an authentication request includes: S401. Vehicles Select the current timestamp calculate Meanwhile, vehicles Choose a random number calculate ; S402. Vehicle V i Based on the parameters obtained during identity registration and calculate ,in Then generate vehicle V i authentication request Send to roadside unit ; Roadside Unit (RSU) j Receive vehicle authentication requests and perform identity authentication, including: S411. If the roadside unit RSU j At the current timestamp TR j If only one vehicle authentication request is received, proceed to step S412. If the roadside unit (RSU) is... j At the current timestamp TR j If authentication requests for two or more vehicles are received, proceed to step S415. S412 Roadside Unit (RSU) j Receiving vehicle V i authentication request And determine whether the timestamp is valid. ,in, Minimum time limit; if not met, vehicle V is rejected. i If the authentication request is satisfied, proceed to step S413; S413. Based on the authentication request Perform XOR operation Obtain identity information Roadside Unit (RSU) j Query vehicle identity database Does vehicle V exist in the middle? i identity information If it does not exist, then vehicle V is rejected. i If an authentication request exists, proceed to step S414; S414. Determine if there are equalities Is it valid? If not, reject vehicle V. i The authentication request is submitted; if successful, the identity authentication is completed, and the Roadside Unit (RSU) is activated. j Select random number calculate , , and temporary session keys ; Last roadside unit Select the current timestamp The information to be negotiated Send to vehicle S415. Roadside Unit (RSU) j Receiving vehicles authentication request Each authentication request is checked to see if it meets the timestamp validity condition. All vehicles that meet the timestamp validity condition are obtained and step S416 is executed. S416 Roadside Unit (RSU) j Calculate and query the vehicle identity database If vehicle identification information is found, obtain all vehicles with identification information and execute step S417; S417 Roadside Unit (RSU) j Judgment Equation Whether it is true or not, among which, This indicates that among n vehicles, those meeting the timestamp validity condition and listed in the vehicle identity database... The number of vehicles with identity information is determined; if this is not true, all vehicle authentication requests are rejected; if this is true, the corresponding negotiation information is calculated and returned. S5. The roadside unit sends negotiation information to the vehicle, and the vehicle performs mutual authentication with the roadside unit. If the authentication is successful, the vehicle calculates the session key based on the negotiation information to complete the key negotiation; otherwise, the request fails. S6. When it is discovered that a malicious attacker is sending false information, the malicious attacker's identity will be traced and their status revoked.

2. The efficient batch authentication key negotiation method for vehicle networking based on signature as described in claim 1, characterized in that, When vehicle V i Drive into the roadside unit RSU j When covering the area, if its vehicle user U i Roadside Unit (RSU) j Requesting access to media services, vehicle V i First, you need to complete login authentication, including: S31. Vehicle User U i To vehicle V i Enter your user identity And login password PW i Vehicle V i Calculate based on input information and Where H1 is a one-way hash function; where C i For vehicle V i Key parameters for identity verification; S32. Determine if there is an equality. If true, then vehicle V i I have registered my identity with TA, vehicle user U i If the user is a legitimate user, then vehicle user U is considered a legitimate user. i Login failed.

3. The efficient batch authentication key negotiation method for vehicle networking based on signature as described in claim 1, characterized in that, The vehicle receives the negotiation information returned by the roadside unit and performs mutual authentication, including: S51. Vehicle V i Receiver Roadside Unit (RSU) j Returned negotiation information Determine if the second timestamp condition is met. If not, then vehicle V... i With roadside unit RSU j Mutual authentication fails; if satisfied, proceed to step S52. S52. Calculate based on negotiated information , And determine the equation. If the condition is not met, then vehicle V... i With roadside unit RSU j Mutual authentication failed; if successful, vehicle V... i With roadside unit RSU j Mutual authentication successful, calculate temporary session key. Complete key negotiation.

4. The efficient batch authentication key negotiation method for vehicle networking based on signature as described in claim 1, characterized in that, If the vehicle is registered through identity V i Turn into a malicious attacker in the roadside unit RSU j Sending false information within its coverage area, roadside unit (RSU) j Identification and revocation of malicious attackers include: S61. Roadside Unit (RSU) j Detect malicious attacker V i The parameter r used for authentication i and in the vehicle identity database Searching for parameter r i Corresponding identity information ; S62. Roadside Unit (RSU) j identity information Send to TA and in the vehicle identity database Delete identity information and related data; S63.TA in vehicle identity database T VID Retrieving identity information The corresponding random number k i , random number k i Modified to ; S64. Based on the modified random number The parameters were recalculated. And send it to all roadside units that have registered with TA through their identities, each roadside unit will have the vehicle identity database Chinese identity information The corresponding parameter r i Modified to .

Images