A method for V2R mutual authentication and session key negotiation

Abstract

The application discloses a V2R mutual trust authentication and session key negotiation method, and relates to the field of secure communication.The method comprises the following steps: selecting the identity, password and key of a vehicle and a road side unit; completing vehicle registration based on the identity, password, first challenge and first response of the selected vehicle; completing road side unit registration based on the identity and key of the selected road side unit; obtaining and storing vehicle and road side unit registration information; completing vehicle access identity authentication based on the identity and password of the vehicle and the vehicle registration information; and completing identity mutual trust authentication and session key negotiation between the vehicle and the road side unit through authentication message interaction between the vehicle and the road side unit and verification of to-be-verified parameters in the authentication message.The trusted center of the application is only used for registration of the vehicle and the road side unit and tracking and revocation of malicious communication entities, the number and length of authentication message transfer are reduced, and the security and efficiency of authentication are improved.

Description

Technical Field

[0001] This application relates to the field of secure communication, and in particular to a V2R mutual trust authentication and session key negotiation method. Background Technology

[0002] In the Internet of Vehicles (IoV), vehicles and roadside units (Roadside Units, RSUs) exchange data and share information to update road conditions, traffic congestion, vehicle locations, and lane capacity, thereby improving traffic efficiency, preventing collisions and accidents, and ensuring traffic safety. However, the information exchange between vehicles and between vehicles and RSUs uses public wireless channels, making it vulnerable to serious security threats such as identity spoofing, information interception, information tampering, fake message injection, and leakage of privacy and sensitive information. Currently, identity authentication and key negotiation schemes are often used to address this issue. From a technical perspective, current solutions require a Trusted Authority (TA) to directly participate in authentication, achieving mutual trust authentication through information exchange between vehicles, TAs, and Roadside Units (RSUs). However, this authentication method involves a large number of messages and a long number of bits exchanged, resulting in a longer time required to complete mutual trust authentication, which is not conducive to the timely communication requirements of IoV scenarios. More seriously, in high-speed, high-density vehicle scenarios, the TA (Transmission Controller) bears a very heavy burden, easily causing "single points of failure," severely reducing communication speed, and is detrimental to the vehicle-to-everything (V2X) environment where vehicles move at high speeds and the topology changes rapidly. Moreover, current solutions are often computationally complex and have high computational overhead. How to adopt lightweight computing, preventing the TA from directly participating in V2R (Vehicle-to-Relational) identity mutual trust authentication, and instead using it only for vehicle and RUS (Roadside Controller) registration, as well as tracking and revoking the identities of malicious communication entities, thereby reducing computational overhead, decreasing the number and length of message forwarding, reducing communication overhead, and improving authentication efficiency, has become a pressing technical problem to be solved in this field. Summary of the Invention

[0003] The purpose of this application is to provide a V2R mutual trust authentication and session key negotiation method, which enables TA to be used only for vehicle and RUS registration, as well as for tracking and revoking the identity of malicious communication entities, thereby reducing computational overhead, reducing the number and length of authentication message forwarding, reducing communication overhead, and improving the efficiency of V2R mutual trust authentication and key negotiation.

[0004] To achieve the above objectives, this application provides the following solution:

[0005] Firstly, this application provides a V2R mutual trust authentication and session key negotiation method, including:

[0006] The vehicle selects its own identity and password, and generates a binary string as a challenge. Based on the selected vehicle identity and password, the challenge and response of the non-cloning function, the vehicle registration is completed, and the vehicle registration information is obtained and stored. The vehicle registration process is realized by the vehicle and the trusted center through information exchange.

[0007] The roadside unit selects its own identity and key, and completes the roadside unit registration based on the identity and key, obtaining and storing the roadside unit registration information; the roadside unit registration process is realized by the roadside unit and the trusted center through information interaction;

[0008] Based on the vehicle's identity identifier and password, and vehicle registration information, vehicle access authentication is completed. Through authentication message interaction between the vehicle and the roadside unit, and verification of the parameters to be verified in the authentication message, mutual trust authentication and session key negotiation between the vehicle and the roadside unit are completed. After the mutual trust authentication between the vehicle and the roadside unit is successful, the trusted center tracks and revokes the true identity of the malicious communication entity.

[0009] Optionally, the vehicle selects its own identity and password, and generates a binary string as a challenge. Based on the selected vehicle identity and password, the challenge and response of the non-cloning function, the vehicle registration is completed, and the vehicle registration information is obtained and stored, including:

[0010] Vehicles select their own identification ID i and key PW i And generate the first binary string.

[0011] The first binary string The first challenge of non-clonable functions The first response is obtained through a non-clonable function embedded in the vehicle.

[0012] Based on vehicle identification ID i Password PW i The first challenge and first response Complete the registration request reqv; And send the registration request reqv to the Trusted Center;

[0013] Upon receiving the registration request (reqv), the Trust Center checks its database to see if the vehicle's identity ID exists. i ;

[0014] If it exists, it indicates that the identity ID is correct. i If the vehicle has already been used by another vehicle, notify the vehicle to select a new identification identifier.

[0015] If it does not exist, the Trust Center is based on the first challenge. Vehicle Identification ID i and password PW i and first response Generate the vehicle registration response res1 and send the registration response res1 to the vehicle;

[0016] The vehicle generates vehicle registration information based on the registration response res1; the vehicle registration information includes: the association parameter X between the vehicle and the trusted center. i Vehicle authentication parameters Ver i Misidentification of vehicles (MID) i The correlation parameter Rel between the trusted center and the roadside unit i And the first challenge

