A lightweight anonymous cross-domain batch authentication method for internet of vehicles

Abstract

The present application belongs to the field of authentication and key agreement in Internet of Vehicles, and particularly relates to a kind of lightweight anonymous cross-domain batch authentication method in Internet of Vehicles, in the Internet of Vehicles network formed by trusted center, roadside unit and mobile vehicle loaded with OBU, wired link communication is carried out between trusted center and roadside unit, wireless communication link communication is carried out between vehicle and vehicle and between vehicle and roadside unit, and the process of authentication in the Internet of Vehicles network specifically includes: initializing Internet of Vehicles system, and giving the initialization system parameters of the Internet of Vehicles system; identity registration and verification are completed by vehicle and roadside unit to trusted center respectively, and vehicle needs to perform login to verify its legality; the vehicle that successfully logs in performs fast authentication to confirm whether its identity is legal, and key agreement is used to guarantee the security of subsequent session; after completing authentication in a roadside unit, the vehicle completes fast proof according to label mode when reaching the range of other roadside units. The present application ensures that vehicles can still communicate safely in the environment of communication in public insecure channel, effectively resists common malicious attacks, and has good economic benefits.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of authentication and key agreement in Internet of Vehicles, and particularly relates to a lightweight anonymous cross-domain batch authentication method in Internet of Vehicles. BACKGROUND

[0002] Internet of Vehicles (IoV) is a product of the combination of Internet of Things and Intelligent Transportation Systems (ITS), and aims to provide a safer and more comfortable travel environment and faster and more convenient new applications for drivers, passengers and pedestrians. Using IoV can reduce 60% of road congestion and improve 70% of short-distance transportation efficiency, so that the driving experience of drivers is greatly improved. While IoV improves traffic efficiency, facilitates public life and enhances travel safety, there are still many problems to be solved. Among them, since IoV is established in an open communication environment, it inherits the defects of wireless communication network: information transmitted in the public channel is extremely vulnerable to various malicious attacks, which in turn leads to a series of privacy and security problems.

[0003] Authentication and Key Agreement (AKA) is an effective means to solve the security problems of IoV. Through authentication, legitimate registered vehicles can quickly access IoV, while denying access to illegal and malicious vehicles. Through key agreement, a secure session key is established to encrypt the information exchanged between entities, so as to protect the communication content from being stolen. The current network model of IoV authentication mainly includes entities such as On Broad Unit (OBU), Road Side Unit (RSU) and Trusted Authority (TA). Each intelligent vehicle is equipped with OBU to communicate with the outside environment. RSU is an edge device, which is closer to the vehicle than the vehicle, regularly broadcasts road traffic information to the surrounding vehicles and provides related entertainment services, and TA is usually responsible by the traffic management department, acting as an authoritative agency to ensure global security.

[0004] Although the traditional AKA invention can guarantee the basic security of IoV, on the one hand, the high sensitivity of IoV authentication delay under the high-speed moving characteristics of vehicles, on the other hand, the frequent moving and switching of vehicles between RSUs, which makes the communication link frequently disconnected and connected, and the additional resource consumption caused by repeated authentication of vehicles at different RSUs, brings great challenges to the design of current AKA invention.

[0005] To alleviate the authentication pressure of RSU / TA, it is proposed to package and batch authenticate the messages received within a certain time range to reduce the calculation times of RSU / TA. In a complex IoV communication environment, edge devices such as RSU belong to semi-trusted entities, and in an open environment, they may be attacked, so centralizing the batch authentication service of vehicles on RSU will cause certain security risks. In addition, the computing and storage capacity of RSU itself is limited, and under the impact of massive data, it may cause data processing to be not timely or even paralyzed.

[0006] In summary, the prior art solution does not consider the repeated authentication overhead caused by the rapid switching of vehicles between RSUs, that is, when a vehicle that has completed initial authentication in the range of a certain RSU switches to another new RSU range, most solutions default to repeat the content set by the invention, which will bring high repeated overhead under the characteristics of high-speed vehicle movement. SUMMARY

[0007] To solve the above problems, the present application provides a lightweight anonymous cross-domain batch authentication method for Internet of Vehicles, in the Internet of Vehicles network composed of trusted center, roadside unit and mobile vehicle loaded with OBU, the trusted center and roadside unit communicate through wired link, the vehicles and vehicles, vehicles and roadside units communicate through wireless communication link, the authentication process in the Internet of Vehicles network specifically includes the following steps:

[0008] Initialize the Internet of Vehicles system and give the initialization system parameters of the Internet of Vehicles system;

[0009] The vehicle and the roadside unit complete identity registration and verification with the trusted center respectively, and the vehicle needs to perform login to verify its legality;

[0010] The vehicle that successfully logs in performs fast authentication to confirm whether its identity is legal, and key negotiation is used to ensure the security of subsequent sessions;

