Cross-domain authentication and key agreement method and system for unmanned aerial vehicle assisted internet of vehicles

Abstract

The invention relates to a cross-domain authentication and key agreement method and system for an unmanned aerial vehicle assisted Internet of Vehicles. The method is applied to an emergency rescue system comprising an unmanned aerial vehicle, a vehicle, a trusted authority (TA) and an alliance chain. A TA is deployed in each communication domain to serve as an alliance chain consensus node, the node obtains a core parameter after TA dual verification registration, the node generates a temporary parameter to initiate an authentication request during cross-domain rescue, a cross-domain voucher uplink consensus is generated after TA verification, and the three parties collaboratively negotiate a session key based on a Chebyshev Diffie-Hellman problem and perform uplink evidence storage. According to the scheme, the Chebyshev mapping lightweight characteristic and the alliance chain distributed trust advantage are fused, privacy and responsibility traceability are guaranteed, various attacks are resisted, the whole process is low in time consumption, the emergency rescue real-time requirement is met, and safety guarantee is provided for key data interaction.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted ad hoc network communication security technology, and in particular to a cross-domain authentication and key negotiation method and system for unmanned aerial vehicle-assisted vehicle networking. Background Technology

[0002] In emergency rescue scenarios such as mountain search and rescue and disaster site communication, unmanned aerial vehicle-mounted ad hoc networks (VANETs) can overcome the limitations of damaged or insufficient coverage of ground communication infrastructure, enabling real-time transmission of critical data such as rescue commands and the location of the injured. This is of great significance for improving rescue efficiency and reducing casualties. However, existing related technologies are insufficient to meet the safety and real-time requirements of emergency rescue scenarios and have many prominent shortcomings:

[0003] Insufficient privacy protection is one of the core issues. Most solutions rely on a single trusted authority (TA) to centrally manage node identity information. The TA can directly obtain the real identity of the node, which poses a risk of privacy leakage. In cross-domain scenarios, there is a lack of effective identity isolation mechanisms between TAs in different domains, which can easily lead to the tracking of node identities, violating the requirements for privacy protection.

[0004] The security of key negotiation is weak. Existing solutions are mostly two-way key negotiation between vehicles and drones, lacking a three-party verification process involving TAs. Keys are easily tampered with, forged or cracked. The cross-domain key derivation mechanism is imperfect and does not consider key collaborative generation in scenarios with multiple TAs, making it difficult to adapt to complex cross-domain communication needs.

[0005] Limited resistance to attacks means that existing solutions are unable to effectively defend against common attacks such as password guessing, replay attacks, man-in-the-middle attacks, and lost smart cards. Furthermore, the lack of a cross-domain revocation mechanism after a smart card is lost means that the lost smart card may be illegally used to participate in cross-domain communications, threatening the security of rescue data.

[0006] The lack of distributed trust is a prominent issue. Without the introduction of blockchain technology, cross-domain authentication relies on offline negotiation between multiple TAs, resulting in low authentication efficiency and a lack of traceability. Authentication records and key information are stored on centralized nodes, posing a single point of failure risk. Once a node is compromised, it will lead to a large-scale security incident.

[0007] Furthermore, the interaction steps of cross-domain authentication and key negotiation are unclear, and there is a lack of strict message verification and timestamp verification mechanisms, which can easily lead to problems such as message loss and chaotic timeout processing, affecting the real-time communication in emergency rescue scenarios.

[0008] Therefore, there is an urgent need to design an authentication and key negotiation scheme that features standardized interaction processes, high security, strong cross-domain adaptability, and lightweight design to meet the dual requirements of communication security and real-time performance in emergency rescue scenarios. Summary of the Invention

[0009] Therefore, it is necessary to provide a cross-domain authentication and key negotiation method and system for UAV-assisted vehicle networks that is efficient, secure, privacy-preserving, and trustworthy across domains, addressing the aforementioned technical issues.

[0010] A cross-domain authentication and key negotiation method for drone-assisted vehicle-to-everything (V2X) networks is disclosed. The method is implemented in a drone-assisted V2X emergency rescue system composed of drones, vehicles, trusted authoritative institutions, and a consortium blockchain. The drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authoritative institution. All trusted authoritative institutions serve as consensus nodes of the consortium blockchain and are equipped with cross-domain authentication smart contracts and key verification smart contracts. The drones and vehicles act as lightweight terminal nodes of the consortium blockchain. The method includes: Each of the aforementioned trusted authoritative institutions negotiates global parameters through an offline security meeting. These global parameters are made public to all nodes through the genesis block of the consortium blockchain. At the same time, they generate exclusive public and private key pairs, encapsulate their own identity identifier, public key, and registration timestamp into registration information, and register it on the blockchain through a cross-domain authentication smart contract. The lightweight terminal nodes complete registration through a trusted authority in their respective communication domains, submitting information including their real identity identifier and login password. After the trusted authority double-verifies the uniqueness of their identity, they obtain core parameters containing the false identity and public / private key pairs. These core parameters are stored in their own encryption module. When lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on Chebyshev mapping, encapsulate a cross-domain authentication request containing a pseudo-identity, temporary parameters, timestamp, and rescue scenario identifier, and send it to a trusted authoritative institution in their respective communication domain. After receiving the request, the trusted authoritative institutions of both parties first verify the timeliness of the timestamp, then query the status and legitimacy of the target node through the consortium blockchain. After the verification is successful, a cross-domain certificate is generated and digitally signed, and submitted to the consortium blockchain for verification by the PBFT consensus algorithm and then synchronized to the relevant nodes. The lightweight terminal node and the trusted authoritative institutions of both parties collaborate to derive key components, and generate session keys based on the difficulty of the Chebyshev problem. After the keys are verified to be consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

[0011] In one embodiment, the global parameters include a large prime number, a randomly selected Chebyshev mapping seed, and three types of secure hash functions. The three types of hash functions are used to generate identity obfuscation and signature, key derivation, and session key, respectively. The global parameters are synchronized to ensure parameter consistency across all nodes through the genesis block of the consortium blockchain.

[0012] In one embodiment, during the lightweight terminal node line registration process: The lightweight terminal node sets its own login password independently, and then generates a random number through its own encrypted storage module. The login password and the random number are then concatenated using a hash function to obtain a password derived value. The lightweight terminal node encapsulates the real identity identifier, hardware identifier, and the password derivation value into a registration request, and sends it to a trusted authoritative institution in its communication domain through offline verification or AES-256 encrypted channel; After receiving the request, the relevant trusted authority performs dual verification. Once the verification is successful, it generates core parameters including a private key, a public key, and a pseudo-identity. The registration record of the lightweight terminal node is then uploaded to the blockchain for filing through a cross-domain authentication smart contract. Finally, the core parameters are sent to the corresponding lightweight terminal node through an AES-256 encrypted channel. The lightweight terminal node stores the core parameters in its own encryption module and sets exclusive access permissions, allowing only legitimate commands to read them.

[0013] In one embodiment, the dual verification includes: the trusted authority first queries the local database to verify whether the node hardware identifier has been registered, and then calls the query interface of the cross-domain authentication smart contract to verify the uniqueness of the node's true identity identifier through the consortium blockchain historical records.

[0014] In one embodiment, the cross-domain authentication request is transmitted via a C-V2X public channel. The pseudo-identity in the request message is generated by hashing the node's real identity identifier, the public key of the local trusted authority, and the Chebyshev mapping seed. The local trusted authority only maintains a one-to-one mapping table between the pseudo-identity and the real identity identifier in its own encrypted database and does not store it on the blockchain.

[0015] In one embodiment, the timestamp adopts a Unix second-level format, and all cross-domain interaction messages contain this field. Trusted authoritative institutions verify the freshness of messages by calculating whether the difference between the current time and the message timestamp does not exceed a preset threshold. If the timeout occurs, the corresponding error code is returned and the message is rejected.