[0017] Optionally, the roadside unit selects its own identity and key, and completes roadside unit registration based on the identity and key, obtaining and storing roadside unit registration information, including:

[0018] Roadside units select their own identification ID j and key K j , key K j The data is stored in the immutable TPM module of the roadside unit, based on the selected identity ID. j and key K j Generate a registration request (reqr) for the roadside unit and send the registration request (reqr) to the trusted center;

[0019] After receiving the registration request (reqr), the trusted center checks whether the roadside unit's identity ID exists in its database. j ;

[0020] If it exists, it indicates the selected identity ID. j If the identity has already been used by other roadside units, the trusted center can notify the roadside unit to reselect its identity.

[0021] If it does not exist, the trusted center will assign the roadside unit's identification ID. j and key K j Stored in its database; subsequently, a trusted center generates a random number RN. ta and in random number RN ta Based on this, construct the registered response res2 of the roadside unit; res2=<RN ta ,W>, This is an intermediate temporary variable; the registration response res2 is sent to the roadside unit.

[0022] After receiving the registration response res2, the roadside unit stores the registration information (ID). j (,Y,W), where, It is also an intermediate temporary variable.

[0023] Optionally, based on the vehicle's identity identifier and password, and vehicle registration information, vehicle access authentication is completed. Through authentication message exchange between the vehicle and the roadside unit, and verification of the parameters to be verified in the authentication message, mutual trust authentication and session key negotiation between the vehicle and the roadside unit are completed, including:

[0024] Enter the vehicle's real identification ID i and password PW i It then retrieves the vehicle registration information from the vehicle's memory and determines the vehicle's pseudo-identity identifier (PID) based on the retrieved vehicle registration information. i Roadside Unit and Trusted Center Key K ta The relevant temporary parameter W k and the key K with the roadside unit j The relevant temporary parameter V j ;

[0025] Based on the association parameter X between vehicles and trusted centers i and the key K with the roadside unit j The relevant temporary parameter V j Determine the vehicle's verification parameters Ver i ;

[0026] Verification parameters for determining the vehicle i Whether it is equal to the vehicle's identity verification parameters in the vehicle registration information, i.e. The first judgment result is obtained; ? = indicates whether it is equal;

[0027] If the first judgment result is yes, then the second binary string is generated. and the second binary string As a challenge for non-clonable functions, obtaining a second response

[0028] Generate the first timestamp t1, and based on the vehicle's pseudo-identity PID i Roadside unit identification ID j , and the trusted central key K ta The relevant temporary parameter W k Second binary string Second Response and the Rel parameter, which is the correlation between the trusted center and the roadside unit. iGenerate a first authentication message Msg1; the first authentication message Msg1 includes: the vehicle's obfuscated identity identifier (MID). i The first temporary parameter A1, the first authentication parameter A2, and the first timestamp t1 in the authentication and key negotiation process;

[0029] After receiving the first authentication message Msg1, the roadside unit determines the validity of the first timestamp t1 in the first authentication message Msg1;

[0030] When the first timestamp t1 is valid, the roadside unit uses key K. j Misidentification of vehicles (MID) i Decryption is performed, and the second authentication parameters in the identity authentication and key negotiation process are determined based on the decrypted parameters. in h() represents a hash function;

[0031] Determine whether the first authentication parameter A2 in the identity mutual trust authentication and key negotiation process is consistent with the second authentication parameter in the identity authentication and key negotiation process. If they are equal, the second judgment result is obtained;

[0032] When the second judgment result is yes, the roadside unit completes the vehicle's identity authentication;

[0033] Roadside units are based on the vehicle's pseudo-identity identifier (PID). i Vehicle password PW i First binary string First Response Second binary string Second response Identify new confusing identifiers for vehicles And the second temporary parameter B1 in the authentication and key negotiation process between the vehicle and the roadside unit;

[0034] The roadside unit generates a second timestamp t2, based on the vehicle's pseudo-identity identifier PID. i , and the trusted central key K ta The relevant temporary parameter W k Key K with roadside unit j The relevant temporary parameter V j First binary string Second binary string The second timestamp t2 and the vehicle's new obfuscated identity identifier A second authentication message Msg2 is generated and sent to the vehicle. The second authentication message Msg2 includes: a second temporary parameter B1 during the authentication and key negotiation process between the vehicle and the roadside unit, a third authentication parameter B2 during the same process, and a second timestamp t2. The roadside unit determines the session key SK. ij ,in,

[0035] After receiving the second authentication message Msg2, the vehicle determines the validity of the second timestamp t2; when the second timestamp t2 is valid, the vehicle uses its pseudo-identity identifier PID. i , and the trusted central key K ta The relevant temporary parameter W k Key K with roadside unit j The relevant temporary parameter V j First binary string Second binary string Determine the fourth authentication parameter in the authentication and key negotiation process between the vehicle and the roadside unit. in,

[0036] Determine whether the third authentication parameter B2 in the mutual trust authentication and key negotiation process between the vehicle and the roadside unit is related to the fourth authentication parameter in the same process. If they are equal, the third judgment result is obtained;

[0037] When the third judgment result is yes, the vehicle completes the authentication of the roadside unit; the vehicle determines its session key SK. ij ,in, And use a new, confusing identifier for the vehicle. Update the obfuscated identity MID stored in its memory. i .

