A lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology

Abstract

The present invention discloses a lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology, which belongs to the field of blockchain and vehicle privacy protection. The method includes the following steps: determining a trust node based on system public parameters; performing server registration based on the trust node to obtain a registration authentication server and a registration calculation server; a vehicle user applies for registration to the trust node in the area where the vehicle is located to obtain a registered vehicle; a registered vehicle in the current area applies to the registration authentication server in the target area for vehicle cross-domain authentication, and after the registration authentication server in the target area successfully verifies, the registration authentication server in the target area sends a cross-domain consent request to the registered vehicle in the current area; after the registration authentication server in the target area agrees to the cross-domain request, the registration authentication server in the target area and the registration calculation server in the target area 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.

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 the Internet of Vehicles based on blockchain technology. Background Art

[0002] With the rapid development of information technology, the internet has become deeply integrated into every aspect of people's lives, and information exchange and collaboration between businesses and organizations are becoming increasingly frequent. In this context, cross-domain authentication has become a critical requirement. Different domains may represent different businesses, institutions, network service providers, or different business systems. Secure and efficient user identity authentication and authorization are required between them 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 one domain, the authentication information is stored on a centralized server. When a user accesses another domain, that domain needs to request verification of the user's identity from the centralized server. This approach has many problems: First, the centralized server becomes a single point of failure. If the server is attacked or fails, the entire cross-domain authentication system will be at risk of paralysis. Second, the user's private data is stored on a centralized server, which is prone to data leakage risks. Once hacked, a large amount of user sensitive information may be stolen. Third, establishing trust between different domains often requires complex negotiations and protocols. In addition, when new domains are added or existing domains are withdrawn, the system's scalability and flexibility are poor, requiring significant adjustments to the entire authentication architecture. 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 existing technologies.

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

[0006] System initialization generates system public parameters, and determines the trusted nodes 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 vehicles in the current area apply to the registration authentication server in the target area for vehicle cross-domain. The registration authentication server in the target area verifies the identity information of the registered vehicles 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 vehicles 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 calculation 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] Where 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 the 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 to 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. Based on the vehicle's virtual identity, the trust node calculates the vehicle's area number and the vehicle's related address in the blockchain, thereby successfully registering the vehicle.

[0022] Optionally, the expression for calculating the area 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, and Addrit V Indicates the vehicle's relevant address in the blockchain, PK TI Indicates the public key of the trusted node TI, RT V Indicates the random number selected by the trust node TI for the vehicle applying for registration.

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

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

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

[0028] The registration authentication server in the target area receives 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, and then 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 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 the hash value M2 to the authentication server of the vehicle registration area.

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

[0031] After verifying the second timestamp and hash value M2, the authentication server in the vehicle registration area sends the modular operation M3 and the third timestamp to the registration authentication server in the target area;

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

[0033] The registration authentication server in the target area performs a modular operation on Req to obtain Z3, encrypts Z3 using the fourth timestamp and the public key of the registered vehicle, and sends the encrypted data to the registered vehicle applying for cross-domain authentication.

[0034] 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.

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

[0036]

[0037] Where SK A,H represents the temporary session key; M'7 represents the decrypted modular operation M7, 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] This paper proposes a lightweight, cross-domain authentication scheme for connected vehicles (IoVs) based on blockchain technology, demonstrating significant technical benefits. By initializing the system to generate public parameters and identify trusted nodes, it lays a secure foundation for the entire authentication process. The introduction of trusted nodes effectively addresses the trust transfer issue in cross-domain IoV authentication, reducing the complexity of the authentication process.

[0040] After registering with a trusted node, a vehicle user can conveniently request a cross-domain authentication request from the authentication server in the target region. The authentication server in the target region rigorously verifies the vehicle's identity to ensure the security of the cross-domain request. Upon successful verification, the registration authentication server collaborates with the computing server to complete verification and key negotiation, generating a temporary session key. The vehicle decrypts the private key and securely communicates. This solution leverages the decentralized and tamper-proof nature of blockchain technology to improve the efficiency and security of cross-domain authentication and reduce communication costs. It is suitable for the frequent cross-domain interactions of vehicles in connected vehicle scenarios, providing reliable assurance for secure communication in the connected vehicle network. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which constitute part of this application, are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. In the accompanying drawings:

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

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