[0016] In one embodiment, the cross-domain credential is a structured data format, including the public key of the trusted authority, the pseudo identity of the node, temporary parameters, the rescue scenario identifier, the timestamp, and the digital signature; The PBFT consensus algorithm of the consortium blockchain requires a preset number of trusted authoritative nodes to verify the validity of the signature and the integrity of the fields, and the consensus delay does not exceed a preset time. After the cross-domain certificate is approved, it is synchronized to all consensus nodes.

[0017] In one embodiment, the key component is derived based on the semigroup property of Chebyshev mappings, including: Both trusted authorities first calculate the cross-domain key component and digitally sign it based on their own private keys and the temporary parameters submitted by the lightweight terminal node, and then send it to the corresponding lightweight terminal node through the AES-256 encrypted C-V2X channel; After receiving the data, the lightweight terminal node first performs multi-layer verification, sequentially verifying the legality of the public key of the trusted authority, the validity of the key component signature, and the timeliness of the cross-domain credential. After all verification steps are passed, it then generates three types of key components based on Chebyshev mapping operations, including a trusted connection component with the local trusted authority, a cross-domain temporary component with the other party node, and its own local temporary key.

[0018] In one embodiment, the method further includes password updates, revocations, and recovery for lightweight terminal nodes: When the password is updated, the lightweight terminal node inputs the old password, which is verified as valid by its own encryption module. Then, it generates a new password and a new random number, calculates the new password derivation value, and sends an update request to a trusted authority in its communication domain. After verification by the trusted authority, the blockchain synchronously updates the corresponding password hash record. After the lightweight terminal node revocation certificate is generated and uploaded to the blockchain by the trusted authority of its communication domain, it must be verified by PBFT consensus before it can be effective across domains. If a valid revocation record is found during cross-domain authentication, communication will be rejected. When a lightweight terminal node regains its legitimacy, the trusted authority in its communication domain generates a revocation certificate and uploads it to the blockchain for consensus. After verification, the node regains its normal cross-domain communication permissions, and the consortium blockchain updates the node's status record synchronously.

[0019] This application also provides a cross-domain authentication and key negotiation system for drone-assisted vehicle networks. The system comprises a drone-assisted vehicle network consisting of drones, vehicles, trusted authoritative institutions, and a consortium blockchain. The drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authoritative institution. All trusted authoritative institutions serve as consensus nodes of the consortium blockchain and are equipped with cross-domain authentication smart contracts and key verification smart contracts. The drones and vehicles serve as lightweight terminal nodes of the consortium blockchain. The system includes: Each of the aforementioned trusted authoritative institutions negotiates global parameters through an offline security meeting. These global parameters are made public to all nodes through the genesis block of the consortium blockchain. At the same time, they generate exclusive public and private key pairs, encapsulate their own identity identifier, public key, and registration timestamp into registration information, and register it on the blockchain through a cross-domain authentication smart contract. The lightweight terminal nodes complete registration through a trusted authority in their respective communication domains, submitting information including their real identity identifier and login password. After the trusted authority double-verifies the uniqueness of their identity, they obtain core parameters containing the false identity and public / private key pairs. These core parameters are stored in their own encryption module. When lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on Chebyshev mapping, encapsulate a cross-domain authentication request containing a pseudo-identity, temporary parameters, timestamp, and rescue scenario identifier, and send it to a trusted authoritative institution in their respective communication domain. After receiving the request, the trusted authoritative institutions of both parties first verify the timeliness of the timestamp, then query the status and legitimacy of the target node through the consortium blockchain. After the verification is successful, a cross-domain certificate is generated and digitally signed, and submitted to the consortium blockchain for verification by the PBFT consensus algorithm and then synchronized to the relevant nodes. The lightweight terminal node and the trusted authoritative institutions of both parties collaborate to derive key components, and generate session keys based on the difficulty of the Chebyshev problem. After the keys are verified to be consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

[0020] The aforementioned cross-domain authentication and key negotiation method and system for drone-assisted vehicle-to-everything (V2X) networks are implemented in a drone-assisted V2X emergency rescue system composed of drones, vehicles, trusted authoritative institutions, and a consortium blockchain. Drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authoritative institution. All trusted authoritative institutions serve as consensus nodes on the consortium blockchain and are equipped with cross-domain authentication and key verification smart contracts. Drones and vehicles act as lightweight terminal nodes on the consortium blockchain. Each trusted authoritative institution negotiates global parameters through an offline secure meeting. These global parameters are then publicly disclosed to all nodes via the consortium blockchain's genesis block. Simultaneously, each institution generates a unique public-private key pair, encapsulating its identity identifier, public key, and registration timestamp into registration information. This information is then uploaded to the blockchain via the cross-domain authentication smart contract for record-keeping. Lightweight terminal nodes complete registration through their respective trusted authoritative institutions within their communication domains, submitting information including their real identity identifier and login password. After the identity is double-verified by a trusted authority, the system obtains core parameters containing the false identity and public / private key pairs. These core parameters are stored in its own encryption module. When lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on the Chebyshev mapping. They then encapsulate a cross-domain authentication request containing the false identity, temporary parameters, timestamp, and rescue scenario identifier, and send it to the trusted authority in their respective communication domains. Upon receiving the request, both trusted authorities first verify the timeliness of the timestamp, then query the target node's status and legitimacy through the consortium blockchain. After successful verification, a cross-domain credential is generated and digitally signed. This credential is then submitted to the consortium blockchain and synchronized to relevant nodes after verification using the PBFT consensus algorithm. The lightweight terminal node and both trusted authorities collaboratively derive key components and negotiate a session key based on the intractability of the Chebyshev problem. After key verification is consistent, the key negotiation record is uploaded to the blockchain for evidence storage through a key verification smart contract.

[0021] This method employs a collaborative architecture combining the control of trusted authoritative institutions within a domain and the consensus of a cross-domain consortium blockchain. It integrates the lightweight computational characteristics of Chebyshev chaotic mapping with the distributed trust advantages of consortium blockchains, adapting to the resource constraints of drones and vehicles while achieving efficient cross-domain trust transfer. By leveraging a pseudo-identity generation mechanism and identity mapping management by local trusted authoritative institutions, it ensures both privacy and accountability in cross-domain communication. Based on the intractability of the Chebyshev Diffie-Hellman Problem (CMDHP), it strengthens key security defenses, effectively resisting common attacks such as replay attacks, man-in-the-middle attacks, and lost smart cards. Through standardized cross-domain authentication processes, timestamp verification mechanisms, and the PBFT consensus algorithm, it ensures minimal time consumption for the entire cross-domain authentication and key negotiation process, meeting the real-time requirements of emergency rescue. Furthermore, the consortium blockchain's immutable storage of cross-domain credentials and key negotiation records enables traceability and full-process auditing, providing reliable security guarantees that combine confidentiality, integrity, and availability for critical data interactions such as rescue command transmission and casualty location reporting in drone-assisted vehicle-to-everything (V2X) emergency rescue scenarios. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a cross-domain authentication and key negotiation method for unmanned aerial vehicle-assisted vehicle networking in one embodiment. Figure 2 This is a schematic diagram of the architecture of a cross-domain authentication and key negotiation system for drone-assisted vehicle networking in one embodiment. Figure 3 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] To address the problems in existing technologies, such as insufficient privacy protection in cross-domain communication, weak security in key negotiation, limited resistance to attacks, lack of distributed trust, and non-standard interaction processes, Figure 1 As shown, a cross-domain authentication and key negotiation method for drone-assisted vehicle-to-everything (V2X) networks is provided. This method is implemented in a drone-assisted V2X emergency rescue system composed of drones, vehicles, trusted authorities, and a consortium blockchain. The drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authority. All trusted authorities serve as consensus nodes of the consortium blockchain and are equipped with cross-domain authentication smart contracts and key verification smart contracts. The drones and vehicles act as lightweight terminal nodes of the consortium blockchain. The method specifically includes the following steps: In step S100, each trusted authority negotiates global parameters through an offline security meeting. The global parameters are made public to all nodes through the genesis block of the consortium blockchain. At the same time, a unique public-private key pair is generated, and its own identity identifier, public key, and registration timestamp are encapsulated into registration information and filed on the blockchain through a cross-domain authentication smart contract.