[0038] Optionally, after mutual trust authentication between the vehicle and the roadside unit is successful, the trusted center tracks and revokes the true identity of the malicious communication entity, including:

[0039] The roadside unit receives the first authentication message Msg1 sent by the vehicle and, based on the vehicle's pseudo-identity identifier PID... i Roadside unit identification ID j Roadside Unit and Trusted Center Key K ta The relevant temporary parameter W k Second binary string Second Response And the first hash value is determined by the first timestamp t1.

[0040] Determine the first hash value The fourth judgment result is obtained by determining whether the first authentication parameter A2 in the process of mutual trust authentication and session key negotiation between the vehicle and the roadside unit is equal.

[0041] When the fourth judgment result is negative, the vehicle's identity cannot be authenticated, and the received first authentication message Msg1 is discarded.

[0042] When the fourth determination result is yes, the vehicle's identity is authenticated by the roadside unit. The roadside unit determines and records the vehicle's confused identity identifier (MID) based on the received first authentication message Msg1. i ;

[0043] When a vehicle is detected sending false / malicious messages, the roadside unit will use the vehicle's Obfuscated Identity (MID). i Add it to the incremental obfuscated identity revocation list (IMRL) of the roadside unit, and based on its own identity ID. j and key K j And the vehicle's misidentification identifier (MID) i Calculate the second hash value V ta , where V ta =h(MID) i ||ID j ||K j ), and based on the second hash value V ta Misidentification of vehicles (MID) i Generate a revocation message Revo, where Revo = <MID i V ta > and send the revocation message Revo to the Trusted Center;

[0044] Upon receiving the Revo message, the Trusted Center retrieves the roadside unit's identification ID from its database. j and key K j The third hash value is determined based on the revocation message. in, And determine the third hash value Is it related to the second hash value V? ta If they are equal, we arrive at the fifth judgment result;

[0045] When the fifth judgment result is yes, the trusted center uses its key K. ta Decrypt the obfuscated identity (MID) of the vehicle in the Revo revocation message. i Obtain the vehicle's pseudo-identity identifier (PID). i And based on the vehicle's pseudo-identity identifier PID i Query the vehicle's real identity ID iDoes binary data (ID) exist? i ,PID i The binary data includes the vehicle's real identity identifier ID. i And the vehicle's false identification PID i ;

[0046] When a fake vehicle ID (PID) is detected i There are binary data (ID) i ,PID i When this happens, the Trust Center determines the true identity ID of the vehicle sending the false / malicious message. i Complete the tracking of vehicles sending false / malicious messages and generate a broadcast message CMID. i ;in, Indicates the use of a trusted center's key K ta Perform encryption operations on *;

[0047] Trust Center will broadcast CMID messages i Broadcast to all roadside units except the one that reported the cancellation message;

[0048] Received broadcast message CMID i Subsequently, the roadside unit extracts its key K from its tamper-proof module TPM. j Extract (ID) from its memory j (,Y,W), then according to K temp =h(ID) j ||RN ta ), Calculate and obtain the key K of the trusted center. ta and with K ta The received broadcast message CMID i Decryption is performed to obtain the obfuscated identity (MID) of the vehicle sending the false / malicious message. i and the decrypted vehicle's obfuscated identity identifier (MID) i Add it to its incremental obfuscated identity removal list (IMRL);

[0049] When a vehicle sending a false message sends a first authentication message Msg1 to other roadside units, the roadside unit, upon receiving Msg1, checks the vehicle's obfuscated identity identifier (MID). i Check if the vehicle is in its Incremental Obfuscated Identity Revocation List (IMRL); if it is not in the IML, it indicates that the vehicle is a normal vehicle; if it is in the IML, it indicates that the vehicle has been revoked, and identity authentication is terminated.

[0050] Optionally, before selecting a vehicle identifier and password, completing vehicle registration based on the selected vehicle identifier and password, and obtaining and storing vehicle registration information, the V2R mutual trust authentication and session key negotiation method further includes:

[0051] Complete the pre-setting of the trusted center key and the roadside unit key, and complete the embedding of the non-clonable device in the vehicle; the non-clonable device contains non-clonable functions.

[0052] Choose a one-way hash function and a symmetric encryption / decryption standard.

[0053] Optionally, SHA-256 can be selected as the one-way hash function.

[0054] Optionally, AES-128 block encryption can be selected as the symmetric encryption / decryption standard.

[0055] According to the specific embodiments provided in this application, this application has the following technical effects:

[0056] This application provides a V2R mutual trust authentication and session key negotiation method. Based on the vehicle's identity identifier and password, and vehicle registration information, it completes vehicle access authentication. Through authentication message exchange between the vehicle and the roadside unit (RUS), and verification of the parameters to be verified in the authentication message, it achieves two-way identity authentication between the vehicle and the RUS, ensuring the legitimacy of the identities of both parties in the information exchange and preventing attackers from impersonating communication entities to send false messages. During the two-way identity authentication process between the vehicle and the RUS, session key negotiation is completed, significantly reducing the burden on the TA (Transmission Controller) caused by identity authentication between dense communication entities, and reducing the number of authentication message exchanges and transmission latency. Furthermore, this method can also track and revoke the identities of malicious communication entities, preventing malicious actions by legitimate communication entities. This application only uses the TA for vehicle and RUS registration, and for tracking and revoking the identities of malicious communication entities, preventing single points of failure for the TA in dense vehicle scenarios and improving the security and efficiency of authentication. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 A flowchart illustrating a V2R mutual trust authentication and session key negotiation method provided in an embodiment of this application;

