Lightweight cross-domain authentication method for Internet of Vehicles based on block chain technology

Abstract

The invention discloses a block chain technology-based lightweight cross-domain authentication method for the Internet of Vehicles, and belongs to the field of block chains and vehicle privacy protection, and the method comprises the following steps: determining a trusted node based on a system public parameter; performing server registration based on the trusted node to obtain a registration authentication server and a registration calculation server; the vehicle user applies for registration from the trusted node of the area where the vehicle is located to obtain a registered vehicle; the registered vehicle of the current area applies for vehicle cross-domain to the registration authentication server of the target area, and after the registration authentication server of the target area verifies successfully, the registration authentication server of the target area sends a cross-domain agreement request to the registered vehicle of the current area; after the registration authentication server of the target area agrees with the cross-domain request, the registration authentication server and the registration computing server of the target area perform verification and key negotiation to obtain a temporary session key; and the registered vehicle in the current area decrypts the temporary session key to obtain a private key for subsequent communication.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain and vehicle privacy protection, and in particular relates to a lightweight cross-domain authentication method for vehicle networks based on blockchain technology. Background Art

[0002] With the rapid development of information technology, the Internet has been deeply integrated into all aspects of people's lives, and information exchange and collaboration between enterprises and organizations are becoming increasingly frequent. In this context, cross-domain authentication has become a key requirement. Different domains may represent different enterprises, institutions, network service providers or different business systems. They need to authenticate and authorize user identities securely and efficiently to achieve goals such as resource sharing and service interoperability.

[0003] Traditional cross-domain authentication schemes often rely on centralized authentication agencies. After a user authenticates in a domain, the authentication information will be stored on a centralized server. When a user accesses another domain, the domain needs to request verification of the user's identity from the centralized server. There are many problems with this approach: first, the centralized server becomes a single point of failure. If the server is attacked or fails, the entire cross-domain authentication system will face the risk of paralysis; second, the user's privacy data is stored in a centralized server, which is prone to data leakage risks. Once attacked by hackers, a large number of users' sensitive information may be stolen; third, the establishment of trust between different domains often requires complex negotiations and protocols, and when a new domain is added or an existing domain is withdrawn, the system's scalability and flexibility are poor, and the entire authentication architecture needs to be adjusted significantly. Therefore, the present invention proposes a lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology. Summary of the invention

[0004] In order to solve the above technical problems, the present invention proposes a lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology to solve the problems existing in the above-mentioned prior art.

[0005] To achieve the above objectives, the present invention provides a lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology, comprising:

[0006] The system is initialized to generate system public parameters, and a trusted node is determined based on the system public parameters;

[0007] Perform server registration based on the trust node to obtain a registration authentication server and a registration calculation server;

[0008] The vehicle user applies for registration at the trust node in the area where the vehicle is located to obtain a registered vehicle;

[0009] The registered vehicle in the current area applies to the registration authentication server in the target area for vehicle cross-domain, and the registration authentication server in the target area verifies the identity information of the registered vehicle in the current area. When the verification is successful, the registration authentication server in the target area sends a request for cross-domain approval to the registered vehicle in the current area;

[0010] After the registration authentication server of the target area agrees to the cross-domain request, the registration authentication server of the target area and the registration computing server perform verification and key negotiation to obtain a temporary session key;

[0011] The registered vehicles in the current area decrypt the temporary session key to obtain a private key for subsequent communication.

[0012] Optionally, the process of obtaining the registration authentication server includes:

[0013] The authentication server provides the authentication server identity and the authentication server public key to the trust node and issues a registration request;

[0014] After receiving the registration request from the authentication server, the trust node calculates the vehicle information set in the authentication server and generates an authentication server certificate;

[0015] A registered authentication server is obtained based on the authentication server certificate.

[0016] Optionally, the authentication server certificate is:

[0017] CERIT VS =E(SK TI ,(ID VS ||PK VS ||RT VS ||VAD))

