Lightweight anonymous traceable and revoked VANETs mutual trust authentication and key agreement method

By adopting the lightweight anonymous traceability and revocation authentication method of Hash and XOR operations in the Internet of Vehicles, the problem of complex and insufficient security in the Internet of Vehicles is solved, and fast privacy protection authentication and effective key management are realized between Vehicles, RSUs and TAs are realized.

CN120201423AInactive Publication Date: 2025-06-24CHANGZHOU INST OF TECH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510338057.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-03-21
Publication Date
2025-06-24
Estimated Expiration
Not applicable · inactive patent

AI Technical Summary

Technical Problem

The existing Internet of Vehicle authentication schemes have insufficient security problems such as complex key management, "single point of failure" caused by centralized key management, key leakage and playback attacks, and it is difficult to achieve anonymity, traceability and revocation.

Method used

The simple operation of Hash and XOR is adopted to realize the mutual trust authentication and key negotiation method of anonymous traceability and revocation between Vehicle, RSU and TA. Through the stages of system initialization, registration, RSU authentication and two-way authentication, we ensure privacy protection and rapid authentication between entities in the trust domain.

Benefits of technology

It realizes fast mutual trust authentication and privacy protection between Vehicle, RSU and TA in the trust domain, avoids single point of failure of centralized key management, reduces the risk of key leakage and replay attacks, and supports anonymity, traceability and revocation.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120201423A_ABST
    Figure CN120201423A_ABST
Patent Text Reader

Abstract

The invention discloses a lightweight anonymous traceable and revoked VANETs mutual trust authentication and key negotiation method, which comprises the following four stages: a system initialization stage, a registration stage, RSU authentication and access to a VANETs system, a Vehile, RSU and TA mutual authentication and a Vehile and RSU session key negotiation stage, the system initialization stage is as follows: a system administrator configures a unique secret value K for the TA; the data are stored in a storage device with tamper-proofing and power consumption analysis prevention functions; and the registration stage is used for realizing registration of the Vehile and the RSU in the TA. According to the method and the system, rapid authentication among the Vehile, the RSU and the TA and secrecy of message transmission between the Vehile and the RSU in a high-speed moving and high-density vehicle scene are met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of vehicle networking information security, and particularly to a lightweight anonymous traceable and revocable mutual trust authentication and key negotiation method for VANETs. Background Art

[0002] For the identity authentication and message authentication of communication entities in vehicle networking, the following several technical solutions are mainly adopted: (1) Symmetric encryption technology is adopted, mainly including authentication schemes based on message authentication codes (MAC-BAS), authentication schemes based on hash functions (HF-BAS), and authentication schemes based on real-time efficient flow loss tolerance (TESLA-BAS). (2) Asymmetric encryption technology is adopted, mainly including anonymous identity authentication schemes based on PKI (PKI-BAS) and authentication schemes based on elliptic curve digital signature algorithms (ECDSA-BAS). (3) Identity-based authentication schemes (ID-BAS). (4) Group signature-based identity authentication (G-BAS). (5) Verification-based authentication schemes (V-BAS).

[0003] The authentication schemes based on symmetric encryption technology have problems such as complex key management (key distribution, key storage), "single point of failure" caused by centralized key management, poor scalability, security deficiencies such as key leakage and replay attacks, lack of non-repudiation, inability to achieve traceability, and difficulty in meeting the high security and dynamic requirements of vehicle networking.

[0004] The authentication schemes based on asymmetric encryption technology have problems such as low encryption and decryption efficiency, large computational overhead caused by frequent authentication, high communication overhead caused by complex certificate and signature transmission and handshake protocols, the need for complex certificate management mechanisms (certificate issuance, update, revocation, and verification) and certificate revocation list problems, and digital certificates contain vehicle identity information, which is prone to privacy leakage.

[0005] Identity-based authentication schemes usually rely on a trusted key generation center Key Generate Center (KGC), and there are problems of "single point of failure" and key escrow; the identity identifier of the vehicle is directly used as the public key, resulting in the exposure of vehicle identity information during the communication process. In addition, attackers can trace vehicle behavior and location by analyzing the identity identifier and communication mode, increasing the risk of privacy leakage; this scheme usually adopts complex cryptographic operations such as bilinear pairing (BP), with a large computational overhead; in addition, additional security parameters or signature information need to be transmitted during the authentication process, and the communication overhead is also very large.

[0006] Group signature-based authentication schemes usually adopt complex cryptographic operations (bilinear pairing, zero-knowledge proof, etc.), which incur high computational overhead. Moreover, the group signature process is more time-consuming than traditional signature verification, resulting in significant authentication delays. The large signature data volume and frequent authentication lead to high communication overhead. Group signatures require generating and managing a set of keys for each group, increasing the complexity of key management. Additionally, the frequent joining and leaving of vehicles in the group require dynamic updates of the group key, further increasing the complexity of key management. There is a contradiction between privacy protection and traceability. Although group signatures provide anonymity, if the group size is relatively small, attackers may infer vehicle identities through statistical analysis. Moreover, group signatures rely on administrators to trace the true identities of signers. If the administrator is untrustworthy or fails, traceability may fail.

[0007] Verification-based authentication schemes usually rely on a third-party verification agency. The credibility of the verification agency directly affects the security of the system, and there is also a "single point of failure" problem. The authentication scheme usually involves complex cryptographic operations (digital signature verification, zero-knowledge proof, etc.), resulting in high computational overhead. The verification process requires multiple interactions with the remote verification agency, leading to high communication overhead and authentication latency. The vehicle's identity information or certificate needs to be transmitted during the verification process, increasing the risk of privacy leakage. In addition, attackers can track the vehicle's behavior and location through verification request and response data, affecting user privacy. Summary of the Invention

[0008] Aiming at the problems existing in the prior art, the present invention provides a lightweight anonymous traceable and revocable mutual trust authentication and key negotiation method for VANETs. It only uses simple operations such as Hash and XOR to achieve privacy-protected mutual trust authentication among Vehicle, RSU, and TA within the trust domain, as well as the key negotiation method between Vehicle and RSU, meeting the requirements of fast authentication among Vehicle, RSU, and TA and the secrecy of message transmission between Vehicle and RSU in the scenario of high-speed moving and highly dense vehicles.