[0044] Figure 3 This is a diagram of the process of the authentication server VS registering with the TI according to an embodiment of the present invention;

[0045] Figure 4 This is a diagram showing the process of computing server PS registering with TI according to an embodiment of the present invention;

[0046] Figure 5 A diagram of the cross-domain request and cross-domain request confirmation process according to an embodiment of the present invention;

[0047] Figure 6 This is a diagram of the key negotiation process according to an embodiment of the present invention. DETAILED DESCRIPTION

[0048] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

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

[0050] Example 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 has provided new ideas and possibilities for solving cross-domain authentication problems. As a distributed ledger technology, blockchain has the characteristics of decentralization, immutability, traceability, and high transparency. These characteristics enable blockchain-based cross-domain authentication solutions to avoid the single point of failure problem of traditional centralized authentication solutions 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, user identity information can be securely stored and verified without relying on a single centralized organization, greatly reducing the risk of privacy leakage.

[0052] In this invention, vehicle users and servers must submit registration applications to a distributed trusted authority. Compared to traditional methods, this distributed architecture significantly reduces the burden of registration. Leveraging the advantages of the blockchain network, virtual registration information can be shared, laying a solid foundation for the smooth implementation of the subsequent authentication process.

[0053] When a vehicle user has a cross-domain need, they can initiate a cross-domain request to the authentication server in the target cross-domain area based on their actual situation. At this time, the authentication server in the area where the vehicle is located and the authentication server in the target cross-domain area will communicate. 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 an appropriate judgment 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 tracing work and greatly facilitates the management and supervision of the entire cross-domain authentication process.

[0054] In addition, the server will also conduct a temporary key negotiation with the vehicle. This 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 private 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] A Trusted Institution (TI) is a professional, trustworthy organization or entity whose core responsibility is to oversee the complete vehicle and server registration process. They are also responsible for managing the entire process of uploading identity information to the blockchain network. From information collection and review to final upload and storage, all processes are carried out in an orderly manner under their rigorous management system. This ensures the accuracy, integrity, and security of vehicle and server identity information, laying the foundation for the stable operation of the entire system.

[0057] The Verification Server (VS) is an essential server component that plays a key role in the vehicle authentication process and is responsible for communicating with authentication servers in different regions. By specifically handling authentication-related tasks, it effectively avoids unnecessary resource overhead and performance loss caused by a mix of 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 focuses on executing various vehicle-related computing tasks. For example, in a vehicle's cross-regional operation, the generation of temporary identities and key calculations are the exclusive responsibility of this computing server. This specialized division of labor ensures efficient and high-speed utilization of server resources, avoiding idle and wasted resources, comprehensively improving the overall performance of the server, and providing stable and efficient computing support and guarantees for vehicles in complex cross-regional operations and various interactive tasks.

[0059] Vehicle (V): A vehicle is equipped with specialized electronic equipment whose core function is to establish robust communication links between vehicles, between vehicles and infrastructure, and between vehicles and cloud servers, enabling efficient data exchange. This effectively improves the overall performance and operational efficiency of vehicles within modern transportation systems, laying a solid technological foundation for the development of intelligent transportation.

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

[0061] S1. System initialization generates public system parameters and determines trusted nodes based on these parameters. Participants include vehicle users (V), cloud servers, and trusted institutions (TIs). These institutions jointly maintain a blockchain ledger that records all vehicle user and cloud server registrations, transactions, and other transactions.