[0018] In the formula, CERIT VS Is the authentication server certificate, SK TI is the private key of TI, TI is the trusted node, VAD is the validity period of the certificate, RT VS is a random number generated for VS, PK VS is the authentication server public key, ID VS Is the authentication server identity.

[0019] Optionally, the process of a vehicle user applying for registration with a trust node in the area where the vehicle is located to obtain a registered vehicle includes:

[0020] The vehicle user provides the vehicle identity and vehicle public key to the trust node in the area where the vehicle is located and applies for vehicle registration;

[0021] The trust node in the area where the vehicle is located generates a random number for the vehicle and calculates the vehicle's virtual identity, and based on the vehicle's virtual identity calculates the vehicle's area number and the vehicle's related address in the blockchain, thereby achieving successful vehicle registration.

[0022] Optionally, the expression for calculating the zone number of the vehicle is: ZEN V =H(RID V ||ID VS ||P);

[0023] The expression for calculating the relevant address of the vehicle in the blockchain is: Addrit V =H(RID V ||PK TI ||RT V );

[0024] Where RID V Indicates the virtual identity of the vehicle, ZEN V Indicates the area number to which the vehicle belongs, P represents a secret value randomly selected by TI, Addrit V Indicates the relevant address of the vehicle in the blockchain, PK TI Indicates the public key of the trusted node TI, RT V Indicates the random number selected by the trusted node TI for the vehicle applying for registration.

[0025] Optionally, the process of a registered vehicle in the current area applying to a registration authentication server in the target area for vehicle cross-domain authentication includes:

[0026] The registered vehicles in the current area send cross-domain messages to the registration authentication server in the target area;

[0027] The public key of the registration and authentication server in the target area encrypts the cross-domain message and the first timestamp to obtain an encrypted cross-domain message;

[0028] After receiving the encrypted cross-domain message, the virtual identity of the registered vehicle and the first timestamp sent by the registered vehicle in the current area, the registration authentication server in the target area performs timestamp verification and message decryption to obtain the decrypted cross-domain message and the decrypted area number;

[0029] The registration authentication server of the target area generates a hash value M based on the public key of the registration authentication server of the target area, the virtual identity of the registered vehicle and the second timestamp. 2 Sent to the authentication server in the vehicle registration area.

[0030] Optionally, the process of the registration authentication server in the target area sending a cross-domain approval request to the registered vehicles in the current area includes:

[0031] The authentication server of the vehicle registration area verifies the second timestamp and hash value M 2 Then, the module operation M is sent to the registration and authentication server in the target area. 3 and a third timestamp;

[0032] The registration authentication server of the target area verifies the third timestamp and replies to Req, and records the cross-domain information of the cross-domain application vehicle in the blockchain;

[0033] The registration and authentication server in the target area performs a modulo operation on Req to obtain Z 3 , and use the fourth timestamp and the public key pair Z of the registered vehicle 3 Encrypt and send to the registered vehicles applying for cross-domain;

[0034] Apply for cross-domain registered vehicle verification of the fourth timestamp and Z 3 Decryption is performed to obtain the response of the registration and authentication server in the target area to the cross-domain request.

[0035] Optionally, the expression for obtaining the private key of the registered vehicles in the current area is:

[0036]

[0037] In the formula, SK A,H Represents a temporary session key; M' 7 Represents the decrypted modular operation M 7 , RT A,H Indicates the random number generated when area A communicates with area H.

[0038] Compared with the prior art, the present invention has the following advantages and technical effects:

[0039] The present invention proposes a lightweight cross-domain authentication scheme for Internet of Vehicles based on blockchain technology, which has significant technical effects. By initializing the system to generate public parameters and determine the trust node, a security foundation is laid for the entire authentication process. The introduction of the trust node effectively solves the problem of trust transfer in cross-domain authentication of Internet of Vehicles and reduces the complex interactions in the authentication process.