[0009] The object of the present invention is achieved through the following technical solutions.

[0010] A lightweight anonymous traceable and revocable mutual trust authentication and key negotiation method for VANETs includes the following four stages: system initialization stage, registration stage, RSU authentication and access to the VANETs system, and two-way authentication among Vehicle, RSU, and TA and session key negotiation between Vehicle and RSU. In the system initialization stage, the system administrator configures a unique secret value K for TA and stores K in its tamper-proof and power analysis-resistant storage device. The registration stage is used to realize the registration of Vehicle and RSU with TA.

[0011] The registration of the Vehicle includes the following steps:

[0012] Step 2-1-1: The Vehicle i selects its own unique identity identifier ID i , and sends the registration request <ID i > to the TA through a secure channel;

[0013] Step 2-1-2: After receiving the registration request from the Vehicle i , the TA generates a random number RN i for the Vehicle i , calculates the temporary identity identifier of the Vehicle i and S as well as S i = h(K||RN i ), and stores the triple (ID i , TID i , RN i ) in its storage device with anti-tampering and resistance to power analysis;

[0014] Step 2-1-3: The TA calculates and sends the registration response <TID i , A i > to the Vehicle to be registered i ;

[0015] Step 2-1-4: After receiving the registration response <TID i , A i >, the Vehicle i stores the security parameters (TID i , A i ) in its storage device.

[0016] The registration of the RSU includes the following steps:

[0017] Step 2-2-1: The RSU j selects its own unique identity identifier ID j , and then sends the registration request message <ID j > to the TA through a secure channel;

[0018] Step 2-2-2: After receiving the registration request message <ID j >, the TA generates a random number RN j for the RSU j , calculates the temporary identity identifier of the RSU j and S as well as S j = h(K||RNj ), and store the quadruple (ID j , TID j , RN j , S j ) in its storage device with tamper - proof and power - consumption analysis resistance;

[0019] Step 2 - 2 - 3: TA calculates Then send the registration response <TID j , A j > to the RSU through a secure channel j ;

[0020] Step 2 - 2 - 4: Register the RSU j After receiving the registration response <TID j , A j > from the TA, store the security parameters (TID j , A j ) in its storage device.

[0021] The authentication and access of the RSU to the VANETs system specifically include the following steps:

[0022] Step 3 - 1: The RSU j Inputs its ID j , generates a timestamp t1, calculates B j = h(TID j ||RN j ), and D j = h(TID j ||A j ||C j ||t1), then sends an authentication request message Msg1: <TID j , D j , t1> to the TA through a public channel;

[0023] Step 3 - 2: After receiving Msg1, the TA checks the validity of t1; if it is invalid, it indicates that Msg1 is not fresh, and the system immediately terminates the authentication of the RSU j ; if t1 is valid, then check whether TID j is in its storage device. If it does not exist, it indicates that the RSU j has not been registered, and the RSU j is prohibited from accessing the VANETs system; otherwise, the TA extracts the quadruple (ID j , TID j , RN j , S j ) from its storage device according to TID j), calculate B j = h(TID j ||RN j ), and verify If the two are not equal, terminate the authentication of the RSU j ; if the two are equal, the RSU j is authenticated by the TA;

[0024] Step 3-3: The TA generates a timestamp t2 and calculates F j = h(TID j ||S j ||E j ||t2), and then sends a message Msg2: <E j , F j , t2> to the RSU through the common channel j ;

[0025] Step 3-4: After receiving the message Msg2, the RSU j checks the validity of t2; if t2 is invalid, it indicates that Msg2 is not fresh and terminates the current authentication process; if t2 is valid, calculate and then verify If the two are not equal, terminate the current authentication process; otherwise, if the two are equal, the TA is authenticated by the RSU j , and the system allows the RSU j to access the VANETs system; after the RSU j accesses the VANETs system, it broadcasts a "Ready" message to the Vehicles it covers.

[0026] The mutual authentication of the Vehicle, RSU, and TA, the negotiation of the session key between the Vehicle and the RSU, and the update phase of the system configuration parameters specifically include the following steps:

[0027] Step 4-1: When receiving the "Ready" message, the Vehicle i inputs its identity ID i , generates a timestamp t3, and then calculates B i = h(TID i ||RN i ) and C i = h(TID i ||A i ||B i ||t3), and then sends a message Msg3: <TID j to the RSUi , C i , t3 >;

[0028] Step 4-2: When receiving Msg3, the RSU j checks the validity of t3; if t3 is invalid, it indicates that Msg3 is not fresh and terminates the current authentication process; if t3 is valid, the RSU j extracts TID from its memory j , generates a timestamp t4, and sends a message Msg4 to the TA via the common channel: <TID i , TID j , C i , t3, t4 >;

[0029] Step 4-3: After receiving Msg4, the TA checks whether the timestamp t4 is valid. If t4 is invalid, it indicates that Msg4 is not fresh and terminates the current authentication process; if t4 is valid, the TA finds and extracts the triple (ID i from its memory according to TID i , TID i , RN i ), and then calculates S i = h(K||RN i ), B i = h(TID i ||RN i ) and checks If they are not equal, the current authentication and key negotiation process is terminated; otherwise, the TA generates random numbers i for Vehicle j and RSU and respectively, and then calculates generates a timestamp t5, and then sends a message Msg5 to the RSU via the common channel j : <D i , G j , t5 >;

[0030] Step 4-4: After receiving Msg5, the RSU j checks whether the timestamp t5 is valid. If t5 is invalid, it indicates that Msg5 is not fresh and terminates the current authentication and key negotiation process; otherwise, the RSU j extracts A j , TID j and S j , calculates, Then the RSU j generates a timestamp t6, calculates H ij = h(Di ||G j ||SK ij ||t6), and send message Msg6: <TID i ,D j ,D i ,G j ,A j ,H ij ,t6> to Vehicle