[0011] After the vehicle completes authentication in a roadside unit, when it reaches the range of other roadside units, the vehicle quickly completes the proof according to the label method.

[0012] The beneficial effects of the present application: the present application fully considers the factors of the rapid movement switching of vehicles among RSUs in the Internet of Vehicles, that is, after the vehicle completes authentication at a certain RSU, if it moves to the coverage range of a new RSU, the vehicle needs to be re-authenticated at the new RSU, thereby causing the problem of high repeated authentication overhead, proposes to use elliptic curve cryptography to simultaneously batch authenticate and key negotiate a large number of vehicles, considers the factors of vehicle users, designs a user login and password change mechanism to improve the security of the application, then designs a cross-domain label generation and verification mechanism, and then designs a cross-domain switching authentication application for vehicles based on the label, which greatly reduces the additional resource consumption caused by repeated vehicle authentication, in addition, the label can be upgraded and updated, which is more in line with the actual scene, proposes a binary search algorithm, which can distinguish between valid and invalid information in the batch message to reduce resource waste when batch authentication fails, designs a corresponding pseudonym updating and anonymous tracing method, and proves the security of the application based on the random oracle model, which can effectively protect user privacy and security, resist various malicious attacks, and has good economic benefits. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 A lightweight cross-domain anonymous batch authentication Internet of Vehicles system model in the embodiments of the present application;

[0014] Figure 2 A protocol flowchart of the embodiments of the present application;

[0015] Figure 3 A step flowchart of the embodiments of the present application;

[0016] Figure 4 A flowchart of entity information interaction in the batch authentication and key negotiation stage in the embodiments of the present application;

[0017] Figure 5 A cross-switching authentication scenario diagram in the embodiments of the present application;

[0018] Figure 6 A random oracle proof flowchart in the embodiments of the present application. DETAILED DESCRIPTION

[0019] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the present application.

[0020] The application provides a lightweight anonymous cross-domain batch authentication method for Internet of Vehicles, in an Internet of Vehicles network composed of a trusted center, a roadside unit and a mobile vehicle loaded with an OBU, the trusted center and the roadside unit communicate through a wired link, the vehicles communicate with each other and the vehicles and the roadside unit communicate through a wireless communication link, and the process of authentication in the Internet of Vehicles network comprises the following steps.

[0021] The Internet of Vehicles system is initialized, and the initialization system parameters of the Internet of Vehicles system are given.

[0022] The vehicles and the roadside unit complete identity registration and verification with the trusted center respectively, and the vehicles need to perform login to verify the legality thereof.

[0023] The vehicles that successfully log in perform fast authentication to confirm whether the identity thereof is legal, and key negotiation is used to guarantee the security of subsequent sessions.

[0024] After the vehicles complete authentication at one roadside unit, when the vehicles arrive at the range of other roadside units, the vehicles complete the proof in a labeled manner.

[0025] In the embodiments provided by the application, considering the security authentication in the Internet of Vehicles system IoV, an anonymous cross-domain batch authentication Internet of Vehicles system model is constructed, as shown in Figure 1 The Internet of Vehicles system constructed in the method involves three types of entities, namely a trusted center TA, a roadside unit RSU and a mobile vehicle loaded with an OBU, the TA and the RSU communicate through a wired link, the vehicles communicate with each other and the vehicles and the RSU communicate through a wireless communication link, in the embodiments, the vehicles communicate with each other through a V2V mode, and the vehicles and the RSU communicate through a V2R mode, wherein:

[0026] The trusted center TA has strong computing and storage performance, is generally responsible by a traffic management department and belongs to a fully trusted entity, and mainly undertakes registration and authentication functions in the application;

[0027] The roadside unit RSU has limited computing capability and belongs to a semi-trusted entity, and thus does not directly provide authentication services. In the application, the RSU mainly undertakes information transmission between vehicle users and the TA and key negotiation services.

[0028] The vehicle user is a user who drives an intelligent vehicle and uses IoV related services, and belongs to an untrusted entity, and thus needs to be authenticated before accessing the IoV to confirm the legality of the identity thereof; the intelligent vehicle is loaded with an OBU responsible for simple computing and communication tasks.

[0029] As shown in Figure 2As shown, the vehicle authentication process in the application includes six stages, the first stage is system initialization, that is, the trusted center generates public parameters and private keys and the like; the second stage is vehicle user registration with the RSU, when the vehicle after completing registration performs the third stage of login, after successfully passing the third stage of login, the vehicle user will enter the fourth stage to perform batch authentication and key negotiation, the fifth stage supports the vehicle user to perform fast cross-domain authentication, and the sixth stage is the upgrade and update of the cross-domain label.

[0030] In this embodiment, a flowchart of a vehicle networking lightweight anonymous cross-domain batch authentication method is provided as shown in the figure, which specifically includes: Figure 3