[0040] After registering at the trust node, the vehicle user can easily apply for cross-domain authentication to the authentication server in the target area. The authentication server in the target area strictly verifies the vehicle identity information to ensure the security of the cross-domain request. After successful verification, the registration authentication server and the computing server work together to complete the verification and key negotiation and generate a temporary session key. After the vehicle decrypts the private key, it can communicate securely. This solution uses the decentralized and tamper-proof characteristics of blockchain technology to improve the efficiency and security of cross-domain authentication and reduce communication costs. It is suitable for the needs of frequent cross-domain vehicles in the Internet of Vehicles scenario and provides reliable protection for the secure communication of the Internet of Vehicles. Brief Description of the Drawings

[0041] The drawings forming a part of this application are used to provide a further understanding of this application. The schematic embodiments and descriptions thereof of this application are used to explain this application and do not constitute an improper limitation to this application. In the drawings:

[0042] Figure 1 is the system model diagram of the embodiment of the present invention;

[0043] Figure 2 is the process diagram of a vehicle user registering with TI in the embodiment of the present invention;

[0044] Figure 3 is the process diagram of the authentication server VS registering with TI in the embodiment of the present invention;

[0045] Figure 4 is the process diagram of the computing server PS registering with TI in the embodiment of the present invention;

[0046] Figure 5 is the process diagram of cross - domain request and cross - domain request confirmation in the embodiment of the present invention;

[0047] Figure 6 is the process diagram of key negotiation in the embodiment of the present invention. Detailed Description of the Embodiments

[0048] It should be noted that, without conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The following will refer to the drawings and combine with the embodiments to detail this application.

[0049] It should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer - executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0050] Embodiment 1

[0051] To solve the above - mentioned technical problems, the present invention provides a lightweight cross - domain authentication method for the Internet of Vehicles based on blockchain technology. The emergence of blockchain technology provides new ideas and possibilities for solving the cross - domain authentication problem. As a distributed ledger technology, blockchain has characteristics such as decentralization, immutability, traceability, and high transparency. These characteristics enable the cross - domain authentication scheme based on blockchain to avoid the single - point failure problem of traditional centralized authentication schemes and ensure the security and reliability of authentication information through a distributed node consensus mechanism. Due to the encryption technology and distributed storage of blockchain, the identity information of users can be securely stored and verified without relying on a single centralized institution, greatly reducing the risk of privacy leakage.

[0052] In the present invention, vehicle users and servers need to apply for registration to a distributed trusted authority. Compared with the traditional method, this distributed architecture can significantly reduce the burden of the registration process. By taking advantage of the blockchain network, registered virtual information can be shared, laying a solid foundation for the smooth progress of the subsequent authentication process.

[0053] When a vehicle user has a cross-domain demand, he or she can initiate a cross-domain request to the authentication server in the target cross-domain area according to his or her actual situation. At this time, the authentication server in the area where the vehicle is located will communicate with the authentication server in the target cross-domain area. The former will pass the relevant address of the vehicle in the blockchain to the latter to help it accurately find and confirm the legitimacy of the vehicle on the blockchain, and then make appropriate judgments on the cross-domain request. It is worth mentioning that every search operation for a vehicle will leave a detailed record on the relevant blockchain, which provides a solid basis for subsequent traceability work and greatly facilitates the management and supervision of the entire cross-domain authentication process.

[0054] In addition, the server will also conduct temporary key negotiation with the vehicle. The present invention has many significant advantages. In terms of reliability, it greatly enhances the credibility of vehicle cross-domain authentication; in terms of security, it fully protects the safe execution of cross-domain tasks; in terms of privacy protection, it fully guarantees the security of privacy information such as vehicle identity, providing an innovative and efficient solution for the field of vehicle cross-domain authentication.

[0055] The important terms and constraints of the present invention are as follows:

[0056] Trusted Institution (TI): This is a professional institution or entity organization with absolute credibility, whose core function focuses on the comprehensive control of vehicle and server registration process. At the same time, it is responsible for the management of the entire process of uploading identity information to the blockchain network. From information collection and review to final upload and storage, everything is carried out in an orderly manner under its rigorous management system, thus providing solid guarantees for the accuracy, integrity and security of vehicle and server-related identity information, and laying the foundation for the stable operation of the entire system.