[0059] Figure 2A schematic diagram of a vehicle registration process provided in an embodiment of this application;

[0060] Figure 3 This is a schematic diagram of the registration process for a roadside unit provided in an embodiment of this application. Detailed Implementation

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

[0062] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] In an exemplary embodiment, this application provides a V2R mutual trust authentication and session key negotiation method. This method is executed by a computer device, specifically by a terminal or server alone, or by both. In this embodiment, the method is described using a server as an example. The method includes:

[0064] Step 100: The vehicle selects its own identity and password, and generates a binary string as a challenge. Based on the selected vehicle identity and password, the challenge and response of the non-cloning function, the vehicle registration is completed, and the vehicle registration information is obtained and stored. The vehicle registration process is achieved through information exchange between the vehicle and the trusted center.

[0065] Step 101: The roadside unit selects its own identity and key, and completes the roadside unit registration based on the identity and key, obtaining and storing the roadside unit registration information. The roadside unit registration process is achieved through information exchange between the roadside unit and the trusted center.

[0066] Step 102: Based on the vehicle's identity identifier and password, and vehicle registration information, complete vehicle access authentication. Through the interaction of authentication messages between the vehicle and the roadside unit, and the verification of the parameters to be verified in the authentication messages, complete the mutual trust authentication and session key negotiation between the vehicle and the roadside unit. After successful mutual trust authentication between the vehicle and the roadside unit, the trusted center tracks and revokes the true identity of malicious communication entities.

[0067] Based on steps 100-102 provided above, this application can make TA used only for vehicle and roadside unit registration, as well as for tracking and revoking the identity of malicious communication entities, thereby reducing the number and length of authentication message forwarding and improving authentication security and efficiency.

[0068] In another exemplary embodiment of this application, a vehicle i The TA sends a registration request message through a secure channel, and the TA sends the registration response to the vehicle through the secure channel. i Vehicle i The registration process is as follows Figure 2 As shown, it includes:

[0069] Step 1: Vehicle i Choose your real identity ID i and password PW i Generate the first binary string As a challenge, and by embedding it in the vehicle i Unclonable Functions (PUFs) i Received first response Then, the vehicle i Send a registration request to TA via a secure channel.

[0070] Step 2: After receiving the registration request reqv, the TA first checks the vehicle. i Real identity ID i Does it exist in TA's database? If it exists, notify Vehicle. i Choose a different identity identifier. Otherwise, calculate... Storage tuple (ID) i ,PID i ) in TA's database, and then through a secure channel to the vehicle. i Send the first registration response res1:<MID i W k ,Rel i >.

[0071] Step 3: The vehicle i After receiving the first registration response res1, calculate Then store its system parameters. That is, the vehicle i The registration information is stored in its memory. Among them, Xi This indicates the association parameters between the vehicle and the trusted center, Ver. i This indicates the vehicle's authentication parameters, MID. i Indicates a vehicle's misidentification, Rel i This represents the association parameters between the trusted center and the roadside unit. Among them, This represents the XOR operation.

[0072] In another exemplary embodiment of this application, the roadside unit (RSU) selects only its own identity and key. Based on this, in this embodiment, the roadside unit (RSU) j The registration process is as follows Figure 3 As shown, it includes:

[0073] Step 1: Roadside Unit (RSU) j Select your identity ID j and key K j , key K j It is stored in its immutable module TPM, and then the roadside unit registration request reqr:<ID is sent through a secure channel. j ,K j > Send to a trusted center.

[0074] Step 2: After receiving the registration request (reqr), the trusted center first checks the Roadside Unit (RSU). j Real identity ID j Check if it exists in its database. If it exists, notify the RSU. j Select a different identity. Otherwise, RSU j Storage (ID) j ,K j Then generate random numbers RN. ta Calculate the intermediate temporary variable K temp =h(ID) j ||RN ta )and Then construct the second registration response res2:<RN ta W>, and sends the second registration response res2 to the roadside unit RSU through a secure channel. j .

[0075] Step 3: The Roadside Unit (RSU) j After receiving the second registration response res2, calculate Register roadside unit information (ID) j Y, W) are stored in its memory.

[0076] In another exemplary embodiment of this application, during the login, authentication, and key negotiation process, the vehicle completes authentication upon access by having the user input their identity identifier and password. If authentication fails, the vehicle cannot log in to the VANETs network. Only after successful authentication can the vehicle log in to the VANETs network and then complete bidirectional identity authentication and session key negotiation between the vehicle and the roadside unit through the interaction of authentication messages with the roadside unit and the verification of parameters to be verified in the authentication messages. Based on this, the login, authentication, and key negotiation process can be: based on the vehicle's identity identifier and password, vehicle registration information, and the roadside unit's identity identifier and key, and roadside unit registration information, through the interaction of authentication messages between the authenticated vehicle and the roadside unit, and the verification of parameters to be verified in the authentication messages, mutual trust authentication and session key negotiation between the vehicle and the roadside unit are completed. Figure 1 As shown, the process of completing vehicle login, mutual trust authentication between the vehicle and the roadside unit, and session key negotiation includes:

[0077] Step 1: User enters vehicle i Real identity ID i and password PW i and extract parameters from its memory. X i 、Rel i Ver i and MID i Then calculate the vehicle. i fake identity Temporary parameters associated with the trusted center key And temporary parameters related to the key of the roadside unit.