[0031] S1, initialize the vehicle networking system, and give the initialization system parameters of the vehicle networking system, the vehicle networking system including a trusted center TA, a roadside unit and a vehicle.

[0032] S2, the vehicle and the roadside unit RSU complete identity registration and verification with the trusted center TA respectively, and the vehicle user needs to perform login to verify its legality.

[0033] S3, the vehicle after successful login needs to perform fast authentication to confirm whether its identity is legal, and key negotiation is used to guarantee the security of the subsequent session. The fast batch authentication and key negotiation process of a large number of vehicles are realized.

[0034] S4, a vehicle fast cross-domain switching authentication invention is proposed, that is, when the vehicle moves to the range of a new RSU, it will quickly complete the verification through the label, avoiding repeated use of the previously designed authentication process.

[0035] This embodiment provides a specific implementation of the initialization system parameters of the vehicle networking system, which is responsible for the TA at this stage, for generating related system parameters, and the generation process of the parameters includes:

[0036] Let F p be a prime finite field, p represents the size of the field, the TA generates an elliptic curve E: y 2 = x 3 + ax + b mod p, (a, b) ∈ F p , G is a prime group with order q, and the generator is P, P ≠ O, wherein O represents infinity;

[0037] Then, the TA selects a one-way anti-collision hash function h: l i represents the output length;

[0038] After that, the TA randomly selects as the system master private key, and then calculates P pub = s TA ​• P as the system public key

[0039] Finally, TA publishes the system public parameters {P pub , h, G, q}.

[0040] Vehicle user registration phase, vehicle user needs to register to TA to obtain the authentication private key, to facilitate the subsequent authentication process. Vehicle user performs the following steps to complete the registration:

[0041] S201, the user confirms its username IDU i and password PWD i , and calculates Then {IDU i , FPW i} is uploaded to TA through a secure channel. Here, the real password is not uploaded to TA to improve the security of the invention.

[0042] S202, after receiving the user registration request, TA selects a random number as the user's authentication private key, calculates the corresponding public key D ui = d ui · P, in order to support the user to verify the username and password locally, TA continues to calculate and Then generate a long-term session key lsk ui = h(D ui || IDU i ) · s TA mod q for the user.

[0043] S203, TA returns the message {A ui , B ui , lsk ui} to the user through a secure channel, and the user stores the received information {A ui , B ui , lsk ui , P} in the local trusted platform module (Trusted Platform Module, TPM).

[0044] Before authentication and key agreement, the vehicle user needs to log in first to preliminarily verify its legitimacy. The login process is as follows:

[0045] S221, the vehicle user V i inputs its username IDU i and password PWD i into the OBU of the vehicle user V i .

[0046] S222, the OBU calculates Then judge B' ui = B ui is established, the login is successful, otherwise the login fails.

[0047] It is worth noting that the number of times of user input username and password is limited, when exceeding the threshold but still not completing login, the OBU will be locked for a period of time, refusing to continue login.

[0048] The vehicle that successfully logs in needs to be quickly authenticated to confirm whether its identity is legal, and key negotiation is used to protect the security of subsequent sessions. As shown in the figure, it specifically includes the following steps: Figure 4

[0049] S31, the intelligent vehicle V i driven by the user selects a random number as its private key for key negotiation, and calculates the corresponding public key F ui = f ui · P. Record the current timestamp T ui of the system, and generate a pseudonym for the user wherein D' ui is calculated when the user logs in, and finally generate signature information a ui = (lsk ui + f ui )· b ui mod q, wherein b ui = h (lsk ui || IDU i || F ui || T ui ). The vehicle sends an authentication request message m ui = {F ui , FIDU ui , D' ui , a ui , T ui} to the nearby RSU.

[0050] S32, the RSU i receives multiple authentication request messages from different vehicles V i , checks whether the timestamp T ui carried by the authentication request message is valid, and if not, refuses access and no longer performs the subsequent process. If it is valid, the RSU i selects a random number as its private key for key negotiation, and calculates the corresponding public key L Ri = l Ri · P, records the current timestamp T Ri of the system, and then calculates its pseudonym ​Finally, signature information α is generated Ri = h(lsk Ri || IDR i || L Ri || T Ri ), RSU i sends message m Ri = {m ui , L Ri , FIDR i , α Ri , C i , T Ri} to TA, k is the number of RSUs i The number of messages with valid timestamps received in the authentication request message.

[0051] S33, after receiving message m Ri , TA first checks whether the timestamp T Ri is valid, and if not, rejects this access. If valid, TA calculates lsk' Ri = h(IDR' i || s TA ) + C i , α' Ri = h(lsk' Ri || IDR' i || L Ri || T Ri ), and determines whether α' Ri = α Ri is true, and if true, RSU i successfully passes the authentication, and if not, rejects this access. Then TA continues to complete the authentication of the vehicle, calculates lsk' ui = h(D' ui || IDU' i ) · s TA mod q, and finally determines whether the formula is true to complete the authentication of the vehicle.