[0057] Authentication Server (VS): As an indispensable part of the server, it plays a key role in the vehicle authentication process and bears the important responsibility of communicating and interacting with authentication servers in different regions. By specifically handling authentication-related matters, it effectively avoids unnecessary resource overhead and performance loss caused by mixed functions, thereby ensuring the efficiency and accuracy of the authentication process and laying a solid foundation for the stable operation of the entire vehicle authentication system.

[0058] Computing server (PS): As a key component of the server, this system has different core functions from the authentication server, and it mainly focuses on the execution of various vehicle-related computing tasks. For example, in the vehicle cross-region scenario, the generation of temporary identities and the calculation of keys are exclusively the responsibility of the computing server. Through this specialized division of labor design, it can ensure that server resources are used efficiently and quickly, avoid idleness and waste of resources, and comprehensively improve the overall performance of the server, providing stable and efficient computing support and guarantee for vehicles in complex cross-region operations and various interactive tasks.

[0059] Vehicle (V): Vehicles are equipped with specific electronic devices, whose core function is to build a stable communication link between vehicles, vehicles and infrastructure, and vehicles and cloud servers to achieve efficient data exchange. This effectively improves the overall performance and operating efficiency of vehicles in the modern transportation system, laying a solid technical foundation for the development of intelligent transportation.

[0060] like Figure 1 As shown, this embodiment provides a lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology, including the following steps:

[0061] S1. Initialize the system, generate system public parameters, and determine the trusted nodes based on the system public parameters. Participants include vehicle users V (Vehicle), cloud servers, and trusted institutions TI (Trusted Institutions). Several trusted institutions jointly maintain a blockchain ledger to record all vehicle users and cloud server registrations, transactions, and other transactions.

[0062] S1-1 System initialization: System initialization implements the establishment of the consortium chain. The trust node TI uses a pair of homomorphic keys <pk TI ,sk TI > As a node of the blockchain, build a consortium chain. When a new TI is added to the blockchain, it exchanges public keys with the nodes in the chain. Therefore, the nodes in the chain have a consistent table of TI's public keys (i.e., table ID TIi , pk TIi , i=1,...,n) values.

[0063] S2, server registration: server registration based on the trust node to obtain a registered authentication server and a registered computing server. Cloud servers are divided into authentication servers VS (Verification Server) and computing servers PS (Process Server) according to different functions. Both register with TI respectively, and TI returns verification certificates to VS and PS servers respectively based on server ID and public key.

[0064] S2-1 VS registration: the authentication server provides the authentication server identity and authentication server public key to the trust node and sends a registration request; after receiving the registration request sent by the authentication server, the trust node calculates the vehicle information set in the authentication server and generates an authentication server certificate; based on the authentication server certificate, the registered authentication server is obtained. Figure 3 As shown, the specific implementation of this embodiment includes: VS provides its own identity ID to TI VS and public key PK VS After receiving the registration request, TI first strictly verifies the identity information of VS. Then, TI calculates the vehicle information set y in the authentication server. 1 =E(SK TI ,(Addrit V ||RID V )), and generate the authentication server certificate CERIT VS =E(SK TI ,(ID VS ||PK VS ||RT VS ||VAD)), where SK TI is TI's private key, VAD is the validity period of the certificate, RT VS is a random number generated for VS. Finally, TI returns the message {y 1 ,CERIT VS}Get the registered authentication server.

[0065] S2-2 PS registration: PS provides its own identity ID and public key PK to TI PS .like Figure 4 As shown in the figure, after receiving the registration request, TI first strictly checks the identity information. Then, it generates a certificate CERIT PS =E(SK TI ,(ID PS ||PK PS ||RT PS ||VAD)), RT PS is a random number generated for PS, and VAD is the validity period of the certificate. And the PS certificate format is the same as the AS certificate format. Finally, TI returns the PS certificate CERIT to the registrant to obtain the registration calculation server.