[0062] S1-1 System Initialization: System initialization realizes 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 is performed based on the trust node to obtain a registered authentication server and a registered computing server. Cloud servers are divided into verification servers (VS) and process servers (PS) based on their functions. Both servers register with the TI. The TI returns verification certificates to the VS and PS servers, respectively, based on the 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 from 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 y1=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 the private key of TI, VAD is the validity period of the certificate, RT VS Is a random number generated for VS. Finally, TI returns the message {y1, 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, after receiving the registration request, TI first strictly verifies 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 the PS, and VAD is the validity period of the certificate. 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 in the figure, vehicle users in each region register with the local TI. Vehicle users send a registration request to the TI, including their real identity information and public key. When the TI receives the request, it selects a random number to encrypt and hide the vehicle's real identity, stores the pseudonym information on the blockchain, generates a related address, and encrypts it before returning it to the local authentication server VS 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 vehicle's real identity, virtual identity, area number, and randomly generated value, 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 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 to 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, a registered vehicle in the current region requests a vehicle cross-domain request from the registration and authentication server in the target region. When a registered vehicle in the current region wishes to communicate across domains, it must first send a cross-domain request to the registration and authentication server (VS) in the target region. The request only requires the vehicle to encrypt the region it belongs to, the cross-domain request message, and the timestamp before sending it 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 sends a request to the registration authentication server VS in area H. H , that is, the registration and authentication server of the target area, sends a cross-domain request. Calculate the cross-domain message RID V It is V A Virtual identity, PK V It is V A The public key of ZEN V It is the registered area code. The message and timestamp are encrypted using the public key of the cross-area. MESS1 is an encrypted cross-domain message. is the public key of the cross-region authentication server, ts1 is the first timestamp generated. Then, V will {MESS1, RID V ,ts1} is sent to the cross-region authentication server VS H , when VS H After receiving it, first verify whether the first timestamp is valid ts'1-ts1<Δts, then decrypt to obtain the decrypted cross-domain message M'1 and the decrypted zone number ZEN' V , the registration authentication server in the target area will use the local public key Registered vehicle virtual identity RID V Generate a hash value with the second timestamp ts2 Send {RID V ,ts2} to the authentication server VS of the registration area A .

[0071] S5. Cross-domain request message confirmation: Figure 5 As shown, the target region's registration authentication server verifies the identity information of registered vehicles in the current region. If the verification is successful, the target region's registration authentication server sends a cross-domain approval request to the registered vehicles in the current region. When the cross-region authentication server (VS) receives the cross-domain request message from the registered vehicle, it first verifies the second timestamp and obtains the region number. It then communicates with the authentication server (VS) in the region to obtain the encrypted pseudonym's address on the blockchain. The cross-region authentication server then searches the blockchain for the pseudonym's verified vehicle. If the verification is successful, the VS sends a cross-domain approval request to the registered vehicle.

[0072] The process of the registration authentication server of the target area sending a cross-domain request to the registered vehicle of the current area includes: after the authentication server of the vehicle registration area verifies the second timestamp and the hash value M2, it sends a modular operation M3 and a third timestamp to the registration authentication server of the target area; the registration authentication server of the target area verifies the third timestamp and replies to Req, and at the same time records the cross-domain information of the cross-domain application vehicle in the blockchain; the registration authentication server of the target area performs a modular operation on Req to obtain Z3, and uses the fourth timestamp and the public key of the registered vehicle to encrypt Z3 and send it to the registered vehicle applying for cross-domain; the registered vehicle applying for cross-domain verifies the fourth timestamp and decrypts Z3 to obtain a reply from the registration authentication server of 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 of the current area VS A First, check the timeliness of the second timestamp ts2, ts'2-ts2<Δts, to determine the validity of the time. Then, VS A Start calculation Is it equal to the sent M2? If it is equal, it proves that the message has not been tampered with. Then calculate the auxiliary formula Z1=H(RID V ||PK V ||ts3), where RID V Indicates the car's virtual identity, PK V Represents the public key of the car, ts3 represents the third timestamp, and performs a modular operation on the relevant address to be sent To the authentication server VS across regions H Send {M3, ts3}. After receiving, first verify the third timestamp ts'3-ts3<Δts, and generate a reply Req to the cross-domain message. At the same time, the cross-domain information of the car will be recorded in the blockchain for easy traceability. The registration and authentication server in the target area calculates whether Z'1 is equal to Z1, and then uses the modular operation to obtain the relevant address y'1, using the virtual identity of the car 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. The fourth timestamp and the public key of the vehicle are used to encrypt Z3 to protect the privacy of the message. {M4, ts4} is sent to the vehicle through a public channel. After the vehicle receives it, it verifies that the fourth timestamp ts'4-ts4<Δts, decrypts and calculates Z'3 and Z'2, and then performs modular operations to obtain Know whether the cross-domain request is successful.

[0074] S5-2 When n vehicles send data to the authentication server VS H When a cross-domain request is initiated, each vehicle will obtain 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 server, aggregate these addresses, and send the aggregated related addresses to the local trusted institution TI. After TI completes the verification of the relevant information of these 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 6 As shown, after the target region's registered authentication server agrees to the cross-domain request, the target region's registered authentication server and the registered computing server perform verification and key negotiation to obtain a temporary session key. The registered vehicle in the current region 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 computing server PS perform mutual verification and key negotiation. The PS encrypts the negotiated temporary session key and sends it to the vehicle, which decrypts it to obtain the key 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 a randomly generated number and the private key. Modulo operation of certificate, key and timestamp Using the computing server PS H The public key encryption is obtained Send via public channel to PS H , verify the fifth timestamp and private key And calculate VS H Is the certificate consistent with PSH Verify that the certificate format is consistent Whether it has been tampered with to protect the accuracy. Calculate the vehicle temporary session key These include RID V The car's virtual identity, ETK V The generated validity period, The private key of the entire server, ts6 sixth timestamp. Obtained by modular 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 ,M8,ts6,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 area 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, this system enables the interoperability and sharing of vehicle information. All access records are accurately and immutably added to the blockchain, thus providing strong traceability. This feature not only effectively guarantees the authenticity and reliability of the data, but also enables rapid tracing and efficient resolution of potential disputes in the event of vehicle information tampering disputes, leveraging clear and accurate blockchain records. This provides a solid foundation of trust and technical support for the vehicle information management sector, driving the industry towards a more standardized, transparent, and trustworthy direction.

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

[0081] 3. Cross-domain authentication: Mutual authentication can be completed using simple steps, effectively reducing the consumption of computing resources while fully leveraging 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 access. At the same time, the system design fully considers the scenario of multiple vehicles applying for authentication concurrently. It has efficient parallel processing capabilities, can carry out verification work on multiple vehicles at the same time, and smoothly advance subsequent processes, ensuring that the overall authentication process is not affected by the increase in the number of vehicles and always maintains an efficient and stable operation state.

[0082] 4. Key negotiation method: Servers are rationally divided based on task differences 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 merely preferred embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A lightweight cross-domain authentication method for Internet of Vehicles based on blockchain technology, characterized by: The following steps are involved: System initialization generates system public parameters, and determines the trusted nodes 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 vehicles in the current area apply to the registration authentication server in the target area for vehicle cross-domain. The registration authentication server in the target area verifies the identity information of the registered vehicles 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 vehicles in the current area. The process of the registration authentication server of the target area sending a cross-domain request to the registered vehicle of the current area includes: after the authentication server of the vehicle registration area verifies the second timestamp and the hash value M2, it sends a modular operation M3 and a third timestamp to the registration authentication server of 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 of 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 registered vehicle applying for cross-domain verifies the fourth timestamp and decrypts Z3 to obtain a reply to the cross-domain request from the registration authentication server of the target 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 calculation 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; The expression for obtaining the private key of the registered vehicles in the current area is: Where SK A,H represents the temporary session key; M′7 represents the decrypted modular operation M7, RT A,H Indicates the random number generated when area A communicates with area H.

2. The lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology according to claim 1 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 from 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. The lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology according to claim 2 is characterized in that: The authentication server certificate is: CERIT VS =E(SK TI ,(ID VS ||PK VS ||RT VS ||WHAT)) Where 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 the random number generated for VS, PK VS Is the authentication server public key, ID VS Is the authentication server identity.

4. The lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology according to claim 3 is characterized in that: The process for a vehicle user to apply 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. Based on the vehicle's virtual identity, the trust node calculates the vehicle's area number and the vehicle's related address in the blockchain, thereby successfully registering the vehicle.

5. The lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology according to claim 4 is characterized in that: The expression for calculating the area code 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 ||RT 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, and Addrit V Indicates the vehicle's relevant address in the blockchain, PK TI Indicates the public key of the trusted node TI, RT V Indicates the random number selected by the trust node TI for the vehicle applying for registration.

6. The lightweight cross-domain authentication method for the Internet of Vehicles based on blockchain technology according to claim 4 is characterized in that: The process for a registered vehicle in the current area to apply for a vehicle cross-domain request from the registration authentication server in the target area includes: The registered vehicles in the current area send a cross-domain message to the registration authentication server in the target area; Encrypting the cross-domain message and the first timestamp using the public key of the registration authentication server in the target area to obtain an encrypted cross-domain message; The registration authentication server in the target area receives 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, and then 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 the hash value M2 to the authentication server of the vehicle registration area.

Images