[0025] In step S110, the lightweight terminal nodes complete the registration through the trusted authority of their respective communication domain, submitting information including real identity identifier and login password. After the trusted authority double-verifies the uniqueness of the identity, the nodes obtain the core parameters containing the false identity and public / private key pair, which are stored in their own encryption module.

[0026] In step S120, when lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on Chebyshev mappings, encapsulate a cross-domain authentication request containing a pseudo-identity, temporary parameters, timestamps, and rescue scenario identifiers, and send it to a trusted authoritative institution in their respective communication domains.

[0027] In step S130, after receiving the request, the trusted authoritative institutions of both parties first verify the timeliness of the timestamp, then query the status and legitimacy of the target node through the consortium blockchain. After the verification is successful, a cross-domain certificate is generated and digitally signed, and submitted to the consortium blockchain for verification by the PBFT consensus algorithm and then synchronized to the relevant nodes.

[0028] In step S140, the lightweight terminal node and the trusted authorities of both parties collaborate to derive a key component, and generate a session key through negotiation based on the difficulty of the Chebyshev problem. After the key verification is consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

[0029] This method is implemented in an emergency rescue system comprised of drone-assisted vehicle-to-everything (V2X) networks, which includes four core participants, each with clearly defined roles and functions, working together to achieve secure cross-domain communication. The first is the vehicle, which acts as a lightweight terminal node in the consortium blockchain. In other words, this serves as the terminal node in an emergency rescue scenario, equipped with a vehicle-mounted terminal, smart card, and C-V2X communication module. The smart card stores core keys and identity parameters, and performs operations such as encryption, hashing, and Chebyshev mapping. The vehicle-mounted terminal handles user interaction (entering passwords and initiating communication requests). The C-V2X module enables wireless communication with the TA (Technical Assistant) and drones, transmitting authentication messages and rescue data. Next is the drone, which acts as a relay node for rescue data transmission. It is equipped with an airborne control system, an encrypted storage module, and a C-V2X communication module. The airborne control system is responsible for generating keys and encapsulating messages, while the encrypted storage module is used to store core parameters and negotiation keys. It also communicates with the TA and vehicles through the C-V2X module, providing services such as data forwarding and rescue guidance.

[0030] In fact, both drones and vehicles serve as lightweight terminal nodes in the consortium blockchain. Drones also act as relay nodes for cross-domain communication, responsible for forwarding cross-domain authentication messages and rescue data, and completing on-chain data queries and on-chain evidence storage based on the permissions of lightweight terminal nodes.

[0031] Next is the local trusted authority (TA). , Each communication domain deploys one TA (Task Authority), which serves as the node management center and consensus node for the consortium blockchain within that domain. It is responsible for node registration, authentication, cross-domain credential issuance, and key component generation. It participates in the consortium blockchain consensus to ensure the immutability and synchronization of cross-domain data (such as credentials and revocation records).

[0032] Finally, a permissioned blockchain, i.e., a consortium blockchain, is deployed, consisting of consensus nodes from various communication domain TAs. and Two types of smart contracts are used to store immutable TA registration information, node registration records, cross-domain credentials, key hashes, and revocation records, enabling cross-domain trust transfer, data traceability, and auditing.

[0033] In this embodiment, the system adopts a hybrid architecture of intra-domain Trust Provider (TA) management and cross-domain blockchain consensus. The intra-domain TA is responsible for the full lifecycle management of nodes, including registration, password updates, and revocation applications, ensuring the security of intra-domain communication. The consortium blockchain is responsible for cross-domain trust endorsement, i.e., credential consensus and revocation synchronization, solving the trust deficiency problem in cross-domain scenarios. The two work together to ensure the security and efficiency of cross-domain communication.

[0034] This method proposes several algorithms, which will be introduced in advance before a detailed explanation of the method.