[0066] S3. Vehicle user registration: The vehicle user applies to the trust node in the area where the vehicle is located to obtain a registered vehicle. Figure 2As shown. Vehicle users in each area register with the TI in the area. Vehicle users send a registration request to TI including real identity information and public key. When TI receives it, TI selects a random number to encrypt and hide the real identity of the vehicle, and stores the pseudonym information on the blockchain. It generates a related address and encrypts it and returns it to the authentication server VS in the area for subsequent authentication queries to verify the legitimacy of the vehicle and obtain the registered vehicle.

[0067] S3-1 Vehicle Registration: Vehicles entering the trust domain send their real identities and public keys to TI through a secure channel for registration. TI randomly selects a random number RT for each registered vehicle. V Compute virtual identity to protect the vehicle's real identity RID V =H(ID V ||P||RT V ), calculate the area to which the car belongs as ZEN V =H(RID V ||ID VS ||P) and the car's related address in the blockchain Addrit V =H(RID V ||RK TI ||RT V ) to get the registered vehicle. P represents a secret value randomly selected by TI. After successful registration, TI stores the real identity, virtual identity, area number, and randomly generated value of the vehicle, but the relevant address needs to be communicated with other TIs before it can be stored in the blockchain. Then, TI sends the pseudonym information {RID V ,ZEN V}, sent to the corresponding vehicle, and V A Store the information in a local database.

[0068] S3-2 TI submits the virtual identity generated for the vehicle identity to the blockchain as a transaction request, and uses the Kafka consensus mechanism to sort and package the transaction requests into blocks. After that, TI sends the blocks to other TIs, allowing other TIs to verify and approve these transactions. When more than half of the TIs approve, the virtual identity is officially stored in the blockchain to generate the relevant address Addrit V Then, TI will add the relevant address Addrit V Sent to the authentication server VS A , using Addrit V The vehicle's encrypted virtual identity information can be found quickly and easily.

[0069] S4. The vehicle makes a cross-domain request: Figure 5As shown, the registered vehicles in the current area apply for vehicle cross-domain communication from the registered authentication server in the target area. When the registered vehicles in the current area want to communicate across domains, they need to first send a cross-domain request to the registered authentication server VS of the cross-domain, that is, the registered authentication server of the target area. In the request, only the vehicle needs to encrypt the region to which it belongs, the cross-domain request message and the timestamp and send them to the authentication server VS.

[0070] S4-1 is a specific implementation of this embodiment. The registered vehicle in the current area belongs to area A. If it wants to perform a cross-domain task to area H, it first registers with the registration authentication server VS in area H. H , that is, the registration and authentication server in the target area, sends a cross-domain request. Calculate the cross-domain message Where RID V Yes V A Virtual identity, PK V Yes V A The public key of ZEN V is the registered region number. The message and timestamp are encrypted using the public key of the region. MESS 1 It is an encrypted cross-domain message. is the public key of the cross-region authentication server, ts 1 is the first timestamp generated. Then, V will be {MESS 1 ,RID V ,ts 1}Sent to the cross-region authentication server VS H , when VS H After receiving it, verify whether the first timestamp is valid ts' 1 -ts 1 <Δts, then decrypt to get the decrypted cross-domain message M' 1 and decryption area code ZEN' V , the registration authentication server in the target area will use the local public key Register the vehicle's virtual identity RID V and the second timestamp ts 2 Generate hash value Send {RID V ,ts 2} to the authentication server VS of the registration area A .