[0031] Step 4-5: After receiving message Msg6, Vehicle i checks whether the timestamp t6 is valid. If t6 is invalid, it indicates that the received Msg6 is not fresh, and the current authentication and key negotiation process is terminated; otherwise, Vehicle i extracts A i and TID i from its storage device, calculates and verifies If the two are not equal, the current authentication and key negotiation process is terminated; otherwise, Vehicle i calculates uses to replace (A i ,TID i ), then generates timestamp t7, calculates and sends message Msg7: <L j ,t7> to RSU through the common channel ij ;

[0032] Step 4-6: After receiving message Msg7, RSU j checks whether the timestamp t7 is valid. If t7 is invalid, it indicates that Msg7 is not fresh, and the current authentication and key negotiation process is terminated; otherwise, calculates and then verifies If the two are not equal, the current authentication and key negotiation process is terminated; otherwise, RSU j calculates then uses to replace (A j ,TID j ), RSU j generates timestamp t8, and sends message Msg8: <S j ,G j ,t8> to TA through the common channel

[0033] Step 4-7: After receiving the message Msg8, the TA checks whether the timestamp t8 is valid. If t8 is invalid, it indicates that the received Msg8 is not fresh, and the current authentication and key negotiation process is terminated; otherwise, the TA checks whether both TID i and TID j already exist in its memory. If either TID i or TID j does not exist, the current authentication and key negotiation process is terminated; otherwise, the TA calculates Then, the TA respectively uses to replace (ID i , TID i , RN i ) stored in its memory, and uses to replace (ID j , TID j , RN j , S j ) stored in its memory.

[0034] The specific implementation steps for changing the Vehicle identity are as follows:

[0035] Step 5-1: The vehicle Vehicle i inputs its currently used identity ID i , and extracts A i and TID i from its storage device, selects a new identity Then calculates and

[0036]

[0037] Step 5-2: Vehicle i generates a timestamp t1, then calculates R i = h(ID i || TID i || A i || S i || t1), and then sends the message Msg9: <TID i , M i , R i , t1> through the common channel to the TA;

[0038] Step 5-3: After receiving the message Msg9, the TA checks the validity of t1. If t1 is invalid, it indicates that Msg9 is not fresh, and the current Vehicle i identity change process is terminated; otherwise, the TA extracts the secret value K from its storage device, and then extracts the 3-tuple (ID according to TID i ​i , TID i , RN i ), and then calculate S i = h(K || RN i ). and

[0039]

[0040] Step 5-4: TA verifies If the two are not equal, terminate the current identity identification change process of the Vehicle i ; otherwise, TA calculates and then uses to update the current triple (ID i , TID i , RN i ).

[0041] Step 5-5: TA generates a timestamp t2, calculates and then sends a message Msg10: <N i , t2> to the Vehicle through the common channel i .

[0042] Step 5-6: After receiving the message Msg10, the Vehicle i checks the validity of t2. If t2 is invalid, indicating that Msg10 is not fresh, terminate the current identity identification change process of the Vehicle i ; otherwise, the Vehicle i calculates and then verifies If the two are not equal, terminate the current identity identification change process of the Vehicle i ; otherwise, the Vehicle i calculates and then uses to update its security parameters (A i , TID i ).

[0043] The specific implementation steps for changing the RSU identity are as follows:

[0044] Step 6-1: The RSU j inputs its currently used identity ID j , selects a new identity , extracts (TID j , A j ) from its memory, and then calculates and

[0045] Step 6-2: RSU j Generate timestamp t1 and calculate R j = h(ID j ||TID j ||A j ||S j ||t1), and then send message Msg11: <TID j , M j , R j , t1> to TA through the common channel;

[0046] Step 6-3: After receiving message Msg11, TA checks the validity of t1. If t1 is invalid, it means Msg11 is not fresh and terminates the current RSU j identity identification change process; otherwise, TA extracts the quadruple (ID j , TID j , RN j , S j ) from its storage device according to TID j and calculate

[0047] Step 6-4: TA checks If the two are not equal, terminate the current RSU j identity identification change process; otherwise, TA calculates Then use to update the quadruple (ID j , TID j , RN j , S j ) in its storage device;

[0048] Step 6-5: TA generates timestamp t2 and calculates Then send message Msg12: <N j , t2> to RSU j through the common channel;

[0049] Step 6-6: After receiving message Msg12, RSU j checks the validity of t2. If t2 is invalid, it means Msg12 is not fresh and terminates the current RSU j identity identification change process; otherwise, RSU j calculates Then checks If the two are not equal, terminate the current RSU j identity identification change process; otherwise, RSU j calculates Then use To update its security parameters (A j ,TID j ).

[0050] The specific steps for tracking and canceling malicious vehicles are as follows:

[0051] Step 7-1: Vehicle i RSU j Send message Msg3:<TID i ,C i ,t3>,RSU j To Vehicle i Send message Msg6:<TID j ,D i ,G j ,A j ,H ij ,t6>, complete Vehicle i and RSU j Two-way authentication;

[0052] Step 7-2: Assume Vehicle i RSU j Send malicious false messages, RSU j Once this malicious fake message is detected, RSU j Extract from its memory (A j ,TID j ), then calculate Since the TA storage device has a quadruple (ID j ,TID j ,RN j ,S j ) stores S j , S j As RSU j Shared key between TA and the client;

[0053] Step 7-3: RSU j Select SHA256 as the hash function, S j As a key, Vehicle i Temporary identity TID i As the plain text of the message to be sent, calculate T = HMAC (S j ,TID i ), the message <TID i ,T>send to TA;

[0054] Step 7-4: Receive message <TID i ,T>,TA recalculates T* = HMAC(S j , TID i ), and then verify T * ? = T. If the two are equal, it indicates that TID i is reported by the RSU j , and during the transmission process, the temporary identity identifier TID of the false message vehicle i has not been tampered with;