[0078] Step 2: Vehicle i Calculate verification parameters Then check Ver. i * ? = Ver i If the two are not equal, it indicates that the vehicle is not in good condition. i If login authentication fails, the system terminates the current identity mutual trust authentication and session key negotiation process. Otherwise, the vehicle... i Generate a second binary string PUF as an unclonable function i The challenge input is obtained through the non-cloning function PUF. i Obtain its response (i.e., the second response).

[0079] Step 3: The vehicle i Generate the first timestamp t1, and then calculate the temporary parameters during the identity mutual trust authentication and session key negotiation process. And the first authentication parameter in the identity mutual trust authentication and session key negotiation process. Then to the roadside unit RSU j Send the first authentication message Msg1: <MID i ,A1,A2,t1>。h() is a hash function.

[0080] Step 4: The Roadside Unit (RSU) j Upon receiving the first authentication message Msg1, the validity of the first timestamp t1 is checked first. If |t1-t|>ε (i.e., the first timestamp is invalid), where t is the system time when Msg1 was received, the current identity mutual trust authentication and session key negotiation process is terminated to prevent replay attacks. Otherwise, the roadside unit (RSU)... j Assuming the first timestamp t1 is valid, use its key K. j The Misunderstanding Identifier (MID) of the vehicle described in the received Msg1 i Decrypt to obtain And calculate

[0081] Step 5: Roadside Unit (RSU) j calculate And the second authentication parameter in the identity mutual trust authentication and session key negotiation process. examine If they are not equal, it indicates that the RSU j For the vehicle i If authentication fails, the system terminates the current identity mutual trust authentication and session key negotiation process. Otherwise, the Vehicle... i The identity of the roadside unit RSU j Certified.

[0082] Step 6: The Roadside Unit (RSU) j Calculate the vehicle i New confusing identity identifiers Second temporary parameter in the process of identity mutual trust authentication and session key negotiation between vehicle and roadside unit in, Indicates the use of a trusted center's key K ta Perform encryption operations on *.

[0083] Step 7: Roadside Unit (RSU) jGenerate a second timestamp t2, and then calculate the second authentication parameters during the mutual trust authentication and session key negotiation process between the vehicle and the roadside unit. and session key Then to the vehicle i Send the second authentication message Msg2: <B1,B2,t2>.

[0084] Step 8: The vehicle i Upon receiving the second authentication message Msg2, the validity of the second timestamp t2 is first checked. If |t2-t|>ε (i.e., the second timestamp is invalid), where t is the system time when Msg2 was received, the current authentication and session key negotiation process is terminated to prevent replay attacks. Otherwise (i.e., the second timestamp is valid), the vehicle... i calculate And the second authentication parameter in the process of mutual trust authentication and session key negotiation between the vehicle and the roadside unit. Then check If the two are not equal, it indicates that the vehicle is not equal. i Roadside Unit (RSU) j If authentication fails, the system terminates the current identity mutual trust authentication and session key negotiation process. Otherwise, the roadside unit (RSU)... j The identity of the vehicle i The vehicle was subsequently certified. i Calculate session key And adopt Its system parameter MID i Update.

[0085] In another embodiment of this application, the process of completing mutual trust authentication between a vehicle and a roadside unit through information interaction after identity access verification can be described as follows: based on the vehicle's obfuscated identity identifier, the roadside unit's identity identifier and key, the vehicle's pseudo-identity identifier, the vehicle's identity identifier and password, a first binary string, and a second response, the malicious vehicle's identity is tracked and revoked through information interaction between the roadside unit and a trusted center. Based on this, the process of tracking and revoking a malicious vehicle node can be described as follows:

[0086] Step 1: Vehicle i Roadside Unit (RSU) j Send the first authentication message Msg1: <MID i ,A1,A2,t1>,Roadside Unit RSU j Verification passed Complete the vehicle iThe certification. If the two are equal, then the roadside unit RSU j Complete the vehicle i The identity of the vehicle is verified and the vehicle information is recorded. i Misidentification (MID) i .

[0087] Step 2: Once the vehicle is detected... i Sending false / malicious messages, the roadside unit (RSU) j MID i Add it to its incremental obfuscated identity revocation list (IMRL) and calculate the second hash value V. ta =h(MID) i ||ID j ||K j ), and send a revocation message Revo: <MID i V ta >Give it to them.

[0088] Step 3: Upon receiving the Revo message, TA calculates the third hash value. examine If the two are not equal, it indicates that the message has been withdrawn from the non-roadside unit (RSU). j Report. If the two are equal, TA will proceed according to... Decrypting Vehicles i Misidentification (MID) i To obtain the vehicle i PID (Pseudo-identity identifier) i Then, according to the vehicle i PID (Pseudo-identity identifier) i Query binary data (ID) within its database i ,PID i If found, the Trust Center can determine the true identity ID of the vehicle sending the false / malicious message. i This completes the tracking of vehicles sending false / malicious messages. Among them, Indicates the use of key K ta Decrypt *.

[0089] Step 4: TA will send the message CMID i Broadcast to roadside units (RSUs) j All other roadside units. in, This indicates the use of TA's key K. ta MID i Perform encryption operations.