[0071] S5. Cross-domain request message confirmation: Figure 5As shown, the registration authentication server of the target area verifies the identity information of the registered vehicles in the current area. When the verification is successful, the registration authentication server of the target area sends a request for cross-domain approval to the registered vehicles in the current area. When the authentication server VS of the cross-region receives the cross-domain request message of the registered vehicle, it first verifies the second timestamp and obtains the area number to which it belongs, and communicates with the authentication server VS of the area to which it belongs to obtain the relevant address of the encrypted pseudonym on the blockchain. Then the authentication server of the cross-region goes to the blockchain to find the pseudonym to verify the vehicle. If the verification is successful, VS sends a request for cross-domain approval to the registered vehicle.

[0072] The process of the registered authentication server in the target area sending a cross-domain approval request to the registered vehicle in the current area includes: the authentication server in the vehicle registration area verifies the second timestamp and the hash value M 2 Then, the module operation M is sent to the registration and authentication server in the target area. 3 and a third timestamp; the registration and authentication server of the target area verifies the third timestamp and replies to Req, and records the cross-domain information of the cross-domain application vehicle in the blockchain; the registration and authentication server of the target area performs a modular operation on Req to obtain Z 3 , and use the fourth timestamp and the public key pair Z of the registered vehicle 3 The encrypted time stamp is sent to the registered vehicle applying for cross-domain; the registered vehicle applying for cross-domain verifies the fourth time stamp and 3 Decryption is performed to obtain the response of the registration and authentication server in the target area to the cross-domain request.

[0073] S5-1 is a specific implementation of this embodiment. When receiving a request from the registration authentication server VS in the target area, H When the message is received, the registration authentication server in the current area VS A First check the second timestamp ts 2 Timeliness of 2 -ts 2 <Δts, determine the validity of the time. Then, VS A Start calculation Is it the same as the M sent? 2 If they are equal, it proves that the message has not been tampered with. Then calculate the auxiliary formula Z 1 =H(RID V ||PK V ||ts 3 ), where RID V Indicates the car's virtual identity, PK V Indicates the public key of the car, ts 3 Indicates the third timestamp, modulo operation on the relevant address to be sent To the authentication server VS across regions H Send {M 3 ,ts 3}. After receiving, first verify the third timestamp ts' 3 -ts 3 <Δts, and generates a reply Req to the cross-domain message. At the same time, the cross-domain information of the vehicle will be recorded in the blockchain for subsequent tracing. The registration authentication server in the target area calculates Z' 1 Whether and Z 1 Equal, then use the modulus operation to get the relevant address y' 1 , using the car's virtual identity and VS H The public key is used to calculate the hash value and perform a modulo operation on the cross-domain message to be replied. Using the fourth timestamp and the car's public key to Z 3 Encryption protects the privacy of messages. 4 ,ts 4} to the vehicle. After receiving it, the vehicle verifies the fourth timestamp ts' 4 -ts 4 <Δts, decrypt and calculate to get Z' 3 , Z' 2 , we can perform modular operation to get Know whether the cross-domain request is successful.

[0074] S5-2 When n vehicles send messages to the authentication server VS H When a cross-domain request is initiated, each vehicle will be assigned a corresponding region number. H The virtual identity information of each vehicle will be sent to the corresponding regional authentication server VS A Then, VS H Receive the vehicle-related addresses returned by the regional authentication servers, aggregate these addresses, and send the aggregated addresses to the local trusted institution TI. After TI completes the verification of the relevant information of the n vehicles and confirms that they are qualified, it sends the information to the authentication server VS. H Feedback verification results, ultimately by VS H Based on the feedback results, corresponding responses are given to the cross-domain requests of these n vehicles.

[0075] S6. The server negotiates a key with the registered vehicle: Figure 6As shown, after the registered authentication server in the target area agrees to the cross-domain request, the registered authentication server in the target area and the registered computing server perform verification and key negotiation to obtain a temporary session key; the registered vehicle in the current area decrypts the temporary session key to obtain a private key for subsequent communication. After the cross-domain request is verified and confirmed, the authentication server VS and the computing server PS perform mutual verification and key negotiation. PS encrypts the negotiated temporary session key and sends it to the vehicle. The vehicle obtains the key after decryption for subsequent communication.

