Continuous authentication method based on trusted connection architecture in Internet of Vehicles environment
The continuous authentication method with a trusted connection architecture and dynamic token mechanism addresses the dynamic identity changes in the Internet of Vehicles, ensuring persistent security and reducing latency and overhead through dual-mechanism switching.
Patent Information
- Application Number
- CN202411184814.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-27
- Publication Date
- 2025-01-03
AI Technical Summary
Current authentication methods in the Internet of Vehicles environment focus solely on initial authentication, failing to address the dynamic changes in vehicle identity due to rapid movement, thereby compromising the continuous security and reliability of the communication process.
A continuous authentication method utilizing a trusted connection architecture with a dynamic token mechanism and lightweight cryptographic primitives, enabling continuous verification of vehicle identity through a dual-mechanism switching method across different roadside units.
Ensures persistent security by continuously verifying vehicle identity, resisting attacks, and reducing latency and overhead in high-traffic areas, while maintaining low computing and communication costs.
Smart Images

Figure CN119255239A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of information security technology of Internet of Vehicles, relates to trusted network connection technology and elliptic curve cryptography algorithm, and particularly designs a continuous authentication method based on a trusted connection architecture in an Internet of Vehicles environment. Background Art
[0002] The Internet of Vehicles is a typical application of IoT technology in the field of transportation systems. The Internet of Vehicles provides vehicles with a variety of safety and efficiency applications such as collision avoidance, warning prompts, and traffic signal optimization by collecting and exchanging real-time information between vehicles, infrastructure, pedestrians, and other traffic participants. The Internet of Vehicles serves the intelligent transportation system. The future intelligent transportation system will be highly dependent on the Internet of Vehicles to solve important issues such as traffic safety, efficiency, and comfort services.
[0003] The typical feature of the Internet of Vehicles is the rapid and long-term movement of vehicles, which leads to continuous dynamic changes in the network topology, which determines the connectivity characteristics between vehicles and between vehicles and infrastructure. The open communication environment of the Internet of Vehicles brings many security risks to vehicles, including information tampering, terminal impersonation and privacy leakage, which directly threaten the life and property safety of vehicle users. The existing solution starts with identity authentication, completing the identity verification of the vehicle before accessing the network, and only allows the vehicle to access after the verification is passed.
[0004] However, in the Internet of Vehicles environment, due to the dynamic changes in the network topology caused by the long-term high-speed movement of vehicles, the identity of the vehicle that has been initially authenticated is likely to change during the subsequent driving process. Only a single access authentication will provide opportunities for potential attackers and increase the risk of security threats to the system. For example, the legitimate identity of the vehicle may be tampered or impersonated by attackers, and then malicious activities are carried out. Therefore, it is necessary to continuously verify the identity of the vehicle on the basis of completing the initial access authentication. This continuous authentication mechanism can ensure that the vehicle always maintains a legitimate identity throughout the communication process, thereby effectively improving the security and reliability of the Internet of Vehicles system. Summary of the invention
[0005] The technical problem to be solved by the present invention is to provide a continuous authentication method based on a trusted connection architecture in a connected vehicle environment, which is used to protect the persistent security in dynamic connected vehicle scenarios. This is because most current research only focuses on the initial authentication of the vehicle, and cannot solve the problem of changes in vehicle identity in a highly dynamic environment, and cannot guarantee the continuous security of the entire communication process.
[0006] The technical solution of the present invention to solve the above technical problems is as follows: the vehicle networking environment system includes a trusted network, a trusted organization, multiple roadside units and vehicles, wherein the trusted network includes a cloud service provider to provide secure cloud computing services. A continuous authentication method based on a trusted connection architecture includes:
[0007] Step 1: The trusted authority TA is initialized and generates system parameters. TA randomly selects a non-singular elliptic curve Ep(a,b). TA randomly selects s as the system private key and calculates the system public key P pub TA selects a secure hash function H. TA publishes system public parameters to vehicles and roadside units RSU.
[0008] Step 2: The vehicle and RSU register with TA. After registration, TA transmits the certificate information of the vehicle and RSU back through a secure channel, and sends the information of the vehicle and RSU to the cloud service provider CSP after signing with s.
[0009] Step 3: When a vehicle requests to access the protected network, it broadcasts its request message.
[0010] Step 4: After receiving the request message, the RSU generates an initial token for the vehicle and transmits its own identity information, key data information and vehicle information to the CSP.
[0011] Step 5: After receiving the message from the RSU, the CSP first completes the identity authentication of the vehicle and the RSU. It verifies the signature based on the locally stored public key information, then checks whether the certificate information and identity information are legal, generates verification results for the vehicle and the RSU respectively, and calculates the session keys for subsequent communications.
[0012] Step 6: After completing the identity authentication, the CSP updates the initial token generated by the RSU. First, the integrity of the message is verified, then the dynamic parameter key is calculated and added to the token, and the token and PID are updated. vi The latest token is encrypted and transmitted to RSU.
[0013] Step 7: RSU uses the public key to verify the message and then generates a session key with CSP. Check the verification result of the vehicle and decide whether to allow the vehicle to access. If the result shows that the vehicle is a trusted vehicle, the token information is forwarded to the vehicle.
[0014] Step 8: The vehicle uses the public key to verify the message and generate a session key with the CSP. The vehicle checks the verification result of the RSU. If it is credible, it decrypts the token information and stores it.
[0015] Step 9: When the vehicle enters the new RSU coverage, the RSU initiates a continuous verification request to the vehicle or the vehicle actively initiates a continuous verification request.
[0016] Step 10: The vehicle calculates the key value, encrypts the token using the session key, and sends it to the new RSU.
[0017] Step 11: After receiving the message, RSU checks the anonymous identity PID vi Check whether the token is within the validity period. If so, forward the message to the CSP.
[0018] Step 12, CSP according to the vehicle's PID vi Find the local mapping information and use the session key SK i Decrypt to obtain the token' information, calculate whether the current token' is consistent with the locally stored token and the token' recalculated with the latest identity information. If the three are consistent, then generate the verification result of the vehicle through continuous verification. CSP performs verification on PID vi and token information, and store the latest vehicle identity information locally. i The latest token information is encrypted and forwarded to the RSU.
[0019] Step 13: RSU decides whether to allow the vehicle to access based on the CSP's verification result. If RSU allows the vehicle to access, it forwards the token information to the vehicle.
[0020] Step 14: After receiving the message, the vehicle uses SK i Decrypt the message and get the latest dynamic token. vi Information is updated and stored.
[0021] The beneficial effects of the present invention are:
[0022] 1. The present invention introduces a trusted connection architecture into the continuous authentication scenario of the Internet of Vehicles, and adds a dynamic token mechanism on this basis. By transmitting dynamic tokens between different RSUs, the variable identity information of the vehicle is continuously verified, thereby realizing continuous authentication of the vehicle and solving the problem that a single static authentication cannot guarantee the lasting legitimacy of the vehicle identity.
[0023] 2. The present invention utilizes lightweight cryptographic primitives and a trust transfer mechanism to propose a dual-mechanism switching method that combines active and passive strategies, thereby achieving rapid switching of vehicles between different RSUs and solving the problems of high latency and high overhead in the switching process in areas with dense traffic.
[0024] 3. Through experimental verification and performance analysis, the present invention can resist common attacks such as impersonation attacks, collusion attacks and man-in-the-middle attacks, and has low computing and communication overhead. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] Figure 1 It is a flow chart of the continuous authentication method based on the trusted connection architecture in the Internet of Vehicles described in the present invention.
[0026] Figure 2 This is a schematic diagram of vehicle registration in Embodiment 1 of the present invention.
[0027] Figure 3 This is a schematic diagram of roadside unit registration in Embodiment 1 of the present invention.
[0028] Figure 4 This is a schematic diagram of the initial authentication of a vehicle and a roadside unit i with the help of a trusted third party in Embodiment 1 of the present invention.
[0029] Figure 5 This is a schematic diagram of continuous authentication between a vehicle and a roadside unit j with the help of a trusted third party in Embodiment 1 of the present invention. DETAILED DESCRIPTION
[0030] The principles and features of the present invention are described below in conjunction with the accompanying drawings. The examples given are only used to explain the present invention rather than to limit the scope of the present invention.
[0031] Embodiment 1
[0032] like Figure 1 As shown, the first embodiment is that the vehicle, the roadside unit RSU and the cloud service provider CSP complete the initial authentication and continuous authentication, and at the same time complete the switching of the vehicle between different RSUs. The method consists of four parts: system initialization phase, vehicle and RSU registration phase, vehicle and RSU initial authentication phase, and vehicle continuous authentication phase. The specific content is described as follows:
[0033] Step 1: TA randomly selects two large prime numbers p and q and a non-singular elliptic curve Ep(a,b), and selects the q-order generator P in the G group. TA randomly selects s as the system private key, which is stored in TA's own memory, and calculates the system public key P pub =s·P. TA selects a secure hash function H. TA publishes system public parameters {p, q, a, b, P, P pub , H}.
[0034] Step 2, the specific steps are as follows Figure 2 and Figure 3 As shown, the vehicle and RSU register at the TA respectively. The vehicle selects a random number pk viAs the private key, calculate the public key PK vi =pk vi P, generate a random number n1, and set ID vi 、PWD vi ,PK vi , n1 information is sent to TA through a secure channel. TA first stores the vehicle's public key, generates a random number n2, and generates an anonymous identity PID for the vehicle vi =H(ID vi ||n1||n2), set PID vi The validity period is Exp PIDvi , generate a certificate Cert for the vehicle vi , store {ID vi ,PK vi ,Cert vi ,PWD vi ,PID vi ,Exp PIDvi}, and the certificate and PID vi The information is sent back to the vehicle, which stores the information after receiving it. RSU selects a random number pk ri As the private key, calculate the public key PK ri =pk ri P, ID ri and PK ri It is sent to TA through a secure channel. TA stores the public key of RSU and generates a certificate Cert for RSU. ri , store {ID ri ,PK ri ,Cert ri}, and sends the certificate back to the RSU, which stores the certificate. After TA completes the registration of the vehicle and RSU, it signs their information and sends it to the CSP.
[0035] Step 3: When a vehicle requests to access a protected network and communicate with other entities, it broadcasts its request message in the area. vi Perform a hash operation to generate a random number a, and sign the key data as Sig vi , and initiate a token application request at the same time.
[0036] Step 4: RSU receives the vehicle's request, first checks the freshness of the message, and then generates an initial token for the vehicle. vi ,Exp PIDvi ,Exp token ,H(ID vi )), perform a hash operation on the token information and calculate RSU signs its own key information and records it as Sig ri , integrates vehicle and its own information and sends it to CSP.
[0037] Step 5: After receiving the message, CSP first checks the freshness of the message and then completes the initial identity authentication of the vehicle and RSU. vi and PK ri Perform signature verification, check the certificate information and identity information of the vehicle and RSU, and if the information is consistent with the locally stored information, generate the identity verification results Res for the vehicle and RSU respectively. vi and Res ri Finally, the session keys SK between CSP and vehicle, and between CSP and RSU are calculated respectively. i =PK vi ·pk c , S.K. j =PK ri ·pk c .
[0038] Step 6: After completing the identity authentication of the vehicle and RSU, the CSP updates the initial token generated by the RSU for the vehicle. First, the CSP generates a random number b and calculates key=t a +t b , where t = T m -T vi , update token = H(PID vi ,Exp PIDvi ,Exp token ,H(ID vi ),key), stores the vehicle’s token information {ID vi ,PID vi ,Exp PIDvi ,token,Exp token}, using SK i Encrypt token information Finally, sign the CSP key data, recorded as Sig c , send a message to RSU.
[0039] Step 7: After receiving the message, RSU uses PK c Verify the message and generate a session key SK with the CSP j =PK c ·pk ri . RSU checks the verification results of the vehicle Res vi ,If the verification result is credible, the vehicle’s access is allowed and the token information is forwarded to the vehicle.
[0040] Step 8, Vehicle Use PK c Verify the message and generate the session key SK with the CSP i =PK c ·pk vi , using SK i Decrypt the token information. View the verification result of RSU Res ri If the result is credible, the token information is trusted and stored for subsequent continuous authentication.
[0041] Step 9: The vehicle enters the coverage of the new RSU. The RSU detects the entry of the vehicle and initiates a verification request to the vehicle or the vehicle actively initiates a continuous verification request.
[0042] Step 10, vehicle calculation key = t a +t b , where t = T i -T m ,,Use SK i Encrypting token information Send token and identity information to RSU.
[0043] Step 11, RSU first checks the freshness of the message, then checks the PID vi If both are within the validity period, the request is forwarded to the CSP for further verification.
[0044] Step 12: CSP based on PID vi Find the mapping information stored locally, using SK i Decrypt the token and calculate whether the decrypted token' is consistent with the locally stored token and the temporary token "calculated based on the latest identity information". If the three are consistent, continuous verification is performed to generate the verification result Res for the vehicle. vi Then, CSP performs the following operations on PID vi Update the token information and recalculate key=t a +t b , where t = T c -T vi , generate a random number n, and recalculate PID vi =H(ID vi ||n1||n), update the locally stored {ID vi ,PID vi ,Exp PIDvi ,token,Exp token}, using SK i Encrypt the latest token information and forward the message to the RSU.
[0045] Step 13, RSU checks Res vi Decide whether to allow the vehicle to access. If the verification result shows that the vehicle is a trusted vehicle, forward the latest token information to the vehicle.
[0046] Step 14: After the vehicle receives the message, it uses SK i Decrypt the token information to obtain the latest token and PID vi , store this latest information locally.
[0047] Efficiency analysis of the present invention:
[0048] First, we define the cryptographic algorithm required in the present invention, and use T to represent the single-round algorithm operation time. h represents hash operation, T e represents symmetric encryption, T d represents symmetric decryption, T key Indicates the dynamic parameter key. Ignore XOR, modulo operations, etc., because their overhead is extremely small and can be ignored.
[0049] The present invention compares the time overhead of the continuous authentication phase with the existing UAAP-IoV, AKAP-IoV and BBLHAP schemes, and the other cryptographic algorithms used are: ecm represents elliptic curve point multiplication, T eca represents elliptic curve point addition, T sign Indicates signature, T ver Indicates signature verification, T ae represents asymmetric encryption, T mac Represents the message authentication code. Finally, the computational overhead comparison results are shown in Table 1.
[0050] Table 1 Computational cost comparison table
[0051]
[0052] Through the above comparative analysis, it is found that the present invention takes less time in the continuous authentication stage, is suitable for continuous multiple and periodic authentication of vehicles, can reduce the overhead of the continuous authentication scenario of the Internet of Vehicles, and fully ensure security.
[0053] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. A continuous authentication method based on a trusted connection architecture in a vehicle networking environment, characterized in that: The trusted connection architecture is applied to achieve continuous authentication of vehicles in the Internet of Vehicles scenario. The specific implementation methods include: Step 1: The system is initialized and the trusted authority TA generates necessary system parameters; Step 2: The vehicle and the roadside unit RSU complete registration at the TA; Step 3: The vehicle and RSU perform initial identity authentication at the cloud service provider CSP; Step 4: CSP and RSU complete continuous authentication of the vehicle.
2. According to claim 1, a continuous authentication method based on a trusted connection architecture in a vehicle networking environment is characterized in that: The execution process of the initial identity authentication in step 3 includes: Step 31: The vehicle performs a hash operation on the real identity, signs the key data with the private key, and initiates an initial authentication and token application request to the RSU in the region; Step 32: RSU generates an initial identity token for the vehicle and sets a validity period. RSU signs its own key data and sends its own information and vehicle information to CSP. Step 33: After receiving the message, CSP first uses the public key to verify the message of the vehicle and RSU, then authenticates the vehicle and RSU based on the certificate information, generates a verification result, and generates session keys with the vehicle and RSU respectively; then updates the token, adds the dynamic parameter key, generates the latest dynamic identity token, and encrypts it and sends it back to RSU and vehicle; Step 34, after receiving the message, the RSU first generates a session key with the CSP, then checks the verification result to decide whether to allow the vehicle to access; Step 35: The vehicle generates a session key with the CSP, decrypts it to obtain a token, and stores the token and its validity period information Exp token for storage.
3. A continuous authentication method based on a trusted connection architecture in a vehicle networking environment according to claim 1, characterized in that: The execution process of continuous authentication in step 4 includes: Step 41, the vehicle enters the coverage of a new RSU, and the RSU or vehicle initiates a continuous authentication request; Step 42: The vehicle calculates the key using the session key SK negotiated with the CSP i The token and identity information are encrypted and sent to the RSU; Step 43, RSU first checks the vehicle PID vi Check whether the token is valid. If it is valid, forward the information. Step 44, CSP according to PID vi Find the mapping information stored locally, decrypt it to get the token, compare the received token to see if it is equal to the stored token, and whether it is equal to the token recalculated based on the latest identity information transmitted by the vehicle. The CSP generates the verification result for the vehicle. If the verification passes, the CSP completes the verification of the token and PID. vi Updates; Step 45, RSU checks the CSP's verification result of the vehicle to decide whether to allow the vehicle to access. If the verification result is a trusted vehicle, the RSU forwards the latest token information to the vehicle; Step 46: Decrypt the vehicle to obtain the latest token, update the token and PID vi information.