[0090] Step 5: Receive broadcast message CMID i Subsequently, the roadside unit extracts its key K from its TPM. j Extract (ID) from its memory j (,Y,W), then calculate K temp =h(ID) j ||RN ta ),as well as Using the calculated TA key K ta ,implement Decryption operation, Indicates the use of key K ta For CMID i Perform the decryption operation. Then, obtain the vehicle information. i Misidentification (MID) i Add it to the incremental obfuscated identity revocation list (IMRL) of the roadside unit that performs the decryption operation.

[0091] Step 6: When a malicious vehicle... i To any roadside unit RSU j Send the first authentication message Msg1: <MID i ,A1,A2,t1>,the roadside unit RSU j First, inspect the vehicle. i Misidentification (MID) i Whether it is in its Incremental Obfuscated Identity Revocation List (IMRL). If the vehicle... i Misidentification (MID) i If it is not in its Incremental Obfuscated Identity Revocation List (IMRL), it indicates a Vehicle. i Authentication initiated for normal vehicles. If the vehicle... i Misidentification (MID) i In its Incremental Obfuscated Identity Revocation List (IMRL), it indicates that the vehicle is a vehicle. i The vehicle's identity authentication has been terminated and it will no longer be accepted. i Any message sent.

[0092] In another embodiment of this application, the method provided in this application can be divided into four stages: system initialization, vehicle registration (step 100), roadside unit registration (step 101), and mutual trust authentication and session key negotiation between the vehicle and the RSU (step 102). Based on this, in this embodiment, the system initialization stage can be completed by the system administrator, including:

[0093] Step 1: The system administrator completes the Trusted Center Key K ta Pre-installed roadside units (RSUs) j Key K j The pre-defined parameters are used to complete the unclonable function PUF. i In vehicle i Embedded within.

[0094] Step 2: The system administrator selects a one-way hash function and a symmetric encryption / decryption standard. SHA-256 is chosen as the one-way hash function, and AES-128 block encryption is chosen as the symmetric encryption / decryption standard.

[0095] In summary, this application employs non-clonable functions, lightweight one-way hash operations (Hash), and bitwise XOR operations (XOR) to achieve bidirectional identity authentication and session key negotiation between vehicles and roadside units in a vehicle-to-everything (V2X) environment. Its main features are as follows:

[0096] 1) It realizes two-way identity authentication between vehicles and roadside units, which can ensure the legitimacy of the identities of both parties in information exchange and prevent attackers from impersonating communication entities to send false messages.

[0097] 2) The session key is negotiated between the vehicle and the roadside unit. The transmission of sensitive messages is encrypted using the session key, and the receiver decrypts the messages using the session key to ensure the confidentiality of the transmitted messages.

[0098] 3) It achieves anonymity of communication entities. During the message transmission process, both the sender and receiver exchange information anonymously, which protects the user's privacy and prevents the tracking of communication entities in the Internet of Vehicles.

[0099] 4) Preventing cloning and physical attacks: This method uses a non-clonable function, which has advantages such as being lightweight, low-power consumption, high throughput, non-replicable, and difficult for adversaries to counterfeit and predict. Moreover, it does not require additional storage space to store keys or random numbers.

[0100] 5) Suitable for identity mutual trust authentication and session key negotiation between resource-constrained devices. This method uses lightweight hash operation, XOR operation, non-clonable function, and symmetric encryption and decryption, with low computational overhead, making it particularly suitable for identity authentication and session key negotiation between resource-constrained devices.

[0101] 6) This application completes identity authentication and session key negotiation in one step, which not only reduces the number of authentication message exchanges, but also shortens the length of the exchanged messages, thereby reducing message transmission latency.

[0102] 7) The authentication of the two communicating parties does not require the participation of a trusted third party, which not only greatly reduces the burden on the TA caused by authentication and session key negotiation between dense communication entities, but also reduces the probability of the TA experiencing a "single point of failure".

[0103] 8) To track and revoke the identity of malicious vehicles, if the roadside unit receives a false or malicious message, it can send the obfuscated identity of the message sender to the TA. Then the TA uses its own key to decrypt the reported obfuscated identity to obtain the false identity of the vehicle. Based on this false identity, the true identity of the vehicle can be tracked by querying the tuple.

[0104] The Trusted Center (TA) uses its own key to encrypt the received vehicle obfuscation identifier and sends it to all roadside units except the reporting roadside unit. Upon receiving the encrypted vehicle obfuscation identifier broadcast message, each roadside unit uses its key stored in its immutable module (TPM) and registration information stored in its memory to calculate the TA's key. It then uses this key to decrypt the received encrypted vehicle obfuscation identifier broadcast message, thereby obtaining the obfuscated identifier of the spoofing message sender. This obfuscated identifier is then added to the roadside unit's incremental obfuscation identifier revocation list, thus completing the revocation of the spoofing message sender's identity.

[0105] In one exemplary embodiment, a computer device is provided, which may be a vehicle-mounted terminal, a roadside unit terminal, or a roadside edge server. The computer device includes a processor, memory, and a communication interface. The processor and memory interact with external devices via the communication interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores V2R mutual trust authentication and session key negotiation data. The communication interface allows the processor to exchange information with external devices and communicate with external terminals via a network connection. When executed by the processor, the computer program implements a V2R mutual trust authentication and session key negotiation method.