[0076] S6-1 After cross-domain verification is confirmed, the authentication server VS H and computing server PS H Authentication and key negotiation are performed. First, VS H Generate random numbers And calculate the PS H Temporary session key is the overall identity of the H region server, It is the computing server PS H The public key of Is the authentication server VS H The public key is hashed using the randomly generated number and the private key Modulo operation of certificate, key and timestamp Using the Compute Server PS H The public key encryption is obtained Send via public channel To PS H , verify the fifth timestamp, private key And calculate VS H Is the certificate consistent with PS H Verify that the certificate format is consistent Whether it has been tampered with to protect accuracy. Calculate the vehicle temporary session key These include RID V The car's virtual identity, ETK V The validity period generated, The private key of the overall server, ts 6 The sixth timestamp is obtained by modulo operation of the sixth timestamp, random value and private key. This is convenient for later encryption to obtain the private key. in Indicates the area number where the vehicle is registered, which is used to verify whether the random value is correct. V ,M 8 ,ts 6 ,G} sent to vehicle V A .

[0077] S6-2 V A After receiving the message, the decryption calculation is performed first in Indicates the private key of the vehicle in zone A. Verify whether the random value has changed Get the private key To facilitate subsequent communication. A The validity period ETK and the temporary session key SK A,H Stored in a temporary database, RT A,H Indicates the random number generated when area A communicates with area H.

[0078] The beneficial effects of the present invention include:

[0079] 1. Sharing of trusted institutions, relying on blockchain technology to build a solid underlying support architecture, realize the intercommunication and sharing of vehicle information, and at the same time accurately and tamper-proof add all access records to the blockchain, thus giving the data strong traceability. This feature not only effectively guarantees the authenticity and reliability of the data, but also can quickly trace the source with clear and accurate blockchain records when facing disputes over vehicle information tampering, efficiently resolve potential disputes, provide a solid foundation of trust and technical guarantee for the field of vehicle information management, and promote the industry to develop in a more standardized, transparent and trustworthy direction.

[0080] 2. The multi-distributed framework not only improves the scalability of the system, allowing the system to easily cope with growing scenarios, but also greatly enhances the reliability of the system. Even in complex dynamic cross-domain scenarios, this design can ensure efficient, stable and accurate management operations, effectively avoiding adverse effects such as single point failures.

[0081] 3. Cross-domain authentication: mutual authentication can be completed using simple steps, which effectively reduces the consumption of computing resources and gives full play to the sharing advantages of blockchain. This mechanism ensures that vehicle information in different regions can be accurately accessed remotely, greatly improving the efficiency of the authentication process, making it more lightweight and efficient, and providing strong support for cross-regional vehicle management and traffic. At the same time, the system is designed with full consideration of scenarios where multiple vehicles apply for authentication concurrently. It has efficient parallel processing capabilities, can verify multiple vehicles at the same time, and smoothly advance subsequent processes to ensure that the overall authentication process is not affected by the increase in the number of vehicles, and always maintains an efficient and stable operating state.

[0082] 4. Key negotiation method: rationally divide the servers based on the differences in tasks to reduce resource overhead during operation. At the same time, a temporary key for the vehicle user is generated through communication and negotiation between the two parties, thereby safeguarding the security of vehicle information, effectively preventing the risk of information leakage, and protecting the rights and interests of vehicle users.

[0083] The above are only preferred specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology, characterized in that: The following steps are involved: The system is initialized to generate system public parameters, and a trusted node is determined based on the system public parameters; Perform server registration based on the trust node to obtain a registration authentication server and a registration calculation server; The vehicle user applies for registration at the trust node in the area where the vehicle is located to obtain a registered vehicle; The registered vehicle in the current area applies to the registration authentication server in the target area for vehicle cross-domain, and the registration authentication server in the target area verifies the identity information of the registered vehicle in the current area. When the verification is successful, the registration authentication server in the target area sends a request for cross-domain approval to the registered vehicle in the current area; After the registration authentication server of the target area agrees to the cross-domain request, the registration authentication server of the target area and the registration computing server perform verification and key negotiation to obtain a temporary session key; The registered vehicles in the current area decrypt the temporary session key to obtain a private key for subsequent communication.