[0052] S34. After TA successfully completes the verification of the vehicle and RSU, TA continues to generate a temporary tag for the vehicle in the following manner: selecting a random number calculating ttag i = h(lsk' ui || tag i || IDU' i ), and then generating a global tag table as shown in Table 1. Continue to symmetrically encrypt the tag where the symmetric key ω ui = s TA · Fui Record system current timestamp T TA Generate corresponding signature information Finally, TA sends the message to RSU i .

[0053] Table 1 Global Tag Table

[0054]

[0055] Table 1 gives the information recorded in the global tag table. In the global tag table, five pieces of information of user ID, tag level, validity period, and use count of each user need to be recorded. The user ID column records the real name of the user. The tag level is upgraded according to the use count. When the use count reaches the set value, the tag level is upgraded, and the use count is emptied and starts counting again after the upgrade. The validity period indicates the validity period of the tag. If the validity period is exceeded, the five pieces of information of user ID, tag level, validity period, and use count of the user will be deleted from the global tag table, and the user needs to apply for a new tag.

[0056] S35. RSU i After receiving the message m TA , first check the freshness of the timestamp T TA . After passing, accept and trust the parameters {FIDU i , F ui} of the vehicle V i . If the check fails, stop the subsequent process. Next, the RSU i will negotiate the session key between the vehicle V i . The RSU i records the current system timestamp as T Rj , then generates the session key sk uRi = h(l Ri · F ui || FIDU i || FIDR i ), and calculates the corresponding signature τ Ri = h(sk uRi || T Rj || L Ri ). Finally, the RSU i returns the message m Rj = {τ Ri , T Rj , FIDR i , L Ri} to the nearby vehicles.