[0106] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0107] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0108] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0109] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic resistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0110] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0111] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0112] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A V2R mutual trust authentication and session key negotiation method, characterized in that, include: The vehicle selects its own identity and password, and generates a binary string as a challenge. Based on the selected vehicle identity and password, the challenge and response of the non-cloning function, the vehicle registration is completed, and the vehicle registration information is obtained and stored. The vehicle registration process is realized by the vehicle and the trusted center through information exchange. The roadside unit selects its own identity and key, and completes the roadside unit registration based on the identity and key, obtaining and storing the roadside unit registration information; the roadside unit registration process is realized by the roadside unit and the trusted center through information interaction; Based on the vehicle's identity and password, and vehicle registration information, the vehicle access authentication is completed. Through the interaction of authentication messages between the vehicle and the roadside unit, and the verification of the parameters to be verified in the authentication messages, the mutual trust authentication and session key negotiation between the vehicle and the roadside unit are completed. After mutual trust authentication between the vehicle and the roadside unit is successful, the trusted center tracks and revokes the true identity of the malicious communication entity; The vehicle selects its own identity and password, and generates a binary string as a challenge. Based on the selected vehicle identity and password, the challenge and response of the non-cloning function, the vehicle registration is completed, and the vehicle registration information is obtained and stored, including: Vehicles can choose their own identification. and password And generate the first binary string. ; The first binary string The first challenge of non-clonable functions The first response is obtained through a non-clonable function embedded in the vehicle. ; Based on vehicle identification ,password The first challenge and first response Complete registration request ; = and the registration request Send to a trusted center; Received registration request Then, the trusted center checks its database to see if the vehicle's identity exists. ; If it exists, it indicates that the identity identifier is valid. If the vehicle has already been used by another vehicle, notify the vehicle to select a new identification identifier. If it does not exist, then the trusted central computation can be performed. , , , , Store binary tuples The system is stored in the database, and then a first registration response is sent to the vehicle through a secure channel. ;in, This indicates a false identification mark for the vehicle. This indicates a vehicle with a misleading identification identifier. Indicates the key from the trusted center. Related temporary parameters, Key representing the roadside unit Related temporary parameters, This represents the association parameters between the trusted center and the roadside unit. This represents the XOR operation; Vehicle based on registration response Generate vehicle registration information; the vehicle registration information includes: association parameters between the vehicle and the trusted center. Vehicle authentication parameters Confusing vehicle identification Correlation parameters between trusted center and roadside unit And the first challenge ; The roadside unit selects its own identity and key, and completes roadside unit registration based on the identity and key, obtaining and storing roadside unit registration information, including: Roadside units select their own identification. and key , the key Stored in the immutable TPM module of the roadside unit, based on the selected identity identifier and key Generate a registration request for the roadside unit. and the registration request Send to a trusted center; Trust Center receives registration request Next, check if the roadside unit's identity identifier exists in the trusted center's database. ; If it exists, it indicates the selected identity identifier. If the identity has already been used by other roadside units, the trusted center can notify the roadside unit to reselect its identity. If it does not exist, the trusted center will identify the roadside unit. and key The data is stored in its database; subsequently, a trusted center generates random numbers. and in random numbers Based on this, the registration response of the roadside unit is constructed. ; = , This is an intermediate temporary variable; the registration response will be used. Send to the roadside unit; Roadside unit receives registration response Then, store the registration information. ,in, It is also an intermediate temporary variable.

2. The V2R mutual trust authentication and session key negotiation method according to claim 1, characterized in that, Based on the vehicle's identity identifier and password, and vehicle registration information, vehicle access authentication is completed. Through authentication message exchange between the vehicle and the roadside unit, and verification of parameters to be verified in the authentication messages, mutual trust authentication and session key negotiation between the vehicle and the roadside unit are completed, including: Enter the vehicle's real identification. and password It then retrieves the vehicle registration information from the vehicle's memory and determines the vehicle's pseudo-identity based on the retrieved vehicle registration information. Roadside Unit and Trusted Center Key Related temporary parameters and the key to the roadside unit. Related temporary parameters ; Based on the association parameters between vehicles and trusted centers and the key with the roadside unit. Related temporary parameters Determine the vehicle's verification parameters ; Determine the verification parameters of the vehicle Whether it is equal to the vehicle's identity verification parameters in the vehicle registration information, i.e. The first judgment result is obtained; Indicates whether it is equal to; If the first judgment result is yes, then the second binary string is generated. and the second binary string As a challenge for non-clonable functions, obtaining a second response ; Generate first timestamp And based on the vehicle's false identity identifier Identification of roadside units , and trusted central key Related temporary parameters Second binary string Second Response And the correlation parameters between the trusted center and the roadside unit. Generate the first authentication message The first authentication message Including: misleading vehicle identification The first temporary parameter in the authentication and key negotiation process The first authentication parameter in the identity authentication and key negotiation process and first timestamp ;in, ; ; The roadside unit received the first authentication message. Then, determine the first authentication message. First time stamp Validity; First timestamp When valid, the roadside unit uses a key. Confusing vehicle identification Decryption is performed, and the second authentication parameters in the identity authentication and key negotiation process are determined based on the decrypted parameters. ,in = , h ( ) represents a hash function; The first authentication parameter in the process of determining identity trust authentication and key negotiation Is it related to the second authentication parameter in the identity authentication and key negotiation process? If they are equal, the second judgment result is obtained; When the second judgment result is yes, the roadside unit completes the vehicle's identity authentication; Roadside units are based on vehicle pseudo-identity identifiers. Vehicle password First binary string First Response Second binary string Second response Identify new confusing identifiers for vehicles And the second temporary parameter in the authentication and key negotiation process between the vehicle and the roadside unit. ;in, ; ; Second timestamp generated by roadside unit And based on the vehicle's false identity identifier Temporary parameters related to the trusted center key Temporary parameters related to the key of the roadside unit First binary string Second binary string Second timestamp And new confusing identification for vehicles Generate a second authentication message and the second authentication message Send to the vehicle; the second authentication message This includes: second temporary parameters during the authentication and key negotiation process between the vehicle and the roadside unit. Third authentication parameters in the process of mutual trust authentication and key negotiation between vehicles and roadside units Second timestamp Roadside unit determines session key ,in, = ; ; Vehicle receives second authentication message Then, determine the second timestamp. The validity of the second timestamp; When valid, the vehicle is based on its false identity. , and trusted central key Related temporary parameters Key to the roadside unit Related temporary parameters First binary string Second binary string and the second timestamp Determine the fourth authentication parameter in the process of mutual trust authentication and session key negotiation between the vehicle and the roadside unit. ,in, = ; The third authentication parameter used in determining the mutual trust authentication and session key negotiation process between the vehicle and the roadside unit. Is it a fourth authentication parameter in the process of mutual trust authentication and session key negotiation between the vehicle and the roadside unit? If they are equal, the third judgment result is obtained; When the third judgment result is yes, the vehicle completes the identity authentication of the roadside unit; the vehicle then proceeds according to... Calculate its new obfuscated identity Determine its session key ,in, = and using new, misleading identification for vehicles. Update the obfuscated identity stored in its memory .