[0035] Chebyshev chaotic mapping: Chebyshev polynomials are a class of orthogonal polynomials that satisfy specific recursive relations, and their core properties are as follows: (1). Recursive relation: , , ( , (For large prime numbers), this property ensures the efficiency of polynomial operations and avoids complex calculations; (2). Properties of semigroups: That is, the composition operation of the Chebyshev map is equivalent to the multiplication operation of the parameters, which provides a mathematical basis for public key generation and key component derivation in key negotiation; (3). Security Basis: Based on the Diffie-Hellman Problem (CMDHP) using Chebyshev mapping, defined as a known , , It is difficult to compute in polynomial time. The difficulty of this problem ensures the security of key negotiation, preventing attackers from cracking the session key through intercepted public parameters.

[0036] Blockchain technology: This method adopts a consortium blockchain architecture, and its core features and components are as follows: (1) Consensus algorithm: The PBFT (Practical Byzantine Fault Tolerance) algorithm is selected. This algorithm can still guarantee system consistency in the presence of malicious nodes, and has low consensus latency (not exceeding 500ms), which is suitable for the real-time requirements of emergency rescue scenarios. (2) Smart Contracts: Deploy two types of contracts. Focusing on the storage and verification of cross-domain authentication-related data, It focuses on the notarization and auditing of key negotiation records; the contract is developed in Solidity language, and cannot be tampered with after deployment, ensuring data security; (3) Distributed storage: All data on the blockchain (such as certificates and revocation records) are stored synchronously by multiple consensus nodes. There is no single point of failure. The data is immutable and traceable, providing trust endorsement for cross-domain communication.

[0037] Hash function: Select a secure hash function. , , All of them satisfy the following characteristics: (1) Collision resistance: It is difficult to find two different inputs. , making ; (2). One-wayness: It is impossible to obtain the hash value from the hash value. Reverse the original input ; (3) Randomness: The hash values ​​are evenly distributed with no obvious pattern. , Output a 160-bit hash value to fit the parameter length of the Chebyshev mapping; Output a 256-bit hash value to generate a high-strength session key.

[0038] In this method, the core process includes four stages: system initialization, node registration, cross-domain authentication and third-party key negotiation, and node lifecycle management. The interaction logic, computational details, and message formats of each stage are clearly defined and standardized to ensure the feasibility and security of the solution. Steps S100 to S140 disclose the most crucial aspects of the initialization, node registration, cross-domain authentication, and third-party key negotiation stages. Step S100 details the technical features of the initialization stage, step S110 details the technical features of the node registration stage, and steps S120-S140 detail the specific technical features of the cross-domain authentication and third-party key negotiation stages. These steps will be elaborated upon in the following sections.

[0039] In step S100, the global parameters include large prime numbers, randomly selected Chebyshev mapping seeds, and three types of secure hash functions. The three types of hash functions are used to generate identity obfuscation and signature, key derivation, and session key, respectively. The global parameters are synchronized to ensure parameter consistency across all nodes through the genesis block of the consortium blockchain.

[0040] In this embodiment, during the system initialization phase, each domain's local trusted authority (TA) jointly negotiates and determines global parameters through an offline security meeting. These global parameters include large prime numbers. Chebyshev mapping seed (random selection) The preferred value range is ) and three secure hash functions , , ,in Used for identity obfuscation and signature generation. Used for key derivation. Global parameters are exposed to all nodes through the consortium blockchain's genesis block, ensuring parameter consistency.

[0041] Specifically, each local TA randomly selects a private key. (Private key length and) Consistent (160 bits), based on the Chebyshev mapping recursion relation ( ), calculate public key Identification (32-bit unique identifier), public key (160 bits) and the registration timestamp (Unix timestamp, accurate to the second) are encapsulated into a TA registration information structure, which is then passed through a cross-domain authentication smart contract. The link to the consortium blockchain is submitted to ensure cross-domain query reachability.

[0042] Furthermore, each TA node participates in the generation of the consortium blockchain's genesis block, with the consensus rule set as the PBFT algorithm (the number of consensus nodes is no less than 3, and the fault tolerance rate is...). The cross-domain authentication threshold is set to at least three TA signatures confirming critical operations (such as node revocation or cross-domain credential activation). Deployment With key verification smart contracts ,in The defined data structures include TA registration information, node registration records, cross-domain credentials, and revocation records. The interaction interfaces include a query interface (querying TA public keys and node identity information by ID), an uplink interface (submitting registration records and cross-domain credentials), and a verification interface (verifying signature validity). The defined data structure includes key negotiation records, and the interaction interface includes an uplink interface (for submitting key hashes) and a query interface (for auditing key negotiation history).

[0043] In step S110, during the registration process of the lightweight terminal node: the lightweight terminal node independently sets its initial login password through its own terminal, then generates a random number using its own encrypted storage module. The initial login password and this random number are then concatenated using a hash function to obtain a password derived value. The lightweight terminal node encapsulates its real identity identifier, hardware identifier, and password derived value into a registration request, which is sent to a trusted authority within its communication domain via offline verification or an AES-256 encrypted channel. Upon receiving the request, the relevant trusted authority performs dual verification. If the verification is successful, it generates core parameters including a private key, public key, and pseudo-identity. The registration record of the lightweight terminal node is then uploaded to the blockchain for filing via a cross-domain authentication smart contract. The core parameters are then sent to the corresponding lightweight terminal node via an AES-256 encrypted channel. The lightweight terminal node stores the core parameters in its own encryption module and sets exclusive access permissions, allowing only legitimate commands to read them.

[0044] In one embodiment, dual verification includes: a trusted authority first queries a local database to verify whether the node hardware identifier has been registered, and then calls the query interface of the cross-domain authentication smart contract to verify the uniqueness of the node's true identity identifier through the consortium blockchain's historical records.

[0045] Specifically, when a vehicle, acting as a lightweight terminal node, registers, the vehicle... Users can independently select their real identity identifier via the vehicle-mounted terminal. This real identity identifier A unique 64-bit identifier containing information such as vehicle model and serial number. Login password. The login password is defined by the user, i.e., the vehicle owner, and must be at least 8 characters long, containing uppercase and lowercase letters, numbers, and special symbols. The vehicle's smart card has a built-in encrypted storage module, which generates random numbers using its own encrypted storage module's random number generator. (160 bits). The smart card calls the hash function. computational cryptography derivation ,in" The "" symbol indicates a string concatenation operation to ensure the security of password storage.

[0046] Furthermore, vehicles undergo offline verification, such as visiting a TA service center or using an encrypted channel, which transmits data to the local TA using AES-256 encryption based on a pre-shared key. Send a registration request; the request message format is as follows: Vehicle hardware identifiers are used to assist in verifying the uniqueness of identity.

[0047] Furthermore, within the relevant communication domain Upon receiving the request, a two-factor authentication process is initiated: first, the local database is queried to verify whether the vehicle hardware identifier has been registered, and then... The query interface, input Query blockchain history and verify The uniqueness of the verification process is ensured. If a duplicate is detected at any stage, a registration refusal response is returned to the vehicle, including an explanation of the reason for the duplicate.

[0048] Furthermore, after verification, Select an integer using a secure random number generator. (160 bits) Based on the recursive relation of Chebyshev mappings and the properties of semigroups, calculate the vehicle's core parameters, including the vehicle's private key, public key, and pseudo-identity. The vehicle's private key is represented as: The private key is stored only on the vehicle's smart card and is not transmitted externally. The vehicle's public key is represented as: By utilizing the semigroup property to simplify computation and ensure the association between the public key and the TA's private key, the pseudo-identity is represented as: 160 bits, used for identity verification during cross-domain communication to prevent the leakage of real identity.

[0049] In this embodiment, the node's pseudo identity From real identity Local TA public key With Chebyshev mapping seed Through hash function Generate, the generation formula is To ensure that the pseudo-identity of the same node is unique in cross-domain scenarios, and that pseudo-identities of different nodes cannot be associated; local TA maintenance. and A one-to-one mapping table, stored only in the TA's local encrypted database, not on the blockchain; only authorized TAs can access it through the blockchain. Combined with authentication records and a local mapping table, the corresponding real identity is traced. This achieves conditional privacy protection, balancing privacy and accountability.

[0050] Furthermore, Will Encapsulated as vehicle registration records, and called. The on-chain interface is submitted to the consortium blockchain, and the on-chain process is completed after the consensus node confirms the submission.

[0051] then, A response message is returned to the vehicle via a secure channel, containing... The response message is encrypted using AES-256, with the key being the hash value of the vehicle's hardware identifier. After the vehicle receives the response, the smart card stores the core parameters through its built-in encrypted storage module. Set access permissions for the storage area, allowing only legitimate commands to read, and complete the registration process.

[0052] Specifically, when a drone, acting as a lightweight terminal node, registers, it... Select a real identity identifier through the airborne control system. This real identity identifier A unique 64-bit identifier containing information such as the drone model and serial number; a login password must also be set. The rules are the same as for the vehicle password, and will not be repeated here. The onboard storage module generates random numbers. (160 bits) Calculate the cryptographic derived value To the local TA ( Send registration request .

[0053] Furthermore, the communication domain to which the drone belongs Perform a dual verification process to verify The uniqueness of the drone's hardware identifier. After successful verification, a random number is generated. (160-bit) Calculate the drone's private key Public key False identity The process is similar to that of vehicles, and will not be described in detail here.

[0054] then, Will pass Uplink to the blockchain and return a response message to the drone. The drone will transmit the core parameters. The data is stored in the onboard encrypted storage module, and registration is complete.

[0055] In step S120, the lightweight terminal node vehicle and the drone submit cross-domain communication requests to the TA (Targeting Authority) of their respective communication domains, and the corresponding TA first performs identity authentication. The cross-domain authentication request is transmitted via the C-V2X public channel. The pseudo-identity in the request message is generated by hashing the node's real identity identifier, the public key of the local trusted authority, and the Chebyshev mapping seed. The local trusted authority only maintains a one-to-one mapping table between the pseudo-identity and the real identity identifier in its own encrypted database and does not store it on the blockchain.

[0056] In this embodiment, the timestamp uses a Unix second-level format, and all cross-domain interaction messages (in this document) are in the same format. to All of these include this field. Trusted authoritative institutions verify message freshness by calculating whether the difference between the current time and the message timestamp does not exceed a preset threshold. If the timeout occurs, the corresponding error code is returned and the message is rejected. The recipient calculates... ( This function determines message freshness and effectively defends against replay attacks. If a message times out, the receiver directly refuses to process it and returns a clear error code, facilitating rapid problem location by the node.

[0057] Specifically, vehicles Cross-domain communication needs are triggered by the vehicle-mounted terminal, such as initiating an emergency rescue data transmission request; the smart card generates a temporary random number. (160-bit), call the Chebyshev mapping operation module to calculate (160 bits). Get the current timestamp. Such as Unix timestamps, accurate to the second, encapsulating cross-domain authentication request messages. The rescue scenario identifier is used to indicate the communication purpose, such as "injured person location transmission" or "rescue command reception." It is then transmitted to the local unit via a C-V2X public channel. .

[0058] Furthermore, take over Next, the timestamp validity verification is performed first: the local clock module is called to obtain the current time. ,calculate ( (This is a preset timeout threshold). If the timeout occurs, a rejection response will be returned. After the timeliness verification is passed, Initiating the blockchain query process: First call The query interface, input , obtain public key Enter the status (whether it is operating normally). Then enter the preset target drone pseudo-identity. Obtain its public key Belonging TA identifier And registration status (whether it has been revoked). If the query results show... abnormal or If the license has been revoked, a rejection response will be returned. .

[0059] Furthermore, Comparison In , Vehicle registration records stored on the blockchain: calculation Verify whether it is consistent with Consistent. Verify. Check if it completely matches the record on the blockchain; if the verification passes, the vehicle's legitimacy within the domain is confirmed; otherwise, a rejection response is returned. .

[0060] Simultaneously, drones Temporary random numbers are generated by the airborne control system. (160 bits), calculation (160 bits), Get Timestamp Encapsulate the request message Send to local . Repeat the above The vehicle verification process, i.e., verification Timeliness, search public key With vehicles public key The system verifies the legality of the drone within the domain; if the verification is successful, it proceeds to the next stage; otherwise, it returns the corresponding rejection response.

[0061] In this embodiment, after each TA verifies the corresponding drone or vehicle, a cross-domain credential is generated and consensus is uploaded to the blockchain. The cross-domain credential is a structured data format containing a trusted authority's public key, a node pseudo-identity, temporary parameters, a rescue scenario identifier, a timestamp, and a digital signature. The consortium blockchain's PBFT consensus algorithm requires a preset number of trusted authority nodes to verify the signature's validity and field integrity, and the consensus delay must not exceed a preset time. Once the cross-domain credential is approved, it is synchronized to all consensus nodes.

[0062] Specifically, the vehicle corresponds to Generate temporary random numbers (160-bit), call the hash function calculate Based on their own private key Calculate digital signature: (160 bits). Next, Will , , , , , Rescue scene identifiers are encapsulated as cross-domain credentials. The voucher format uses structured data (such as JSON format) to ensure field integrity. Call The upper link port will Submit to the consortium blockchain.

[0063] Furthermore, the consortium blockchain triggers the PBFT consensus mechanism, with each consensus node (TA) verifying... The signature validity and field integrity are verified, and after consensus is reached, the data is written into a block and synchronized to [the relevant database]. And other consensus nodes.

[0064] then, To the vehicle Notification status for sending credential generation: This is used for subsequent vehicle verification.

[0065] Similarly, drones correspond to Generate temporary random numbers (160 bits), calculation And based on the private key Calculate signature Encapsulate cross-domain credentials .then, Will Upload to the blockchain and trigger consensus, then synchronize to To drones Send a notification to generate credentials, completing the cross-domain credential interaction.

[0066] In this embodiment, the key component derivation is implemented based on the semigroup property of Chebyshev mapping, including: the trusted authorities of both parties first calculate the cross-domain key component and digitally sign it based on their own private key and the temporary parameters submitted by the lightweight terminal node, and then send it to the corresponding lightweight terminal node through the C-V2X channel encrypted with AES-256. After the lightweight terminal node receives it, it first performs multi-level verification, verifying the legality of the trusted authority's public key, the validity of the key component signature, and the timeliness of the cross-domain certificate in sequence. After all verification steps are passed, three types of key components are generated based on Chebyshev mapping operation, including a trusted connection component with the local trusted authority, a cross-domain temporary component with the other party node, and its own local temporary key.

[0067] Specifically, take over Synchronous That is, the TA (Telematics Authority) of the vehicle receives the synchronized data from the TA (Telematics Authority) of the drone via the alliance link. Initiate the credential verification process. This process first calls... calculate ,in, for The inverse of the private key is calculated using the extended Euclidean algorithm, and then... Next, compare the results of the two steps to see if they are consistent, and verify them simultaneously. Timeliness If verification fails, the process terminates and sends a request to... Send a verification failure notification. If verification is successful... Based on the Chebyshev map semigroup property, calculate cross-domain key components. The cross-domain key component is 160 bits and is used to participate in third-party key derivation.

[0068] Furthermore, Call calculate Based on private key Computation key component signature The key component signature is 160 bits. Encapsulate messages Transmitted to the vehicle via a C-V2X encrypted channel (AES-256) .

[0069] Similarly, in take over Synchronous Then, perform the same verification process to verify. Validity and Timeliness. After successful verification, calculate the cross-domain key component. The cross-domain key component is 160 bits. Next, calculate Based on private key Calculate signature The key component signature is 160 bits. Finally... Encapsulate messages Send to the drone via an encrypted channel .

[0070] Furthermore, vehicles take over Then, initiate multi-layered verification: first verify... Legality requires verification with local storage. Consistency, then approval calculate Comparison with Whether they match. Final verification. The validity of the signature, its steps are the same as take over Synchronous Then, the credential verification process is consistent. If any of these three verification layers fails, a rejection response is returned. .

[0071] In this embodiment, if all three layers of verification pass, the vehicle smart card calls the Chebyshev mapping operation module to calculate three types of key components, including the key component with the local TA, the temporary key component with the drone, and the local temporary key.

[0072] Specifically, the key component of the local TA is represented as follows: (160 bits) used to confirm a trusted connection with the local TA. The temporary key component with the drone is represented as follows: (160-bit), security is ensured based on the CMDHP problem. The local temporary key is represented as: (256-bit) Integrates multiple types of parameters to improve key complexity.

[0073] Similarly, drones take over Then, the above multi-layered verification process is executed to verify... and The validity of the key is verified. After successful verification, the key component with the local TA, the temporary key component with the vehicle, and the local temporary key are calculated.

[0074] Specifically, the key component of the local TA is represented as follows: (160 bits). The temporary key component for the vehicle is represented as follows: (160 bits), and Equivalent. The local temporary key is represented as: (256 bits).

[0075] Furthermore, the vehicle towards Send key component derived confirmation message drones towards Send an acknowledgment message in the same format, and TA records the derived status.

[0076] In step S140, after the lightweight terminal node and the trusted authorities of both parties collaboratively derive the key component, a session key is also generated based on the difficulty of the Chebyshev problem. After the key verification is consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

[0077] Specifically, vehicles Generate current timestamp (Accurate to the second), call Calculate temporary session key candidates (256-bit), further calls Calculate key verification value (160-bit) Vehicle Encapsulated Message Transmitted to the drone via C-V2X encrypted channel .

[0078] Furthermore, drones take over Then, first verify Timeliness If the timeout occurs, a rejection response error code 1005 is returned, with the description: negotiation message timed out. Once the timeliness verification passes, the drone generates the current timestamp. ,calculate (256-bit), call Calculate key verification value (160 bits). Drone encapsulated message. Send to vehicle .

[0079] Furthermore, vehicle reception Afterwards, verification Timeliness If the timeout period expires, the negotiation will terminate; once the timeliness verification is passed, the vehicle will be dispatched. Calculate the final three-party session key (256-bit) Vehicle Recall calculate Comparison with received Check if they match; if they don't match, return a rejection response error code: 1006, description: Key verification failed. Similarly, the drone synchronously performs the same operation to calculate the final session key. ,verify Consistency, i.e., computation Comparison with Are they consistent?

[0080] Furthermore, after both parties have passed the verification, the vehicle and the drone respectively call... calculate (256 bits) will Encapsulated as a key negotiation record. Vehicles and drones call it separately. The upstream connection interface submits the key negotiation record to the consortium blockchain for subsequent auditing and traceability, and sends a key negotiation success notification to its respective TA. The TA updates its local node status to "negotiated key", completing the entire process of cross-domain authentication and key negotiation.

[0081] In this embodiment, the method also includes password updates, revocations, and restorations for lightweight terminal nodes. During password updates, the lightweight terminal node inputs the old password, which is verified as valid by its own encryption module. It then generates a new password and a new random number, calculates the new password derivation value, and sends an update request to a trusted authority within its communication domain. After verification by the trusted authority, the blockchain synchronously updates the corresponding password hash record. When a lightweight terminal node's revocation certificate is generated and uploaded to the blockchain by the trusted authority within its communication domain, it must undergo PBFT consensus verification to be effective across domains. If a valid revocation record is found during cross-domain authentication, communication is rejected. When a lightweight terminal node restores its legitimacy, the trusted authority within its communication domain generates a revocation certificate and uploads it to the blockchain for consensus. After successful verification, the node regains normal cross-domain communication permissions, and the consortium blockchain synchronously updates the node's status record.

[0082] Specifically, the password update is performed locally. (Vehicle) Insert the smart card and enter the old password through the vehicle terminal. Smart card calculation , with local storage The system compares and verifies the validity of the old password; if they do not match, the update is rejected, displaying the message "Old password incorrect." After successful verification, the vehicle enters the new password. (Saving the password complexity rules), the smart card generates a new random number. (160 bits) Calculate the new cryptographic derived value Next, the vehicle headed towards the local area. Send a password update request; the message contains... ,in Used for authentication.

[0083] Furthermore, verify With blockchain storage Consistency is achieved, and calculations are performed after passing the test. , call The update interface updates the corresponding password hash record on the blockchain. The system returns a successful update response to the vehicle, and the smart card update storage is complete. Complete password update.

[0084] In this embodiment, the password update process for the drone is exactly the same as that for the vehicle, and will not be described again.

[0085] In this embodiment, when a lightweight terminal node needs to be revoked, if the vehicle... If the smart card is lost, stolen, or the node engages in malicious activity, then the local... Generate a revocation certificate, represented as .then, Call The link above will submit the revocation certificate to the consortium blockchain.

[0086] Furthermore, the consortium blockchain initiates PBFT consensus, with each TA node verifying it. Once the validity and consensus are reached, the revocation certificate is written to the blockchain and synchronized to the TA nodes in all domains. Other nodes (such as drones)... Before initiating cross-domain authentication, call The query interface allows you to input the other party's information. Check if a valid revocation record exists (not expired, not revoked); if it has been revoked, refuse to initiate authentication and return a new value. .

[0087] Furthermore, if the node regains its legitimacy (e.g., by retrieving the smart card). Generate a revocation certificate and upload it to the blockchain. Once consensus is reached, the node will return to its normal state.

[0088] In this approach, the initialization phase lays the foundation for cross-domain communication, with the core tasks being the unification of global parameters, generation of TA keys, and deployment of the consortium blockchain. Each domain's TA negotiates global parameters through offline secure meetings, ensuring all nodes use a consistent computational foundation. Each TA generates a public-private key pair, with the public key uploaded to the blockchain for cross-domain queries. The deployment of the consortium blockchain and smart contracts clarifies the data storage structure and interaction interfaces, providing standardized support for cross-domain data sharing and verification, and avoiding interaction failures due to inconsistent interfaces.

[0089] Furthermore, during the node registration phase, vehicles and drones register through the Domain Transaction Agent (TA). The core of this process is generating a public-private key pair and a pseudo-identity to ensure both identity legitimacy and privacy protection. The registration process employs a dual-verification + encrypted storage mechanism: the TA verifies the uniqueness of the node's true identity to prevent duplicate registrations; the node password is generated using a hash function and random number derivation before storage to prevent password leakage; the true identity is stored only locally on the TA, while the blockchain stores only the pseudo-identity and non-sensitive information such as the public key, achieving a balance between privacy protection and verifiable identity.

[0090] Furthermore, the cross-domain authentication and third-party key negotiation phase is the core of the method, realizing cross-domain node identity authentication and secure key negotiation. It consists of four steps: identity request and query, cross-domain credential generation, key component derivation, and key negotiation and verification. This involves 36 interactive sub-steps between the vehicle, drone, and both parties' TAs. Each step includes a clearly defined message format, verification logic, and error handling mechanism, including: Identity request and query steps: defend against replay attacks by verifying the timeliness of timestamps, and confirm the legitimacy of the target node and TA by querying the blockchain to avoid communication with illegal nodes; Cross-domain credential generation steps: The TA generates a cross-domain credential based on the private key and uploads it to the blockchain for consensus, ensuring the credential's immutability and cross-domain trustworthiness, and providing a basis for subsequent identity authentication; Key component derivation steps: The three parties (vehicle, drone, and TA) generate key components respectively. The component generation relies on the semigroup property of Chebyshev mapping and the CMDHP problem to ensure component security; the component signing and verification mechanism ensures that the component has not been tampered with. Key negotiation and verification steps: Through temporary key exchange and cross-validation, ensure that both parties generate consistent session keys; key hashing is recorded on the blockchain to achieve traceability and facilitate subsequent auditing.

[0091] Finally, during the node lifecycle management phase, password updates and node revocation are supported to ensure the continuous and secure operation of the system. Password updates employ a mechanism of local verification and blockchain record updates, eliminating the need for cross-domain interaction and ensuring convenient and secure operation. Node revocation utilizes a mechanism initiated by a TA (Trustee Agent) and agreed upon by the consortium blockchain. Revocation records take effect across domains, preventing lost smart cards or malicious nodes from continuing to participate in communication and safeguarding the overall security of the system.

[0092] Security analysis of this method is conducted, and it is proven using the game sequence method that the semantic security of the session key is reduced to the intractability of the CMDHP problem. Assuming an attacker can crack the session key with a non-negligible advantage, an algorithm could be constructed to exploit this attacker's ability to solve the CMDHP problem. However, this contradicts the difficulty of the CMDHP problem; therefore, the attacker's advantage in cracking the key is negligible, and the scheme satisfies semantic security.

[0093] Furthermore, this method fully meets 14 core security requirements, including anonymity, traceability, two-way authentication, session key negotiation, no password verification table, password friendliness, timely spelling error detection, perfect forward security, resistance to smart card loss attacks, resistance to forgery attacks, resistance to man-in-the-middle attacks, resistance to temporary secret disclosure attacks, resistance to replay attacks, and resistance to password guessing attacks. It can effectively resist various common attacks in emergency rescue scenarios.

[0094] Furthermore, all cross-domain interaction messages include timestamp and signature fields. The recipient verifies the freshness and integrity of the messages through timestamp verification and signature verification. The error handling mechanism is clear, which facilitates nodes to quickly locate problems and avoids communication blockage caused by message anomalies.

[0095] Next, a performance analysis of this method is performed. Regarding computational overhead, the core operations of this method are Chebyshev mapping and hash operations, both lightweight operations, avoiding complex bilinear pairing or large number modular exponentiation operations. Specifically, in the node registration phase: vehicles / drones require only 2 Chebyshev mapping operations and 3 hash operations, while TAs require 2 Chebyshev mapping operations and 2 hash operations, with the total computation time for a single node registration not exceeding 5ms. In the cross-domain authentication and key negotiation phase: vehicles / drones each require 3 Chebyshev mapping operations and 5 hash operations, while TAs each require 2 Chebyshev mapping operations and 3 hash operations, with the total computation time for the entire process being approximately 35.17ms, far below the time threshold (1 second) for emergency rescue scenarios.

[0096] Regarding communication overhead, the total communication data packet size for a single cross-domain authentication and key negotiation using this method is approximately 364 bytes, including core fields such as pseudo-identity (160 bits), public key (160 bits), signature (160 bits), and timestamp (4 bytes). This results in low bandwidth consumption and compatibility with VANET's wireless communication environment. Furthermore, the consortium blockchain PBFT consensus latency is no more than 500ms, and the blockchain query time is no more than 100ms. The entire cross-domain authentication and key negotiation process (including 36 interactive sub-steps) can be completed within 1 second, meeting the real-time requirements of emergency rescue scenarios.

[0097] The aforementioned cross-domain authentication and key negotiation method for UAV-assisted vehicle networks, through the organic combination of blockchain and Chebyshev mapping, standardizes the cross-domain interaction process and solves the shortcomings of existing solutions in cross-domain authentication, privacy protection, and key security, with the following significant benefits: High security: The key negotiation mechanism is built based on the CMDHP problem. Combined with the immutability of blockchain, TA signature verification, and timestamp verification, it can effectively resist various attacks such as password guessing, replay, man-in-the-middle, forgery, and smart card loss. It meets 14 core security requirements and ensures the confidentiality, integrity, and availability of emergency rescue data transmission.

[0098] Strong cross-domain adaptability: Supports cross-domain communication across multiple TA jurisdictions without the need for offline negotiation between TAs; achieves cross-domain trust transfer and data synchronization through blockchain, and revocation records and cross-domain credentials take effect across domains, adapting to complex network environments in emergency rescue scenarios.

[0099] Interaction process standardization: Cross-domain authentication and key negotiation include 36 clearly defined interaction sub-steps. Each step has a standardized message format, verification logic and error handling mechanism to avoid communication failures caused by non-standard interaction and improve the feasibility of the solution.

[0100] Lightweight design: The core operation is Chebyshev mapping and hash operation, with low computational overhead; a single cross-domain communication data packet is only 364 bytes, with low bandwidth consumption; the consensus latency of the consortium blockchain is no more than 500ms, and the entire process takes about 1 second, which is suitable for the resource constraints of vehicles and drones and the real-time requirements of emergency rescue.

[0101] It has good scalability: It supports dynamic node registration, password update and revocation, and smart contracts can be upgraded to expand functions (such as adding rescue scenario identifiers and optimizing verification logic), making it suitable for various cross-domain communication scenarios such as emergency rescue, disaster site communication and cross-regional intelligent traffic scheduling.

[0102] This method can be widely applied to fields such as emergency rescue, disaster site communication, and cross-regional intelligent traffic scheduling using UAV-assisted VANETs, ​​providing reliable technical support for secure and efficient communication between cross-domain nodes, and has significant practical application value and promotion prospects.

[0103] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0104] In one embodiment, such as Figure 2 As shown, a cross-domain authentication and key negotiation system for drone-assisted vehicle networks is provided. The system comprises a drone-assisted vehicle network consisting of drones, vehicles, trusted authority institutions, and a consortium blockchain. The drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authority institution. All trusted authority institutions serve as consensus nodes of the consortium blockchain and are equipped with cross-domain authentication smart contracts and key verification smart contracts. The drones and vehicles serve as lightweight terminal nodes of the consortium blockchain. The system includes: Each of the aforementioned trusted authoritative institutions negotiates global parameters through an offline security meeting. These global parameters are made public to all nodes through the genesis block of the consortium blockchain. At the same time, they generate exclusive public and private key pairs, encapsulate their own identity identifier, public key, and registration timestamp into registration information, and register it on the blockchain through a cross-domain authentication smart contract. The lightweight terminal nodes complete registration through a trusted authority in their respective communication domains, submitting information including their real identity identifier and login password. After the trusted authority double-verifies the uniqueness of their identity, they obtain core parameters containing the false identity and public / private key pairs. These core parameters are stored in their own encryption module. When lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on Chebyshev mapping, encapsulate a cross-domain authentication request containing a pseudo-identity, temporary parameters, timestamp, and rescue scenario identifier, and send it to a trusted authoritative institution in their respective communication domain. After receiving the request, the trusted authoritative institutions of both parties first verify the timeliness of the timestamp, then query the status and legitimacy of the target node through the consortium blockchain. After the verification is successful, a cross-domain certificate is generated and digitally signed, and submitted to the consortium blockchain for verification by the PBFT consensus algorithm and then synchronized to the relevant nodes. The lightweight terminal node and the trusted authoritative institutions of both parties collaborate to derive key components, and generate session keys based on the difficulty of the Chebyshev problem. After the keys are verified to be consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

[0105] Specific limitations regarding the cross-domain authentication and key negotiation system for UAV-assisted vehicle networks can be found in the limitations on the cross-domain authentication and key negotiation methods for UAV-assisted vehicle networks mentioned above, and will not be repeated here. The UAVs, vehicles, trusted authoritative institutions, and consortium blockchains in the aforementioned cross-domain authentication and key negotiation system for UAV-assisted vehicle networks can be implemented entirely or partially through software, hardware, or a combination thereof. The functional modules of each component can be embedded in hardware or independent of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the corresponding operations of each module.

[0106] In one embodiment, a computer device is provided that can be integrated into or deployed independently of a drone, vehicle, or trusted authority, and its internal structure diagram is as follows: Figure 3 As shown, the computer device includes a processor, memory, network interface, encryption module, and communication module connected via a system bus. The processor provides core computing and control capabilities, coordinating the various modules to collaboratively perform cross-domain authentication and key negotiation operations. The encryption module is configured to perform secure operations such as Chebyshev mapping, hashing, AES-256 encryption / decryption, and digital signature verification to ensure data processing security. The communication module supports the C-V2X wireless communication protocol and the consortium blockchain node interaction protocol for encrypted data transmission with external nodes (such as other computer devices and consortium blockchain consensus nodes).

[0107] The computer device's memory includes non-volatile storage media and internal memory: the non-volatile storage media stores the operating system, computer programs, and encrypted core parameters (such as public-private key pairs, pseudo-identities, local identity mapping tables, etc.). Access control is set for the core parameter storage area, allowing only legitimate instructions to trigger reading; the internal memory provides a high-speed cache environment for the operation of the operating system and computer programs in the non-volatile storage media, ensuring the efficient execution of computation and communication processes.

[0108] The network interface of this computer device is used to communicate with external terminals and consortium blockchain nodes via an encrypted network connection, transmitting data such as cross-domain authentication requests, cross-domain credentials, and key components. When this computer program is executed by the processor, it implements the aforementioned lightweight cross-domain authentication and key negotiation method for UAV-assisted vehicle-to-everything (V2X) emergency rescue.

[0109] Those skilled in the art will understand that the structure shown in Figure 3 is merely a block diagram of a portion of the structure related to the solution of this application, and does not constitute a limitation on the computer equipment on which the solution of this application is applied. The specific computer equipment may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements, depending on the needs of the deployment scenario (drone, vehicle, TA). In one embodiment, a computer device is provided, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned lightweight cross-domain authentication and key negotiation method for UAV-assisted vehicle-to-everything (V2X) emergency rescue. The computer device is integrated with or associated with a UAV, a vehicle, or a trusted authority, wherein: When the computer device is integrated into the UAV, the processor is configured to execute the computational logic of the airborne control system, including temporary random number generation, Chebyshev mapping operation, key component derivation, session key negotiation and message encapsulation, and the memory is configured to encrypt and store the UAV's core parameters, session keys and key negotiation records. When the computer device is integrated into a vehicle, the processor is configured to perform collaborative operations between the vehicle terminal and the smart card, including cryptographic derivation, cross-domain authentication request generation, key verification value calculation, and on-chain request submission. The memory is configured to encrypt and store the vehicle's real identity identifier, pseudo-identity, public-private key pair, and cryptographic derivation value. When the computer device is associated with a trusted authority (TA), the processor is configured to perform global parameter negotiation, node dual authentication, cross-domain credential generation, PBFT consensus participation, and key component signature operations, and the memory is configured to store node registration information within the domain, local identity mapping table, and consortium blockchain smart contract interaction interface data.

[0110] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the aforementioned lightweight cross-domain authentication and key negotiation method for UAV-assisted vehicle-to-everything (V2X) emergency rescue. The computer-readable storage medium includes an encrypted storage module configured as follows: The system stores core sensitive data involved in the execution of the method, such as global parameters, public-private key pairs, pseudo-identities, and password derived values, and sets access control to allow only legitimate instructions to trigger reading or computation. Synchronously store traceable data such as cross-domain credentials, key negotiation records, and revocation credentials generated during the interaction of the consortium blockchain, ensuring data integrity and immutability, and adapting to subsequent auditing and security verification needs.

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

[0112] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A cross-domain authentication and key negotiation method for unmanned aerial vehicle (UAV) assisted vehicle networking, characterized in that, The method is implemented in a drone-assisted vehicle-to-everything (V2X) emergency rescue system composed of drones, vehicles, trusted authoritative institutions, and a consortium blockchain. The drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authoritative institution. All trusted authoritative institutions serve as consensus nodes of the consortium blockchain and are equipped with cross-domain authentication smart contracts and key verification smart contracts. The drones and vehicles serve as lightweight terminal nodes of the consortium blockchain. The method includes: Each of the aforementioned trusted authoritative institutions negotiates global parameters through an offline security meeting. These global parameters are made public to all nodes through the genesis block of the consortium blockchain. At the same time, they generate exclusive public and private key pairs, encapsulate their own identity identifier, public key, and registration timestamp into registration information, and register it on the blockchain through a cross-domain authentication smart contract. The lightweight terminal nodes complete registration through a trusted authority in their respective communication domains, submitting information including their real identity identifier and login password. After the trusted authority double-verifies the uniqueness of their identity, they obtain core parameters containing the false identity and public / private key pairs. These core parameters are stored in their own encryption module. When lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on Chebyshev mapping, encapsulate a cross-domain authentication request containing a pseudo-identity, temporary parameters, timestamp, and rescue scenario identifier, and send it to a trusted authoritative institution in their respective communication domain. After receiving the request, the trusted authoritative institutions of both parties first verify the timeliness of the timestamp, then query the status and legitimacy of the target node through the consortium blockchain. After the verification is successful, a cross-domain certificate is generated and digitally signed, and submitted to the consortium blockchain for verification by the PBFT consensus algorithm and then synchronized to the relevant nodes. The lightweight terminal node and the trusted authoritative institutions of both parties collaborate to derive key components, and generate session keys based on the difficulty of the Chebyshev problem. After the keys are verified to be consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

2. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 1, characterized in that, The global parameters include large prime numbers, randomly selected Chebyshev mapping seeds, and three types of secure hash functions. These three types of hash functions are used to generate identity obfuscation and signatures, key derivation, and session keys, respectively. The global parameters are synchronized and consistent across all nodes through the genesis block of the consortium blockchain.

3. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 1, characterized in that, During the lightweight terminal node registration process: The lightweight terminal node sets its own login password independently, and then generates a random number through its own encrypted storage module. The login password and the random number are then concatenated using a hash function to obtain a password derived value. The lightweight terminal node encapsulates the real identity identifier, hardware identifier, and the password derivation value into a registration request, and sends it to a trusted authoritative institution in its communication domain through offline verification or AES-256 encrypted channel; After receiving the request, the relevant trusted authority performs dual verification. Once the verification is successful, it generates core parameters including a private key, a public key, and a pseudo-identity. The registration record of the lightweight terminal node is then uploaded to the blockchain for filing through a cross-domain authentication smart contract. Finally, the core parameters are sent to the corresponding lightweight terminal node through an AES-256 encrypted channel. The lightweight terminal node stores the core parameters in its own encryption module and sets exclusive access permissions, allowing only legitimate commands to read them.

4. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 3, characterized in that, The dual verification includes: the trusted authority first queries the local database to verify whether the node hardware identifier has been registered, and then calls the query interface of the cross-domain authentication smart contract to verify the uniqueness of the node's true identity identifier through the consortium blockchain's historical records.

5. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 1, characterized in that, The cross-domain authentication request is transmitted through the C-V2X public channel. The pseudo-identity in the request message is generated by hashing the node's real identity identifier, the public key of the local trusted authority, and the Chebyshev mapping seed. The local trusted authority only maintains a one-to-one mapping table between the pseudo-identity and the real identity identifier in its own encrypted database and does not store it on the blockchain.

6. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 1, characterized in that, The timestamp uses a Unix second-level format, and all cross-domain interaction messages contain this field. Trusted authoritative institutions verify the freshness of messages by calculating whether the difference between the current time and the message timestamp does not exceed a preset threshold. If the timeout occurs, the corresponding error code is returned and the message is rejected.

7. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 3, characterized in that, The cross-domain credential is in a structured data format, containing the public key of the trusted authority, the pseudo-identity of the node, temporary parameters, rescue scenario identifier, timestamp, and digital signature; The PBFT consensus algorithm of the consortium blockchain requires a preset number of trusted authoritative nodes to verify the validity of the signature and the integrity of the fields, and the consensus delay does not exceed a preset time. After the cross-domain certificate is approved, it is synchronized to all consensus nodes.

8. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 1, characterized in that, The key component is derived based on the semigroup property of Chebyshev maps, including: Both trusted authorities first calculate the cross-domain key component and digitally sign it based on their own private keys and the temporary parameters submitted by the lightweight terminal node, and then send it to the corresponding lightweight terminal node through the AES-256 encrypted C-V2X channel; After receiving the data, the lightweight terminal node first performs multi-layer verification, sequentially verifying the legality of the public key of the trusted authority, the validity of the key component signature, and the timeliness of the cross-domain credential. After all verification steps are passed, it then generates three types of key components based on Chebyshev mapping operations, including a trusted connection component with the local trusted authority, a cross-domain temporary component with the other party node, and its own local temporary key.

9. The cross-domain authentication and key negotiation method for UAV-assisted vehicle networking according to claim 1, characterized in that, The method also includes password updates, revocations, and recovery for lightweight terminal nodes: When the password is updated, the lightweight terminal node inputs the old password, which is verified as valid by its own encryption module. Then, it generates a new password and a new random number, calculates the new password derivation value, and sends an update request to a trusted authority in its communication domain. After verification by the trusted authority, the blockchain synchronously updates the corresponding password hash record. After the lightweight terminal node revocation certificate is generated and uploaded to the blockchain by the trusted authority of its communication domain, it must be verified by PBFT consensus before it can be effective across domains. If a valid revocation record is found during cross-domain authentication, communication will be rejected. When a lightweight terminal node regains its legitimacy, the trusted authority in its communication domain generates a revocation certificate and uploads it to the blockchain for consensus. After verification, the node regains its normal cross-domain communication permissions, and the consortium blockchain updates the node's status record synchronously.

10. A cross-domain authentication and key negotiation system for unmanned aerial vehicle (UAV) assisted vehicle networking, characterized in that, The system comprises a drone-assisted vehicle network consisting of drones, vehicles, trusted authoritative institutions, and a consortium blockchain. The drones and vehicles belong to corresponding communication domains, and each communication domain deploys a trusted authoritative institution. All trusted authoritative institutions serve as consensus nodes of the consortium blockchain and are equipped with cross-domain authentication smart contracts and key verification smart contracts. The drones and vehicles act as lightweight terminal nodes of the consortium blockchain. The system includes: Each of the aforementioned trusted authoritative institutions negotiates global parameters through an offline security meeting. These global parameters are made public to all nodes through the genesis block of the consortium blockchain. At the same time, they generate exclusive public and private key pairs, encapsulate their own identity identifier, public key, and registration timestamp into registration information, and register it on the blockchain through a cross-domain authentication smart contract. The lightweight terminal nodes complete registration through a trusted authority in their respective communication domains, submitting information including their real identity identifier and login password. After the trusted authority double-verifies the uniqueness of their identity, they obtain core parameters containing the false identity and public / private key pairs. These core parameters are stored in their own encryption module. When lightweight terminal nodes belonging to different communication domains trigger cross-domain rescue communication requests, they each generate temporary random numbers and calculate temporary parameters based on Chebyshev mapping, encapsulate a cross-domain authentication request containing a pseudo-identity, temporary parameters, timestamp, and rescue scenario identifier, and send it to a trusted authoritative institution in their respective communication domain. After receiving the request, the trusted authoritative institutions of both parties first verify the timeliness of the timestamp, then query the status and legitimacy of the target node through the consortium blockchain. After the verification is successful, a cross-domain certificate is generated and digitally signed, and submitted to the consortium blockchain for verification by the PBFT consensus algorithm and then synchronized to the relevant nodes. The lightweight terminal node and the trusted authoritative institutions of both parties collaborate to derive key components, and generate session keys based on the difficulty of the Chebyshev problem. After the keys are verified to be consistent, the key negotiation record is stored on the blockchain through the key verification smart contract.

Images