[0055] Step 7-5: According to the reported TID i , the TA determines the true identity identifier ID of the malicious vehicle by looking up the triple (ID i , TID i , RN i ) in its memory; i ;

[0056] Step 7-6: To protect the integrity of the data, the TA uses the S stored in its storage device j as the shared key with the RSU j , and uses the same HMAC algorithm to broadcast the warning message Warning: <TID i > to all RSUs j ;

[0057] Step 7-7: After receiving the warning message Warning: <TID j >, the RSU i adds it to the Incremental Certificate Revocation List to complete the revocation of the malicious vehicle Vehicle i ;

[0058] Step 7-8: When the malicious vehicle initiates an authentication request Msg3: <TID i , C i , t3>, the RSU j checks whether the TID i is in its Incremental Certificate Revocation List. If it is, it indicates that Vehicle i is a malicious vehicle, and the authentication operation is terminated.

[0059] Compared with the prior art, the advantages of the present invention are as follows:

[0060] 1. By adopting lightweight Hash and XOR operations, two-way anonymous authentication among Vehicle, RSU, and TA within the trust domain is achieved, as well as session key negotiation between Vehicle and RSU. The present invention can overcome problems such as "single point of failure", key leakage risk, and non-traceability caused by centralized key management in symmetric encryption technology solutions; it can overcome problems such as the inability to control the number of pseudonym certificates, complex operations for addition, deletion, modification, and query, and difficulty in tracing malicious vehicles in anonymous authentication based on PKI; it can overcome prominent problems such as slow signature speed and low efficiency brought by group signature mechanisms, and it can also overcome problems such as key escrow in anonymous identity authentication systems based on identity identifiers, the inability to achieve non-repudiation, and the dependence on a third-party trusted key generation center PKG. Due to the adoption of lightweight operations, small computational overhead, and short exchanged messages, it can meet the fast mutual trust authentication among Vehicle, RSU, and TA in the scenario of high-speed moving and highly dense vehicles.

[0061] 2. The present invention can update the identity identifiers of Vehicle and RSU, preventing attackers from tracking the temporary identity identifiers of vehicles for a long time, inferring the true identity of the vehicle through analysis, and further preventing the tracking of vehicle behavior and location, reducing the risk of system privacy leakage; at the same time, it can also prevent attackers from tracking the temporary identity identifiers of RSU for a long time, inferring the true identity of RSU through analysis, and further preventing attackers from impersonating the identity of RSU and broadcasting false messages to the vehicles covered by its signal to achieve their attack purposes.

[0062] 3. The present invention improves the security performance of the system through the automatic update of the security parameters of Vehicle, RSU, and TA. This mutual trust authentication and session key negotiation method between Vehicle and RSU within the trust domain cleverly embeds the update of the security parameters of Vehicle, RSU, and TA entities into the process of mutual trust authentication and key negotiation between Vehicle and RSU. As long as the mutual trust authentication and session key negotiation between the two are successfully completed once, the security parameters of TA, RSU, and Vehicle will be updated once. Due to the timely update of the security parameters, even if an attacker obtains the security parameters stored in the storage devices of Vehicle and RSU through some method, it is difficult to initiate an attack by impersonating Vehicle or RSU, greatly reducing the probability of a successful impersonation attack.

[0063] 4. Achieve anonymity, as well as effective tracking and revocation of malicious vehicles. The true identities of Vehicle and RSU (ID i and ID j ), the temporary identities of Vehicle and RSU (TID i and TID j), and the random numbers generated by TA for Vehicle and RSU (RN i and RN j ), respectively. The triple (ID i , TID i , RN i ) and the quadruple (ID j , TID j , RN j , S j ) are stored in the storage device of TA. During data transmission, in order not to disclose the real identity of the user, only the temporary identity TID i and TID j are included in the packet header of the sent data packet, realizing the privacy protection of the communication entity identity.

[0064] If the RSU discovers that the Vehicle sends false information to perform malicious acts, the RSU reports the vehicle's temporary identity to the TA in the form of the message authentication code HMAC. The HMAC algorithm is used to ensure the real source of the reported information and prevent it from being tampered with. The TA can query the real identity of the malicious vehicle in the triple (ID i , TID i , RN i ), realizing the effective tracking of the malicious vehicle.

[0065] After the TA identifies the real identity ID i of the vehicle, it broadcasts its temporary identity TID i to all RSUs in the form of the message authentication code HMAC as well (using the message authentication code HMAC is also to ensure that the broadcast message is not tampered with). The RSU adds the temporary identity TID i of the malicious vehicle to its incremental certificate revocation list ICRL, realizing the revocation of the malicious vehicle Vehicle i . When the malicious vehicle Vehicle i attempts to perform malicious acts after completing authentication with a certain RSU, as long as the RSU queries the temporary identity TID i of the vehicle attempting to pass the authentication in its incremental certificate revocation list ICRL, the system terminates the current authentication to prevent the continuous malicious acts of Vehicle i . BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 It is a flowchart of the mutual trust authentication and key negotiation between Vehicle and RSU of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0067] The present invention will be described in detail below in conjunction with the accompanying drawings of the specification and specific embodiments.

[0068] The present invention includes four stages, namely the system initialization stage, the registration stage (including the registration of Vehicle at TA and the registration of RSU at TA), the authentication of RSU and its access to the VANETs system, and the mutual authentication among Vehicle, RSU and TA and the session key negotiation stage between Vehicle and RSU, as Figure 1 shown.

[0069] The first stage: System initialization stage

[0070] The system administrator configures a unique secret value K for TA and stores K in its storage device with tamper-proof and power analysis-resistant capabilities.

[0071] The second stage: Registration stage

[0072] It is used to implement the registration of Vehicle and RSU at TA and prepare for the mutual anonymous authentication between Vehicle and RSU in the next stage.

[0073] 1. Registration of Vehicle at TA

[0074] Step 2-1-1: Vehicle i selects its own unique identity identifier ID i , and sends the registration request <ID i > to TA through a secure channel;