3. The V2R mutual trust authentication and session key negotiation method according to claim 2, characterized in that, After mutual trust authentication between the vehicle and the roadside unit is successful, the trusted center tracks and revokes the true identity of malicious communication entities, including: The roadside unit receives the first authentication message sent by the vehicle. And based on the vehicle's false identity identifier Identification of roadside units Roadside Unit and Trusted Center Key Related temporary parameters Second binary string Second Response and the first timestamp Determine the first hash value ; Determine the first hash value The first authentication parameter in the process of mutual trust authentication and session key negotiation between the vehicle and the roadside unit. Whether they are equal, we obtain the fourth judgment result; If the fourth determination result is negative, the vehicle's identity cannot be authenticated, and the received first authentication message is discarded. ; When the fourth determination result is yes, the vehicle's identity is authenticated by the roadside unit, and the roadside unit verifies the identity based on the received first authentication message. Identify and record the vehicle's obfuscated identity. ; When a vehicle is detected sending false / malicious messages, the roadside unit will obfuscate the vehicle's identity. Add it to the incremental obfuscated identity revocation list (IMRL) of the roadside unit, and based on its own identity. and key and the vehicle's misidentification Calculate the second hash value ,in, = And based on the second hash value Confusing vehicle identification Generate a revocation message ,in, = And will rescind the message. Send to a trusted center; When you receive the cancellation message Then, the trusted center extracts the identification identifiers of the roadside units from its database. and key The third hash value is determined based on the revocation message. ,in, = And determine the third hash value Is it related to the second hash value? If they are equal, we arrive at the fifth judgment result; When the fifth judgment result is yes, the trusted center uses its key. Decrypt the revocation message Confusion of vehicle identification Obtain the vehicle's fake identification. And based on the vehicle's false identity identifier Query the vehicle's true identity identifier Does binary data exist? The binary data includes the vehicle's true identity identifier. and vehicle false identification ; When a fake vehicle identification is detected There are binary data At that time, the Trust Center can determine the true identity of the vehicle sending false / malicious messages. It completes the tracking of vehicles sending false / malicious messages and generates broadcast messages. ;in, , Indicates the use of a trusted center's key. right Perform encryption operations; The Trust Center will broadcast messages Broadcast to all roadside units except the one that reported the cancellation message; Received broadcast message Subsequently, the roadside unit extracts its key from its tamper-proof module TPM. Extract from its memory Then according to , , Calculate and obtain the key from the trusted center and use The broadcast message received Decryption is performed to obtain the obfuscated identity of the vehicle sending the false / malicious message. and the obfuscated identity of the vehicle obtained through decryption. Add it to its incremental obfuscated identity removal list (IMRL); When the vehicle sending the false message sends the first authentication message to other roadside units The roadside unit received Next, check the vehicle's misleading identification markings. Check if the vehicle is in its Incremental Obfuscated Identity Revocation List (IMRL); if it is not in the IML, it indicates that the vehicle is a normal vehicle; if it is in the IML, it indicates that the vehicle has been revoked, and identity authentication is terminated.

4. The V2R mutual trust authentication and session key negotiation method according to claim 1, characterized in that, Before selecting a vehicle identifier and password, completing vehicle registration based on the selected vehicle identifier and password, and obtaining and storing vehicle registration information, the V2R mutual trust authentication and session key negotiation method further includes: Complete the pre-setting of the trusted center key and the roadside unit key, and complete the embedding of the non-clonable device in the vehicle; the non-clonable device has a non-clonable function implanted in it; Choose a one-way hash function and a symmetric encryption / decryption standard.

5. The V2R mutual trust authentication and session key negotiation method according to claim 4, characterized in that, SHA-256 was selected as the one-way hash function.

6. The V2R mutual trust authentication and session key negotiation method according to claim 5, characterized in that, AES-128 block encryption was selected as the symmetric encryption and decryption standard.

Images