[0057] S36. Vehicle V i After receiving the message m Rj , first check the freshness of the timestamp T RjThe validity of the value is checked; if invalid, the process stops. If valid, then V... i Calculate sk' uRi =h(f ui ·L Ri ||FIDU i ||FIDR i ), τ' Ri =h(sk') uRi ||L Ri ||T Rj ), determine τ' Ri =τ Ri If the condition is not met, the access will be denied. If the condition is met, then V... i Accept and trust RSU i The parameter {FIDR i ,L Ri At this point, the entire authentication process is successfully completed, V i with RSU i The session key sk was successfully negotiated. uRi Finally, to support fast cross-domain authentication switching, V... i calculate Determine υ' i =υ i Check if the condition is met; if not, stop the process. If met, then V. i Perform a symmetric decryption Where the symmetric key ω ui =f ui ·P pub Ultimately V i legal tag ttag i Store securely in TPM.

[0058] Because the invention supports volume certification, RSU i It can receive multiple V messages from different vehicles at once. i The authentication request messages arrive at the RSU simultaneously. i At that time, RSU i We only need to examine the earliest timestamp T in this batch of messages. ui If the timestamp is still valid, the entire batch of messages is valid. If the verification fails, the message carrying the timestamp is removed, and the next timestamp is checked until success is achieved.

[0059] When the vehicle is in high-speed driving, it will switch between multiple RSUs, so when the vehicle leaves the range of the RSU it has been authenticated and enters the coverage range of a new RSU, it needs to be re-authenticated at the new RSU, thereby bringing high repeated authentication overhead. The invention of this chapter supports the fast cross-domain switching authentication of the vehicle, that is, when the vehicle moves to the range of a new RSU, it will quickly complete the inspection through the label, avoiding repeated use of the previously designed authentication process. As shown in Figure 5 , the steps specifically include:

[0060] S401, the vehicle user V i switches to the RSU j coverage range, because V i has already completed authentication previously, so the legal label ttag i is stored in the local TPM i , V ui performs one-way symmetric encryption where ω ui =f pub ·P uj , records the current timestamp T i of the system, and generates the corresponding message signature Finally, V j sends the message m to the RSU j .

[0061] S402, after the RSU uj receives the message m uj , it first verifies the freshness of the timestamp T j , and if it does not pass, it rejects this request. If it passes, and the RSU j has passed the authentication process in step S3, the RSU j This step mainly plays a relay role. If the RSU j has not passed the initial authentication process described above, it performs authentication in the manner of step S3. Finally, the RSU uj sends the message m uj to the TA.

[0062] S403, after the TA receives the message m uj , it also needs to verify the validity of the timestamp T ui , and if it is invalid, it terminates the process. If it is valid, it performs label verification, and brings the calculated lsk' i value into the formula to get Judge whether ε' i = ε ui is equal, if not equal, then reject access. If equal, perform symmetric decryption where ω TA =s uiThen, the global label table in the database is searched to determine whether the label exists and its corresponding valid period is expired. If all the conditions are passed, the RSU j returns the authentication success information. If not, the corresponding failure information is returned.

[0063] S404. The RSU j receives the authentication success information, negotiates the session key sk i with the V uRj according to the process described in S35, and obtains the session key. i The V j completes the cross-domain switching authentication process and successfully negotiates the new session key sk uRj with the RSU i .

[0064] Regarding the label upgrade and update:

[0065] Label upgrade: when the label ttag i of the vehicle V i is sent to the TA for verification, if the verification is successful, the TA will increase the use count Cnt i of the corresponding label in the table by 1. When the count exceeds the system threshold, i.e., Cnt i > Thd, the TA will modify the level of the label to level 1, extend the valid period of the label, and finally update the count field of the label to NULL. At this time, the temporary label is upgraded to a long-term label, and the V i will have a longer label use period.

[0066] Label update: when the ttag i of the V i is sent to the TA, if the ttag i has expired, the TA deletes the label information from the table, and returns an error information to the V i , indicating that the label has expired. At this time, the V i needs to re-initiate an authentication request to the TA to obtain a new available label. It is worth noting that the TA will perform a verification when receiving the label of the V i , and delete the expired information from the table. In addition, the TA will also perform an autonomous detection every certain time t to delete the expired information from the table, so as to save storage resources.

[0067] The application supports the user to change the login password, and the specific implementation steps are as follows:

[0068] S411, the user inputs the username IDU i , the original password PWD i , and the new password into the vehicle-mounted OBU.

[0069] S412、OBU according to the username and the original password Then calculate Judge equation B' ui =B ui If not, reject this password modification request. If yes, the user identity authentication is successful, and then update and And replace the original B ui With Stored in the TPM.

[0070] Pseudonym update stage, both the vehicle and the RSU need to pass through the pseudonym mechanism to protect their privacy, but as time goes by, the enemy can also launch an attack when repeatedly intercepting the information carried by the same pseudonym, so the pseudonym update mechanism is particularly important. The present application calculates the pseudonym by the vehicle and the RSU itself, and carries the current system timestamp when calculating, that is, the pseudonym carried by the vehicle or the RSU is different each time the authentication request is sent. At the same time, this kind of update method avoids the participation of other institutions, effectively reducing the overhead of pseudonym update.

[0071] Anonymous tracing stage, when the vehicle that completes the legal registration publishes malicious information in the system, the protocol can support the rapid revocation of the malicious vehicle. Specifically, when the malicious vehicle V i spreads malicious messages and is intercepted, the RSU i nearby will send the relevant information of V i to the TA, and the TA can decrypt the real identity of V i through the formula After receiving it, then performs a revocation operation on the real identity.

[0072] The present application uses the random oracle model to prove the semantic security of the embodiments of the present application, and the model flow is as shown in Figure 6 , and the specific model description is as follows:

[0073] The proof process based on the random oracle model (ROM) is generally as follows: by analyzing the game between the challenger ζ and the attacker A, the security model is defined, and finally the session key security of the proposed protocol is inferred. Assume that the participating entities of the proposed protocol are vehicle V i , RSU j and TA. Let Denote the ith instance in the participating entity ψ, ψ∈{V i , RSU j , TA}, and A can perform the following query operations on ζ:

[0074] When this query is executed, A sends message M to ζ, and ζ returns the corresponding response message to A.

[0075] This query is an eavesdropping query, i.e., A learns all the information exchanged by ζ during the execution of the protocol.

[0076] In this query, if is successfully accepted, A can obtain the session key between ζ and its partner.

[0077] When A executes this query to ζ, ζ outputs the long-term key of to A. When A executes this query using , if the instance satisfies the definition of freshness, ζ obtains the result b of tossing an unbiased coin, b∈{0,1}. If b = 1, ζ outputs the real session key of to A; if b = 0, ζ generates a session key randomly in the same domain and returns it to A.

[0078] Partner: If two instances and in establish the same session key by passing the relevant phase in the protocol, or and can directly exchange information, then and are partners.

[0079] Freshness: If the instance satisfies the following conditions, then is fresh:

[0080] ① has not been queried by Reveal.

[0081] ② has not been queried by Reveal.

[0082] ③ has not been queried by Corrupt.

[0083] ④ has not been queried by Corrupt.

[0084] 3) Semantic security: After A succeeds in executing the above query, it outputs b mentioned in the Test query, i.e., A sends the guessed b' to ζ. The probability that A succeeds in breaking the proposed protocol is defined as the probability that A succeeds in guessing b. The proposed protocol is semantically secure if no arbitrary PPT A can win the game with advantage Adv(A).

[0085] Theorem: No arbitrary probabilistic polynomial time A can win the game with probability .

[0086] Proof: Define a 5-stage sequential game Ge i (i = 0, 1, 2, 3, 4), let Et i denote the event in the game that corresponds to the attacker A successfully guessing b mentioned in the Test query.

[0087] Game Ge0: To simulate the real attack scenario, we set that A can send various prediction queries to ζ, and ζ can respond in the following ways:

[0088] The queries can be divided into the following types according to different steps in the protocol:

[0089] (1) Send(V i , begin): When ζ receives this Send query, ζ performs the following operations: selects a random number , computes F ui = f ui · P, β ui = h(lsk ui || IDU i || F ui || T ui ) and α ui = (lsk ui + f ui )· β ui mod q, and finally ζ responds to A with the message m ui = {F ui , FIDU ui , D' ui , α ui , T ui}.

[0090] (2) Send(RSU j , m ui ): When ζ receives this query, it selects a random number and computes L Ri = l Ri · P, and α Ri= h(lsk Ri || IDR i || L Ri || T Ri ). Finally ζ returns the message m Ri = {m ui , L Ri , FIDR i , a Ri , C i , T Ri} to A.

[0091] (3) Send(TA, m Ri ): When ζ receives this query, ζ checks the correctness of T Ri , a Ri and a ui , and returns nil to A and terminates the process if it fails. If it passes, ζ chooses computes ttag i = h(lsk' ui || tag i || IDU' i ), and finally ζ returns the message to A.

[0092] (4) Send(RSU j , m TA ): When ζ receives this query, ζ checks the freshness of T TA , and returns nil to A and terminates the process if it fails. If it passes, ζ generates sk uRi = h(l Ri · F ui || FIDU i || FIDR i ), and computes τ Ri = h(sk uRi || T Rj || L Ri ), and finally ζ returns the message m Rj = {τ Ri , T Rj , FIDR i , L Ri} to A.

[0093] (5) Send(V i , m Rj ): When ζ receives this query, ζ checks the freshness of T Rj , and returns nil to A and terminates the process if it fails. If it passes, ζ computes sk' uRi = h(f ui · L Ri||FIDU i ||FIDR i ), τ' Ri =h(sk') uRi ||L Ri ||T Rj ), determine τ' Ri =τ Ri Check if the condition is true. If not, return null to A and terminate the process. Otherwise, calculate ζ. Continue to verify υ' i The process checks the correctness of the match; if no match is found, it returns an empty value to A and terminates the process. If a match is successful, the decryption is complete. Finally, ζ returns a message to A indicating that authentication and key negotiation were successful.

[0094] When ζ receives a query from A, ζ will return a response to A. All recently sent and received messages. For example When that happens, return message {m} to A. ui ,m Rj}

[0095] When ζ receives A's After querying, if If accepted, ζ returns the session key sk to A. uRi ,like If rejected, return a null value to A and terminate the process.

[0096] When ζ receives A's After the query, ζ will long-term key lsk ui or lsk Ri Respond to A.

[0097] When ζ receives A's After the query, ζ will toss a fair coin to obtain the value of b (the value of b is private to A). When b = 1, ζ will... The real session key sk uRi Output to A; otherwise, ζ will generate a random number in the same domain (length is the same as sk). uRi (Consistent) and returned to A.

[0098] As can be seen in process Ge0, It can perform the corresponding query operation according to the specifications of the proposed LCDBA protocol. Since Ge0 is consistent with the actual LCDBA protocol, the probability that A can crack Ge0 is the same as the proposed semantic security.

[0099] Process Ge1: In this process, A runs... The query is used to obtain eavesdropping information, and finally the process is run. The query result of Test determines whether A can obtain the correct session key. In the proposed LCDBA protocol, V i with RSU j The session key between them is sk uRi =sk' uRi , i.e., sk uRi =h(l Ri ·F ui ||FIDU i ||FIDR i )=h(L Ri ·f ui ||FIDU i ||FIDR i )=sk' uRi If A wants to successfully obtain the session key, it must know V. i with RSU j private key f ui and l Ri However, these messages are only indirectly encapsulated within the sent messages. Even if A successfully eavesdrops on these messages, it cannot decipher them, and therefore A cannot obtain the correct session key. Thus, when A eavesdrops on messages transmitted between entities, the probability of A winning Ge1 does not increase; that is, processes Ge0 and Ge1 are indistinguishable.

[0100] Process Ge2: In this process, A performs hash lookups, send queries, and execute queries. This process simulates an active attack; A intercepts all communication messages. Since each message carries a timestamp when sent, the probability of a hash collision when A performs a send query is almost zero. Based on the birthday paradox, the maximum probability of a hash function collision is... V i with RSU j random number f ui and l Ri The maximum probability of conflict is (q) s +q e ) 2 / (2q), meaning that processes Ge2 and Ge1 are also difficult to distinguish.

[0101] Process Ge4: This process also simulates an active attack. A will use all the eavesdropped information and the information obtained from the above process to obtain the session key sk. uRi =sk' uRi Because of the session key sk uRi =h(l Ri ·F ui ||FIDUi ||FIDR i )=h(L Ri ·f ui ||FIDU i ||FIDR i )=sk’ uRi , which is protected by the elliptic curve CDHP.

[0102] Finally, when A finishes all the queries in Ge4, A will perform the Test query to obtain the session key. When it is performed, A will guess the value of b, and the success probability of A is 1 / 2.

[0103] Therefore, the probability of A successfully breaking the proposed LCDBA protocol can be ignored.

[0104] The present application aims at the security authentication scene of Internet of Vehicles, and designs a lightweight anonymous cross-domain batch authentication method for Internet of Vehicles. First, the influence of vehicle users is additionally considered, and a corresponding user registration and login mechanism is designed. Then, a fast batch authentication process is designed based on an elliptic curve password when a large number of vehicles simultaneously access IoV. When the vehicle and the RSU are both verified by the TA, they can efficiently perform key agreement between each other, guarantee the safety of subsequent communication, and improve the utilization rate of resources. Then, a lightweight cross-domain switching authentication process is designed based on a label. The label is issued by the TA for the vehicle in the first authentication process and exists in the corresponding global label table. When the vehicle that has completed the first authentication switches to the next RSU field, the label can be used to quickly perform authentication, greatly reducing the additional overhead caused by repeated authentication. At the same time, a label upgrade and update mechanism is also designed to improve the perfection of the protocol. Furthermore, a binary search algorithm is proposed to solve the problem of resource waste caused by batch authentication failure. Finally, the security of the protocol is proved based on the random oracle model, and it is proved through related analysis that the proposed protocol has better efficiency.

[0105] Although the embodiments of the present application have been shown and described, it will be understood by those of ordinary skill in the art that various changes, modifications, substitutions and alterations can be made thereto without departing from the principles and spirit of the present application, and the scope of the present application is defined by the appended claims and their equivalents.

Claims

1.A lightweight anonymous cross-domain batch authentication method for Internet of Vehicles, characterized in that, In the vehicle networking network composed of the trusted center, the roadside unit and the mobile vehicle equipped with OBU, the trusted center and the roadside unit communicate through wired link, and the vehicles communicate with each other and with the roadside unit through wireless communication link. The authentication process in the vehicle networking network comprises the following steps: initializing the vehicle networking system and giving the initialization system parameters of the vehicle networking system; the vehicle and the roadside unit complete identity registration and verification with the trusted center respectively, and the vehicle needs to perform login to verify its legality; the vehicle that has successfully logged in performs fast authentication to confirm whether its identity is legal, and performs key negotiation to guarantee the security of subsequent session; after the vehicle completes authentication at one roadside unit, when it reaches the range of other roadside units, the vehicle completes fast authentication according to the label mode; the process of generating a temporary label for the vehicle that has completed authentication and has no label comprises the following steps: Select a random number tag i , calculate ttag i = h(lsk' ui || tag i || IDU' i ), and then generate a global tag table, h() represents a one-way anti-collision hash function, lsk' ui is the long-term session key of the vehicle user decrypted by the trusted center, IDU' i is the username decrypted by the trusted center; Symmetric encryption of tags Symmetric key ω ui = s TA · F ui , s TA is a master private key randomly selected by the trusted center for the system, F ui is the public key of the intelligent vehicle driven by the user; Recording system current timestamp T TA , generating corresponding signature information Sending information to a roadside unit; Roadside unit verification message m TA The freshness of the data, after verification, is recorded as the current timestamp of the system as T. Rj Generate session key sk uRi =h(l Ri ·F ui ||FIDU i ||FIDR i ), l Ri The private key selected for key negotiation for the vehicle, FIDU i For vehicles, use the pseudonym FIDR to generate the pseudonym. i The pseudonym generated by the roadside unit for an authentication request message is calculated, and the corresponding signature τ is calculated. Ri =h(sk) uRi ||T Rj ||L Ri ), L Ri For private key l Ri The corresponding private key, the roadside unit will send message m Rj ={τ Ri ,T Rj FIDR i ,L Ri Return to the vehicle; The vehicle receives the message and verifies the freshness of the message m Rj , after verification, calculates sk' uRi = h(f ui · L Ri || FIDU i || FIDR i ), f ui is the private key selected by the vehicle for key agreement, τ' Ri = h(sk' uRi || L Ri || T Rj ), determines whether τ' Ri = τ Ri is true, if not, the vehicle rejects this access; if true, the vehicle accepts the parameters {FIDR i , L Ri} of the roadside unit; the process of fast authentication of the vehicle according to the label comprises: Vehicle computation Judge if υ' = f (υ, P, P') is true, if not, stop the flow; if true, the vehicle performs a symmetric decryption i = υ i Judge if υ' = f (υ, P, P') is true, if not, stop the flow; if true, the vehicle performs a symmetric decryption Symmetric key ω = f (υ, P, P') ui = f ui • P pub , P pub is the system public key, the resulting tag ttag i is securely stored in the TPM; The authentication is done by the roadside unit i and the tag ttag is obtained i The vehicle, entering the communication range of the roadside unit j, performs a symmetric encryption of the tag ttag stored in the local TPM i , records the current time stamp T uj , generates a corresponding message signature The vehicle sends the message to the roadside unit j, D′ ui being the public key of the trusted center used for user authentication decrypted by the on-board unit; Roadside unit j verifies freshness of message m uj and, upon verification, forwards message m uj to the trusted center as a relay if roadside unit j The trusted center verifies the message m uj freshness, after verification, calculates judges whether ε' i = ε i are equal, if equal, the label ttag i is obtained by decryption, queries whether the label ttag i is expired in the global label table, if not expired, passes authentication; When the tag ttag i By one authentication, its use times in the global tag table add 1, when the tag ttag i If the use times within the valid period exceed the set threshold, the tag is upgraded, the use times in the global tag table are emptied, and the valid time of the tag is extended. 2.The method of claim 1, wherein, when initializing the vehicle networking system, the trusted center generates system related parameters, and the trusted center publishes the public parameters of the system, which is expressed as: {P pub h, P, G, q} where P pub is a prime number, and pub = s TA · P; h is a one-way collision-resistant hash function that maps sequences of arbitrary length consisting of 0s and 1s to sequences of length l i consisting of 0s and 1s; G is an additive group of order q with generator P; P, q are two unequal prime numbers. 3.The method of claim 1, wherein, the process of the vehicle completing identity registration and verification with the trusted center comprises the following steps: User determines his / her user name IDU i and password PWD i A pseudo password is calculated according to the user name and password, denoted as The user name and pseudo password are sent to the trusted center through a trusted channel; Upon receiving the information, the trusted center selects a random number as the authentication private key d for the user of the vehicle ui and calculates the public key D corresponding to the private key ui = d ui · P, generates the registration parameters and the long-term session key for the user according to the public key, and the generation process includes: lsk ui = h(D ui || IDU i ) · s TA mod q The trusted center sends {A ui ,B ui ,lsk ui} to the vehicle user through a secure channel, and the vehicle stores the received message in a locally trusted module. wherein, represents XOR; P, h(), q are public parameters published by the trusted center, P, q are two unequal prime numbers; A ui , B ui is the registration parameter of the vehicle user; lsk ui is the long-term session key of the vehicle user. 4.The method of claim 3, wherein, the process of the vehicle performing login to verify its legality comprises the following steps: The vehicle user enters a user name IDU i and a password PWD i into the OBU, and the following calculation is performed: Judge B' ui = B ui If it is true, the login is successful, otherwise, the login fails. 5.The method of claim 4, wherein, the process of fast authentication and key negotiation of the vehicle that has successfully logged in comprises: The vehicle selects a random number as a private key f for key agreement ui and calculates a corresponding public key F ui = f ui · P, concatenating a current time stamp T ui to generate a pseudonym and signature information α ui = (lsk ui + f ui )· β ui mod q, and sends an authentication request message to a nearby roadside unit; The roadside unit receives k pieces of authentication request information, deletes authentication request information with invalid time stamp, and selects a random number as a private key l for one piece of authentication request information with valid time stamp Ri and calculates the corresponding public key L Ri = l Ri · P, records the current time stamp T Ri , and then calculates its pseudonym The roadside unit sends a message to the trusted center; The trusted center receives the message m Ri Afterwards, for messages with a valid timestamp, compute: lsk' Ri = h(IDR i ||s TA ) + C i a Ri = h(lsk Ri || IDR' i || L Ri || T Ri ) determining whether α' Ri = α Ri is true, and if true, authenticating the roadside unit; the trusted center calculates: lsk' ui = h(D' ui || IDU' i ) · s TA mod q determining whether the condition is met, and if so, authenticating the vehicle; where β ui = h(lsk ui || IDU i || F ui || T ui ), C i is the public key corresponding to the private key selected by the trusted center for the roadside unit. 6.The method of claim 1, wherein, the process of the roadside unit completing identity registration and verification with the trusted center comprises the following steps: the roadside unit uploads the real identity information to the trusted center through the trusted channel; Upon receiving the information, the trusted center selects a random number as a private key c for the road side unit i , and calculates the corresponding public key C i = c i · P, and generates a long-term session key lsk for the road side unit Ri = C i + h(IDR i || s TA ), and returns the message {C i , lsk Ri} to the road side unit through a trusted channel; The roadside unit will have information {C i ,lsk Ri} in the locally trusted module.

Images