[0075] Step 2-1-2: After receiving the registration request of Vehicle i , TA generates a random number RN i for Vehicle i , calculates the temporary identity identifier i of Vehicle and S i = h(K||RN i ), and stores the triple (ID i , TID i , RN i ) in its storage device with tamper-proof and power analysis-resistant capabilities;

[0076] Step 2-1-3: TA calculates and sends the registration response <TID i , A i > to the Vehicle i to be registered through a secure channel;

[0077] Step 2-1-4: After receiving the registration response <TID i , A i >, Vehiclei The security parameters (TID i ,A i ) is stored in its storage device.

[0078] 2. Registration of RSUs

[0079] Step 2-2-1: RSU j Choose your own unique ID j , and then send the registration request message <ID j >Send to TA via secure channel;

[0080] Step 2-2-2: Receive registration request message <ID j >After that, TA is RSU j Generate a random number RN j , calculate RSU j Temporary identity card and S j =h(K||RN j ), and the four-tuple (ID j ,TID j ,RN j ,S j ) is stored in a storage device that is tamper-proof and resistant to power consumption analysis;

[0081] Step 2-2-3: TA calculation Then the registration response <TID j ,A j >Send to RSU j ;

[0082] Step 2-2-4: Register for RSU j Received TA's registration response <TID j ,A j >After that, the security parameters (TID j ,A j ) is stored in its storage device.

[0083] Phase 3: RSU authentication and access to VANETs system

[0084] Step 3-1: RSU j Enter its ID j , generate timestamp t1, calculate B j =h(TID j ||RN j ), and D j =h(TID j ||A j ||Cj ||t1), and then send an authentication request message Msg1: <TID j , D j , t1> to TA through the common channel;

[0085] Step 3-2: After receiving Msg1, TA checks the validity of t1; if it is invalid, it means Msg1 is not fresh, and the system immediately terminates the authentication of the RSU j ; if t1 is valid, then check whether TID j is in its storage device. If it does not exist, it means the RSU j has not been registered yet, and the RSU j is prohibited from accessing the VANETs system; otherwise, TA extracts the quadruple (ID j , TID j , RN j , S j ) from its storage device according to TID j , and calculate B j = h(TID j ||RN j ), and verify If the two are not equal, terminate the authentication of the RSU j ; if the two are equal, the RSU j is authenticated by TA;

[0086] Step 3-3: TA generates a timestamp t2, calculates F j = h(TID j ||S j ||E j ||t2), and then sends a message Msg2: <E j , F j , t2> to the RSU through the common channel; j ;

[0087] Step 3-4: After receiving the message Msg2, the RSU j checks the validity of t2; if t2 is invalid, it means Msg2 is not fresh, and terminates the current authentication process; if t2 is valid, calculate and then verify If the two are not equal, terminate the current authentication process; otherwise, if the two are equal, TA is authenticated by the RSU j , and the system allows the RSU j to access the VANETs system; the RSU jAfter accessing the VANETs system, broadcast the "Ready" message to the Vehicles covered by it.

[0088] The fourth stage: Two-way authentication among Vehicle, RSU, and TA, session key negotiation between Vehicle and RSU, and system configuration parameter update stage

[0089] Step 4-1: When receiving the "Ready" message, Vehicle i inputs its identity identifier ID i , generates a timestamp t3, and then calculates B i = h(TID i ||RN i ) and C i = h(TID i ||A i ||B i ||t3), and then sends the message Msg3: <TID j ,C i ,t3> to the RSU; i

[0090] Step 4-2: When receiving Msg3, the RSU j checks the validity of t3; if t3 is invalid, it indicates that Msg3 is not fresh and terminates the current authentication process; if t3 is valid, the RSU j extracts TID from its memory j , generates a timestamp t4, and sends the message Msg4: <TID i ,TID j ,C i ,t3,t4> to the TA through the common channel;

[0091] Step 4-3: After receiving Msg4, the TA checks whether the timestamp t4 is valid. If t4 is invalid, it indicates that Msg4 is not fresh and terminates the current authentication process; if t4 is valid, the TA finds and extracts the triple (ID i ,TID i ,RN i ) from its memory according to TID i , and then calculates S i = h(K||RN i ), B i = h(TID i ||RN i ) and and checks If they are not equal, terminate the current authentication and key negotiation process; otherwise, the TA generates for the Vehicle iand RSU j Generate random numbers respectively and Then calculate Generate timestamp t5, and then send message Msg5: <D j , G i , j , t5> to RSU through the common channel;

[0092] Step 4-4: After receiving Msg5, RSU j Check whether the timestamp t5 is valid. If t5 is invalid, it indicates that Msg5 is not fresh, and terminate the current authentication and key negotiation process; otherwise, RSU j Extract A j , TID j and S j from its memory, and calculate Then RSU j Generates timestamp t6, calculates H ij = h(D i || G j || SK ij || t6), and sends message Msg6: <TID i , D j , G i , A j , H j , t6> to Vehicle through the common channel; ij ;

[0093] Step 4-5: After receiving message Msg6, Vehicle i Check whether the timestamp t6 is valid. If t6 is invalid, it indicates that the received Msg6 is not fresh, and terminate the current authentication and key negotiation process; otherwise, Vehicle i Extract A i and TID i from its storage device, and calculate and Verify If the two are not equal, terminate the current authentication and key negotiation process; otherwise, Vehicle i Calculates Replace (A , TID i ) with i , then generate timestamp t7, calculate and send message Msg7: <L j , t7> to RSU through the common channel; ij ;

[0094] Step 4-6: After receiving the message Msg7, the RSU j checks whether the timestamp t7 is valid. If t7 is invalid, it indicates that Msg7 is not fresh, and the current authentication and key negotiation process is terminated; otherwise, calculate and Then verify If the two are not equal, the current authentication and key negotiation process is terminated; otherwise, the RSU j calculates Then use to replace (A j , TID j ), The RSU j generates a timestamp t8 and sends a message Msg8 to the TA through the common channel: <S j , G j , t8>;