2. According to claim 1, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The process of obtaining a registered authentication server includes: The authentication server provides the authentication server identity and the authentication server public key to the trust node and issues a registration request; After receiving the registration request sent by the authentication server, the trust node calculates the vehicle information set in the authentication server and generates an authentication server certificate; A registered authentication server is obtained based on the authentication server certificate.

3. According to claim 2, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The authentication server certificate is: CERIT VS =E(SK TI ,(ID VS ||PK VS ||RT VS ||WHAT)) In the formula, CERIT VS Is the authentication server certificate, SK TI is the private key of TI, TI is the trusted node, VAD is the validity period of the certificate, RT VS is a random number generated for VS, PK VS is the authentication server public key, ID VS Is the authentication server identity.

4. According to claim 3, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The process of a vehicle user applying for registration with a trust node in the area where the vehicle is located to obtain a registered vehicle includes: The vehicle user provides the vehicle identity and vehicle public key to the trust node in the area where the vehicle is located and applies for vehicle registration; The trust node in the area where the vehicle is located generates a random number for the vehicle and calculates the vehicle's virtual identity, and based on the vehicle's virtual identity calculates the vehicle's area number and the vehicle's related address in the blockchain, thereby achieving successful vehicle registration.

5. According to claim 4, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The expression for calculating the zone number of a vehicle is: ZEN V =H(RID V ||ID VS ||P); The expression for calculating the relevant address of the vehicle in the blockchain is: Addrit V =H(RID V ||PK TI ||PT V ); Where RID V Indicates the virtual identity of the vehicle, ZEN V Indicates the area number to which the vehicle belongs, P represents a secret value randomly selected by TI, Addrit V Indicates the relevant address of the vehicle in the blockchain, PK TI Indicates the public key of the trusted node TI, RT V Indicates the random number selected by the trusted node TI for the vehicle applying for registration.

6. According to claim 4, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The process of a registered vehicle in the current area applying for a vehicle cross-domain request from the registration authentication server in the target area includes: The registered vehicles in the current area send cross-domain messages to the registration authentication server in the target area; The public key of the registration and authentication server in the target area encrypts the cross-domain message and the first timestamp to obtain an encrypted cross-domain message; After receiving the encrypted cross-domain message, the virtual identity of the registered vehicle and the first timestamp sent by the registered vehicle in the current area, the registration authentication server in the target area performs timestamp verification and message decryption to obtain the decrypted cross-domain message and the decrypted area number; The registration authentication server of the target area generates a hash value M2 based on the public key of the registration authentication server of the target area, the virtual identity of the registered vehicle and the second timestamp and sends it to the authentication server of the vehicle registration area.

7. According to claim 6, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The process of the registration authentication server in the target area sending a cross-domain approval request to the registered vehicle in the current area includes: After verifying the second timestamp and hash value M2, the authentication server in the vehicle registration area sends the modulo operation M3 and the third timestamp to the registration authentication server in the target area; The registration authentication server of the target area verifies the third timestamp and replies to Req, and records the cross-domain information of the cross-domain application vehicle in the blockchain; The registration authentication server in the target area performs a modular operation on Req to obtain Z3, and encrypts Z3 using the fourth timestamp and the public key of the registered vehicle and sends it to the registered vehicle applying for cross-domain; The vehicle applying for cross-domain registration verifies the fourth timestamp and decrypts Z3 to obtain a response from the registration authentication server in the target area to the cross-domain request.

8. According to claim 7, the lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology is characterized in that: The expression for obtaining the private key of the registered vehicles in the current area is: In the formula, SK A,H represents the temporary session key; M'7 represents the decrypted modulus operation M7, RT A,H Indicates the random number generated when area A communicates with area H.

Images