[0095] Step 4-7: After receiving the message Msg8, the TA checks whether the timestamp t8 is valid. If t8 is invalid, it indicates that the received Msg8 is not fresh, and the current authentication and key negotiation process is terminated; otherwise, the TA checks TID i and TID j whether they both exist in its memory. If TID i and TID j any one does not exist, the current authentication and key negotiation process is terminated; otherwise the TA calculates Then, the TA uses to replace the (ID i , TID i , RN i ) stored in its memory respectively, and uses to replace the (ID j , TID j , RN j , S j ) stored in its memory.

[0096] Implementation method of key features

[0097] 1. Change of Vehicle identity identifier

[0098] To improve the security of the system, prevent attackers from tracking the temporary identity identifier of the vehicle for a long time, infer the real identity of the vehicle through analysis, and thus prevent attackers from tracking the behavior and location of the vehicle and reduce the risk of vehicle user privacy leakage. The specific implementation steps are as follows:

[0099] Step 5-1: The vehicle Vehicle i inputs its currently used identity identifier ID i, and extract A from its storage device i and TID i , select a new identity Then calculate and

[0100]

[0101] Step 5-2: Vehicle i Generate a timestamp t1, and then calculate R i = h(ID i ||TID i ||A i ||S i ||t1), and then send a message Msg9: <TID i , M i , R i , t1> to TA through the public channel;

[0102] Step 5-3: After receiving the message Msg9, TA checks the validity of t1. If t1 is invalid, indicating that Msg9 is not fresh, then terminate the current identity change process of Vehicle i ; otherwise, TA extracts the secret value K from its storage device, and then extracts the 3-tuple (ID i , TID i , RN i , RN i ) according to TID i = h(K||RN i ), and

[0103]

[0104] Step 5-4: TA checks If the two are not equal, then terminate the current identity change process of Vehicle i ; otherwise, TA calculates Then use to update the current triple (ID i , TID i , RN i );

[0105] Step 5-5: TA generates a timestamp t2, calculates Then send a message Msg10: <N i , t2> to Vehicle i through the public channel;

[0106] Step 5-6: After receiving the message Msg10, Vehiclei Check the validity of t2. If t2 is invalid, it indicates that Msg10 is not fresh, and then terminate the current identity identification change process of the Vehicle i ; otherwise, the Vehicle i Calculate Then check If they are not equal, terminate the current identity identification change process of the Vehicle i ; otherwise, the Vehicle i Calculate Then use to update its security parameters (A i , TID i ).

[0107] 2. Change of RSU Identity Identification

[0108] To improve the security of the system and prevent attackers from tracking the temporary identity identification of the RSU for a long time, and through analysis to speculate the true identity of the RSU, and then prevent attackers from forging the identity of the RSU and broadcasting false messages to the vehicles covered by its signal to achieve their attack purposes. The specific implementation steps are as follows:

[0109] Step 6-1: The RSU j inputs its currently used identity identification ID j , and selects a new identity identification Extracts (TID j , A j ) from its memory, and then calculates and

[0110] Step 6-2: The RSU j generates a timestamp t1, calculates R j = h(ID j || TID j || A j || S j || t1), and then sends a message Msg11: <TID j , M j , R j , t1> to the TA through the common channel;

[0111] Step 6-3: After receiving the message Msg11, the TA checks the validity of t1. If t1 is invalid, it indicates that Msg11 is not fresh, and terminates the current identity identification change process of the RSU j ; otherwise, the TA extracts the quadruple (ID j from its storage device according to TID j , TIDj , RN j , S j ), calculate

[0112] Step 6-4: TA verification If the two are not equal, terminate the current RSU j identity identification change process; otherwise, TA calculates Then use to update the quadruple (ID j , TID j , RN j , S j ) in its storage device;

[0113] Step 6-5: TA generates timestamp t2 and calculates Then sends message Msg12: <N j , t2> to the RSU through the common channel j ;

[0114] Step 6-6: After receiving message Msg12, the RSU j checks the validity of t2. If t2 is invalid, it indicates that Msg12 is not fresh and terminates the current RSU j identity identification change process; otherwise, the RSU j calculates Then verifies If the two are not equal, terminate the current RSU j identity identification change process; otherwise, the RSU j calculates Then uses to update its security parameters (A j , TID j ).

[0115] 3. Tracking and revocation of malicious vehicles

[0116] Step 7-1: Vehicle Vehicle i sends message Msg3: <TID j , C i , t3> to the RSU. The RSU i sends message Msg6: <TID j , D i , G j , A i , H j , t6> to Vehicle j , completing Vehicle ij and RSU i and RSUj Mutual authentication;

[0117] Step 7-2: Assume Vehicle i sends a malicious false message to the RSU j . Once the RSU detects this malicious false message, j the RSU j extracts (A j , TID j ) from its memory, and then calculates Since the quadruple (ID j , TID j , RN j , S j ) is stored in the TA storage device with S j , S j is used as the shared key between the RSU j and the TA;

[0118] Step 7-3: The RSU j selects SHA256 as the hash function, S j as the key, and the temporary identity identifier TID i of the Vehicle i as the plaintext of the message to be sent. Through the HMAC algorithm, it calculates T = HMAC(S j , TID i ), and sends the message <TID i , T> to the TA;

[0119] Step 7-4: After receiving the message <TID i , T>, the TA recalculates T * = HMAC(S j , TID i ), and then checks whether T * ? = T. If the two are equal, it indicates that TID i is reported by the RSU j , and during the transmission process, the temporary identity identifier TID i of the false message vehicle has not been tampered with;

[0120] Step 7-5: According to the reported TID i , the TA determines the true identity identifier ID i of the malicious vehicle by looking up the triple (ID i , TID i , RN i ) in its memory;

[0121] Step 7-6: To protect the integrity of the data, the TA stores the S stored in its storage device jAs the shared key with the RSU j Adopt the same HMAC algorithm to broadcast the warning message Warning: <TID i > to all RSUs j ;

[0122] Step 7-7: After the RSU j receives the warning message Warning: <TID i >, add it to the Increasement Certificate Revocation List to complete the revocation of the malicious vehicle Vehicle i ;

[0123] Step 7-8: When the malicious vehicle initiates an authentication request Msg3: <TID i ,C i ,t3>, the RSU j checks whether the TID i is in its Increasement Certificate Revocation List. If it is, it indicates that Vehicle i is a malicious vehicle and terminates the authentication operation.

Claims

1. A lightweight, anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method, characterized in that It includes the following four stages: system initialization stage, registration stage, RSU authentication and access to VANETs system, as well as two-way authentication between Vehicle, RSU and TA and session key negotiation between Vehicle and RSU. In the system initialization stage: the system administrator configures a unique secret value K for TA and stores K in its storage device with tamper-proof and power consumption analysis protection; the registration stage is used to realize the registration of Vehicle and RSU in TA.

2. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that The registration of Vehicle with TA includes the following steps: Step 2-1-1: Vehicle i Choose your own unique ID i , register the request <ID i >Send to TA via secure channel; Step 2-1-2: After receiving the Vehicle i After the registration request, TA is Vehicle i Generate a random number RN i , calculate Vehicle i Temporary identity card and S i =h(K||RN i ), and the triple (ID i ,TID i ,RN i ) is stored in a storage device that is tamper-proof and resistant to power consumption analysis; Step 2-1-3: TA calculation And send the registration response <TID through the secure channel i ,A i >Send to the Vehicle to be registered i ; Step 2-1-4: Receive registration response <TID i ,A i >Later, Vehicle i The security parameters (TID i ,A i ) is stored in its storage device.

3. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that Registration of RSUs involves the following steps: Step 2-2-1: RSU j Choose your own unique ID j , and then send the registration request message <ID j >Send to TA via secure channel; Step 2-2-2: Receive registration request message <ID j >After that, TA is RSU j Generate a random number RN j , calculate RSU j Temporary identity card and S j =h(K||RN j ), and the four-tuple (ID j ,TID j ,RN j ,S j ) is stored in a storage device that is tamper-proof and resistant to power consumption analysis; Step 2-2-3: TA calculation Then the registration response <TID j ,A j >Send to RSU j ; Step 2-2-4: Register RSU j Received TA's registration response <TID j ,A j >After that, the security parameters (TID j ,A j ) is stored in its storage device.

4. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that The RSU authentication and access to the VANETs system specifically includes the following steps: Step 3-1: RSU j Enter its ID j , generate timestamp t1, calculate B j =h(TID j ||RN j ), and D j =h(TID j ||A j ||C j ||t1), and then send an authentication request message Msg1:<TID to TA through the public channel j ,D j ,t1>; Step 3-2: After receiving Msg1, TA checks the validity of t1; if it is invalid, it means that Msg1 is not fresh, and the system immediately terminates RSU j authentication; if t1 is valid, then check TID j Is it in its storage device? If not, it indicates that RSU j Not registered yet, RSU prohibited j Connect to the VANETs system; otherwise, TA will j Extract the quadruple (ID j ,TID j ,RN j ,S j ),calculate B j =h(TID j ||RN j ), as well as And check If the two are not equal, the RSU is terminated. j If the two are equal, then RSU j Certified by TA; Step 3-3: TA generates timestamp t2 and calculates F j =h(TID j ||S j ||E j ||t2), and then send the signal to RSU through the public channel. j Send message Msg2:<E j ,F j ,t2>; Step 3-4: After receiving message Msg2, RSU j Check the validity of t2; if t2 is invalid, it means that Msg2 is not fresh and terminate the current authentication process; if t2 is valid, calculate Then check If the two are not equal, the current authentication process is terminated; otherwise, if the two are equal, TA is RSU j Authentication, the system allows RSU j Access to VANETs system; RSU j After accessing the VANETs system, it broadcasts a "Ready" message to the covered Vehicles.

5. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that The two-way authentication of Vehicle, RSU and TA, the negotiation of session keys between Vehicle and RSU, and the update of system configuration parameters specifically include the following steps: Step 4-1: After receiving the "Ready" message, Vehicle i Enter its ID i , generate timestamp t3, and then calculate B i =h(TID i ||RN i ) and C i =h(TID i ||A i ||B i ||t3), then to RSU j Send message Msg3:<TID i ,C i ,t3>; Step 4-2: After receiving Msg3, RSU j Check the validity of t3; if t3 is invalid, it means Msg3 is not fresh and terminate the current authentication process; if t3 is valid, RSU j Extract the TID from its memory j , generate timestamp t4, and send message Msg4 to TA through the public channel: <TID i ,TID j ,C i ,t3,t4>; Step 4-3: After receiving Msg4, TA checks whether the timestamp t4 is valid. If t4 is invalid, it indicates that Msg4 is not fresh, and terminates the current authentication process; If t4 is valid, TA will i Find and extract the triple (ID i ,TID i ,RN i ), then calculate S i =h(K||RN i ), B i =h(TID i ||RN i )as well as And check If the two are not equal, the current authentication and key negotiation process is terminated; Otherwise, TA is Vehicle i and RSU j Generate random numbers separately and Then calculate Generate timestamp t5 and then send it to RSU through the public channel j Send message Msg5:<D i ,G j ,t5>; Step 4-4: After receiving Msg5, RSU j Check whether the timestamp t5 is valid. If t5 is invalid, it means that Msg5 is not fresh, and terminate the current authentication and key negotiation process; otherwise , RSU j Extract A from its memory j , TID j and Sj, calculated, Then RSU j Generate timestamp t6 and calculate H ij =h(D i ||G j ||SK ij ||t6) and send the message to Vehicle through the public channel i Send message Msg6:<TID j ,D i ,G j ,A j ,H ij ,t6>; Step 4-5: After receiving message Msg6, Vehicle i Check whether the timestamp t6 is valid. If t6 is invalid, it means that the received Msg6 is not fresh, and terminate the current authentication and key negotiation process; otherwise, Vehicle i Extract A from its storage device i and TID i ,calculate as well as Inspection If the two are not equal, the current authentication and key negotiation process is terminated; otherwise, Vehicle i calculate use Replace (A i ,TID i ), then generate timestamp t7, calculate And send it to RSU through the public channel j Send message Msg7:<L ij ,t7>; Step 4-6: After receiving message Msg7, RSU j Check whether the timestamp t7 is valid. If t7 is invalid, it means that Msg7 is not fresh, and the current authentication and key negotiation process is terminated; otherwise, calculate as well as Then check If the two are not equal, the current authentication and key negotiation process is terminated; Otherwise, RSU j calculate Then use To replace (A j ,TID j ), RSU j Generate timestamp t8 and send message Msg8 to TA through the public channel: j ,G j ,t8>; Step 4-7: After receiving the message Msg8, TA checks whether the timestamp t8 is valid. If t8 is invalid, it indicates that the received Msg8 is not fresh, and the current authentication and key negotiation process is terminated; Otherwise, TA checks TID i and TID j Are they all present in its memory? If TID i and TID j If any of them does not exist, the current authentication and key negotiation process is terminated; otherwise, TA calculates Then, TA used To replace the (ID i ,TID i ,RN i ),use To replace the (ID j ,TID j ,RN j ,S j ).

6. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that The specific steps to change the Vehicle identity are as follows: Step 5-1: Vehicle i Enter the current identity ID i and extract A from its storage device i and TID i , select a new identity Then calculate as well as Step 5-2: Vehicle i Generate timestamp t1, then calculate R i =h(ID i ||TID i ||A i ||S i ||t1), and then send message Msg9 to TA through the public channel: <TID i ,M i ,R i ,t1>; Step 5-3: After receiving message Msg9, TA checks the validity of t1. If t1 is invalid, it means that Msg9 is not fresh, and the current Vehicle is terminated. i Otherwise, TA extracts the secret value K from its storage device and then changes the identity according to TID i Extract 3-tuple (ID i ,TID i ,RN i ), then calculate S i =h(K||RN i ), as well as Step 5-4: TA verification If the two are not equal, terminate the current Vehicle i The identity change process; Otherwise, TA calculates Then use To update the current triple (ID i ,TID i ,RN i ); Step 5-5: TA generates timestamp t2 and calculates Then send the message to Vehicle through the public channel. i Send message Msg10:<N i ,t2>; Step 5-6: After receiving message Msg10, Vehicle i Check the validity of t2. If t2 is invalid, it means Msg10 is not fresh, then terminate the current Vehicle. i Otherwise, Vehicle i calculate Then check If the two are not equal, terminate the current Vehicle i Otherwise, Vehicle i calculate Then use To update its security parameters (A i ,TID i ).

7. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that The specific steps to change the RSU identity are as follows: Step 6-1: RSU j Enter the current identity ID j , select a new identity Extract from its memory (TID j ,A j ), and then calculate as well as Step 6-2: RSU j Generate timestamp t1 and calculate R j =h(ID j ||TID j ||A j ||S j ||t1), and then send message Msg11 to TA through the public channel: <TID j ,M j ,R j ,t1>; Step 6-3: After receiving the message Msg11, TA checks the validity of t1. If t1 is invalid, it means that Msg11 is not fresh and terminates the current RSU. j Identity change process; Otherwise, TA will send the j Extract the quad from its storage device (ID j ,TID j ,RN j ,S j ),calculate Step 6-4: TA verification If the two are not equal, the current RSU is terminated j Identity change process; Otherwise, TA calculates Then use To update the quadruple (ID j ,TID j ,RN j ,S j ); Step 6-5: TA generates timestamp t2 and calculates Then send the signal to RSU through the public channel j Send message Msg12:<N j ,t2>; Step 6-6: After receiving message Msg12, RSU j Check the validity of t2. If t2 is invalid, it means that Msg12 is not fresh and terminate the current RSU. j The process of changing the identity; Otherwise, RSU j calculate Then check If the two are not equal, the current RSU is terminated j Identity change process; Otherwise, RSU j calculate Then use To update its security parameters (A j ,TID j ).

8. A lightweight anonymous, traceable and revocable VANETs mutual trust authentication and key agreement method according to claim 1, characterized in that The specific steps for tracking and canceling malicious vehicles are as follows: Step 7-1: Vehicle i RSU j Send message Msg3:<TID i ,C i ,t3>,RSU j To Vehicle i Send message Msg6:<TID j ,D i ,G j ,A j ,H ij ,t6>, complete Vehicle i and RSU j Two-way authentication; Step 7-2: Assume Vehicle i RSU j Send malicious false messages, RSU j Once this malicious fake message is detected, RSU j Extract from its memory (A j ,TID j ), and then calculate Since the TA storage device has a quadruple (ID j ,TID j ,RN j ,S j ) stores S j , S j As RSU j Shared key between TA and the client; Step 7-3: RSU j Select SHA256 as the hash function, S j As a key, Vehicle i Temporary identity TID i As the plain text of the message to be sent, calculate T = HMAC (S j ,TID i ), the message <TID i ,T>send to TA; Step 7-4: Receive message <TID i ,T>,TA recalculates T * =HMAC(S j ,TID i ), then check T * ? = T, if the two are equal, it means TID i By RSU j Report, and during the transmission process, the temporary identity TID of the false message vehicle i has not been tampered with; Step 7-5: According to the reported TID i , TA searches for the triple (ID i ,TID i ,RN i ) to determine the real ID of the malicious vehicle i ; Step 7-6: To protect the integrity of the data, TA stores the S j As with RSU j The shared key between the two uses the same HMAC algorithm and sends the warning message Warning: <TID i > Broadcast to all RSUs j ; Step 7-7: RSU j Received warning message Warning: <TID i >After that, add it to the incremental certificate revocation list to complete the revocation of the malicious vehicle. i revocation of Step 7-8: Initiate authentication request as a malicious vehicle Msg3: <TID i ,C i ,t3>,RSU j Check TID i Is the vehicle in its incremental certificate revocation list? If so, it indicates that the vehicle i For malicious vehicles, the authentication operation is terminated.