An unmanned aerial vehicle-assisted vehicle cross-domain authentication method in a vehicle networking emergency communication scenario

Abstract

The application provides a UAV-assisted vehicle cross-domain authentication method in a vehicular networking emergency communication scene, and belongs to the technical field of vehicular networking security. The application solves the technical problems of poor stability, low efficiency, security and performance defects of vehicle identity authentication and key negotiation in an emergency scene. The technical scheme comprises the following steps: S1, system initialization; S2, UAV group deployment; S3, UAV dynamic group key generation; S4, vehicle identity pre-authentication; and S5, vehicle cross-domain authentication. The application designs a UAV-assisted vehicle cross-domain authentication method in a vehicular networking emergency communication scene, and realizes low cost, high security and stability of vehicle authentication.

Description

Technical Field

[0001] This invention relates to the field of vehicle network security technology, and in particular to a method for cross-domain authentication of vehicles assisted by unmanned aerial vehicles in vehicle network emergency communication scenarios. Background Technology

[0002] The Internet of Vehicles (IoV), centered on Vehicle-to-Everything (V2X) communication, improves traffic efficiency, ensures driving safety, and expands intelligent mobility services through multi-device collaborative interaction and data sharing. However, V2X communication carries sensitive data such as traffic perception, route planning, and vehicle control commands, and its transmission security directly impacts user rights and the stability of the traffic system. If subjected to identity forgery, data tampering, or eavesdropping attacks, it can easily lead to serious traffic accidents and privacy breaches. Therefore, V2X communication requires strict identity authentication and session key negotiation mechanisms to verify the legitimate identities of both communicating parties and provide confidentiality and integrity protection for subsequent data transmission. This is the core foundation for building a secure IoV system. Currently, IoV identity authentication largely relies on robust ground infrastructure. However, in emergency scenarios caused by natural disasters such as earthquakes and forest fires, ground communication infrastructure is prone to failure, making authentication and key negotiation difficult to conduct normally. Therefore, building an authentication and key negotiation mechanism that does not rely on ground infrastructure and is both efficient and secure has become a key issue in IoV emergency communication scenarios.

[0003] Extensive research has been conducted in academia to address the core requirements of vehicle-to-everything (V2X) identity authentication and key negotiation, with the core objective of strengthening system security and resisting malicious attacks and unauthorized access. For example, to address the failure of roadside units in extreme scenarios such as natural disasters, the paper "A practical and provably secure authentication and keyagreement scheme for UAV-assisted VANETs for emergency rescue" proposes a two-factor authentication and key negotiation (AKA) protocol integrating smart cards and passwords to ensure communication security during vehicle evacuation. However, this scheme suffers a significant decrease in security when the smart card is lost, and its availability is limited by vehicle battery consumption. To address the efficiency bottleneck in group communication scenarios, researchers have proposed a group authentication and key negotiation (GAKA) protocol, which allows multiple nodes to complete identity authentication and group key negotiation through a single interaction, effectively reducing communication and computational overhead. For example, the paper "A group key agreement protocol based on ECDH and shortsignature" constructs a GAKA scheme independent of local communication facilities based on CLC and the Chinese Remainder Theorem (CRT). It uses tethered drones to replace failed fog nodes to form a flexible three-dimensional coverage architecture. However, the frequent bilinear pairing operations significantly increase computational costs and result in low elasticity. Researchers have attempted to address this low elasticity issue by introducing a threshold secret sharing mechanism. The GAKA protocol, which incorporates the threshold secret sharing mechanism, splits the group key into multiple sub-secrets and distributes them to group members, achieving distributed key management and fault-tolerant authentication functions, further optimizing the security and reliability of group authentication. For instance, the paper "Cluster space key management scheme based on threshold secret sharing and bilinear pairing" embeds a secret sharing mechanism into low-density parity-check (LDPC) codes, enabling efficient computation of the group key by cluster head nodes. However, satellite nodes face significant key update overhead when accessing across domains.

[0004] To address the challenges of identity authentication and key negotiation in infrastructure-less scenarios, unmanned aerial vehicles (UAVs) have gradually emerged as an efficient supplement to ground-based edge infrastructure (such as ground-based service units) in recent years, leveraging their rapid deployment capabilities, high mobility, and reliable line-of-sight communication. In emergency scenarios such as extreme natural disasters and ground communication network failures, multiple UAVs can quickly establish temporary air-to-ground communication links through collaborative networking. These UAVs act as aerial relay nodes, providing crucial support for vehicles within the area, including emergency rescue command transmission, post-disaster communication restoration, and security information broadcasting, effectively filling the communication coverage gap after ground infrastructure failure. The paper "Secure and efficient authenticated keymanagement scheme for UAV-assisted infrastructure-less IoVs" introduces UAVs as mobile trusted entities to undertake identity authentication and key distribution tasks, ensuring secure communication in areas where infrastructure has failed. However, this scheme is highly dependent on the trustworthiness and availability of the UAVs; if a UAV goes offline or is attacked, the system faces the risk of a single point of failure.

[0005] In summary, while existing identity authentication and key negotiation schemes for connected vehicles have achieved breakthroughs in specific technical fields, they generally suffer from deficiencies in security, computational overhead, or scenario adaptability. Furthermore, the highly dynamic topology and low-latency requirements of connected vehicles pose even greater challenges to the efficiency and reliability of authentication schemes. Summary of the Invention

[0006] This invention provides a method for drone-assisted vehicle cross-domain authentication in vehicle-to-everything (V2X) emergency communication scenarios. Addressing the robustness and privacy protection issues of vehicle identity authentication and key negotiation in infrastructure-deficient environments within V2X emergency communication scenarios, this invention constructs a highly robust drone collaborative group authentication architecture and designs the GAKA protocol, which combines verifiability and accountability. This achieves drone-assisted vehicle cross-domain authentication, significantly reducing computational overhead while providing effective privacy protection for vehicles.

[0007] The inventive concept of this invention is as follows: Based on a thorough investigation of current cross-domain authentication schemes in the Internet of Vehicles (IoV) and an analysis of their shortcomings, this invention proposes a drone-assisted cross-domain vehicle authentication scheme for IoV emergency communication scenarios. The scheme constructs a highly robust drone collaborative group authentication architecture, effectively solving the drawbacks of traditional schemes. Since this invention utilizes underlying cryptographic technologies, to clearly explain the principles and steps of this invention, relevant cryptographic knowledge will be explained first:

[0008] 1. Chebyshev chaotic mapping:

[0009] Assumption and It is a real number. The Chebyshev polynomial is expressed as: The formula is (1.1), and the recursive relation is expressed as (1.2), where... :

[0010]

[0011]

[0012] Chebyshev polynomials in the interval The group has a semigroup property. This property is defined as a semigroup property of (1.3), where... and :

[0013]

[0014] 2. Secret sharing

[0015] Let THS and SES represent the threshold space and the secret space, respectively. , It is the total number of members, and This is the threshold used for secret recovery. The (t,n)-Shamir secret sharing includes the following algorithm:

[0016] (1) Share generation: Let The polynomial of degree is ,in The polynomial coefficients are And sharing secrets is , This represents the share of each member, where .

[0017] (2) Secret Recovery: Based on Lagrange Interpolation Polynomial and The secret share of each member, namely .but A polynomial of degree 1 can be expressed as Therefore, through calculation To restore shared secrets .

[0018] 3. Related security issues

[0019] (1) Chaotic Mapping Discrete Logarithm Problem (CMDLP)

[0020] For a given real number Polynomial-time attacker PPT adversary It is difficult to compute the secret integer. , making In other words, for any polynomial-time algorithm, the PPT opponent... The probability is defined as (1.4). It is negligible:

[0021]

[0022] (2) Chaotic mapping computation problem

[0023] Chebyshev polynomials exhibit properties related to chaos theory, for a given real number and two extended Chebyshev polynomials and If for any polynomial-time algorithm, the PPT opponent It is still difficult to obtain under the given conditions. Then the chaotic mapping computation Diffie-Hellman problem (CMCDHP) is called a difficult problem. More formally, for any PPT adversary... , The probability of (1.5) is negligible.

[0024]

[0025] For ease of understanding, the symbols and their meanings involved in this invention are first given in Table 1 below:

[0026] Table 1. Symbols and their meanings

[0027]

[0028] This invention is achieved through the following measures: a method for UAV-assisted cross-domain vehicle authentication in a vehicle-to-everything (V2X) emergency communication scenario, comprising the following steps:

[0029] S1, System initialization;

[0030] S2, drone swarm deployment;

[0031] S3, Dynamic Group Key Generation for Unmanned Aerial Vehicles;

[0032] S4. Vehicle identity pre-authentication;

[0033] S5, Vehicle Cross-Domain Authentication.

[0034] Further, step S1 includes:

[0035] S11. Trusted organization (TA) initializes system parameters;

[0036] S111, Trusted Organization (TA) based on security parameters Choose a large prime number And construct the extended Chebyshev polynomial. Then, TA selects a hash function. ;

[0037] S112, Trusted Institution (TA) selects random numbers As a system parameter, yes A finite field of order, Given a large prime number, select a random number. As a system private key According to the extended Chebyshev polynomial Public key of computing system ,in This is the system's private key;

[0038] S12. The trusted authority (TA) generates a key and an anonymous identifier for the vehicle.

[0039] S121. Trusted institution TA selects random numbers. The private key used as the emergency command and relay vehicle ECRV And calculate the public key of ECRV. Then, TA transmits the public and private key pair via a secure channel. Distributed to ECRV;

[0040] S122, Vehicles Before initiating registration, first select a random number. Anonymity in calculations And send a registration request to a trusted authority (TA);

[0041] S123. After receiving the registration request, the trusted authority (TA) calculates the vehicle... Another part of the anonymity and generate vehicles false identity ;

[0042] S124, Vehicles Select random number Calculate the secret value And through false identities Send a key request to a trusted authority (TA);

[0043] S125, Trusted Institution TA Receives Vehicle After receiving the request, first select a random number. And calculate parameters and verification parameters and Then the common parameters Return to vehicle ;

[0044] S126, Vehicles Received public parameters Then, calculate the verification parameters. and Then verify the equation. If the condition is not met, return failure; if the verification passes, the vehicle... The local secret value is then combined with the public parameters returned by the trusted authority (TA) to generate the vehicle. private key And calculate the vehicle public key Store public and private key pairs The proof of the verification's correctness is as follows:

[0045]

[0046] Further, step S2 includes:

[0047] S21, the Emergency Command and Relay Vehicle (ECRV), as a trusted third party, is responsible for registering and deploying the tethered unmanned aerial vehicle (TUAV). Specifically, the ECRV first selects a random number... As the private key of TUAV And calculate the public key of TUAV. Then, through a secure channel, the public-private key pair was... Distributed to TUAV;

[0048] S22 and tethered drone TUAV are registrations for other drones in this group. Specifically, tethered drone TUAV is a drone... Select random number As a drone The private key and its public key are calculated. Then, the public and private key pairs are transmitted through a secure channel. Assigned to drones ;

[0049] S23, tethered drone TUAV is a drone Assign a unique real identity identifier That is, the true identity of the drone, and calculate the drone's identity based on a hash function. Anonymous identifier ;

[0050] S24. The tethered UAV (TUAV) further initializes the group security parameters. Considering the dynamic changes in UAV group members, the subsequent group key will be dynamically generated through negotiation to adapt to the continuous changes in group size. Specifically, the TUAV first defines the initial group key. And set the initial version number. Next, TUAV calculates the initial version element corresponding to the initial version number. Subsequently, the tethered UAV (TUAV) initialized the dynamic accumulator, setting its initial value to... ,in These are system parameters;

[0051] S25, the tethered drone TUAV initializes the electronic fence parameters for each drone. Specifically, the TUAV initializes the parameters based on the drone's... The expected deployment location, mission requirements, and communication capabilities for drones Generate independent electronic fence parameter sets ,in, This indicates the horizontal coverage area of ​​a drone, used to describe its service boundary in the planar dimension; This indicates the permitted flight altitude range for drones, used to limit their airspace of operation in the vertical direction; This indicates the communication coverage radius of the UAV, which is used to define the effective area where the vehicle can establish wireless communication with the UAV;

[0052] Further, step S3 includes:

[0053] S31, the tethered unmanned aerial vehicle (TUAV) is based on a secret sharing mechanism in a limited domain. Construct a polynomial and calculate the secret share of the group members;

[0054] S311, tethered unmanned aerial vehicle (TUAV) in a limited domain Above, among which For a prime number, construct a number of order . Secret polynomial ,in For constant terms, Belongs to a finite field , `` is a random number, representing the threshold for a drone swarm, indicating the minimum number of drones required. Only the secret share of each member can restore the group key. prime numbers and satisfy ;

[0055] S312, tethered drone TUAV, through drone The hash value of the anonymous identifier As a secret polynomial The interpolated value is used to calculate the drone's value. secret share ;

[0056] S32. Group members use their private keys and verification parameters to verify the validity of the secret share;

[0057] S321, the tethered unmanned aerial vehicle TUAV is based on secret polynomials. For drones Secret share calculation verification parameters The secret share was then transferred. With verification parameters Send to drone ;

[0058] S322, drone Receive secret share and verification parameters Then, using its own private key Calculate the verification value And compare it with the received verification parameters. If the equation holds true, it means that the secret share is valid. If the share is valid and has not been tampered with, it will be accepted and stored; otherwise, it will be deemed an invalid share and rejected.

[0059] S33. When the group members are dynamically adjusted, the group size changes accordingly. The threshold needs to be dynamically adjusted according to the new group size. The group members work together to calculate the group key update based on random parameters and secret share.

[0060] S331, tethered unmanned aerial vehicle (TUAV) selected from the group. Each share, denoted as ,in This is the updated threshold;

[0061] S332, tethered drone TUAV selects random number Calculate the random parameters of group members This is used to update the threshold, and the random parameter is defined as follows:

[0062] ,

[0063] Among them, prime numbers and satisfy , where n represents the total number of drone swarm members, ensuring the randomness and unpredictability of the update process.

[0064] S333. When the system needs to calculate the group key according to the initial settings, the threshold value is: , One drone Collaborative computation of secret polynomials ,in For drones The secret share, For drones Anonymous identifier, These are the Lagrange interpolation coefficients. The constant term was obtained through collaborative calculation by group members. This allows the group key to be recovered. ;

[0065] S334. When the group size changes dynamically, the system needs to update the threshold. When the threshold value is... In this case, One drone Jointly update group key ,in It is a random parameter. , This represents the total number of drones.

[0066] The correctness derivation is as follows:

[0067] random parameters ,in , and It is a large prime modulus and satisfies .therefore:

[0068]

[0069] in yes The Lagrange coefficients, according to the Lagrange interpolation theorem, .

[0070] because Then it can be known From this, we can deduce Because of prime numbers and satisfy Then there is Therefore, the following can be deduced:

[0071]

[0072] Therefore, group key .

[0073] Further, step S4 includes:

[0074] S41. The vehicle sends a pre-authentication request.

[0075] S411, When the vehicle Driving into the drone When setting up an electronic fence, send a drone The process of sending an identity pre-authentication request is as follows: Vehicle First, select a random number. And calculate the Chebyshev value. Then generate vehicles Certification label Where H is the hash function, For vehicles A false identity For common parameters, For vehicles public key, Chebyshev value, For timestamps;

[0076] S412, Vehicles Constructing an identity pre-authentication request message ,in Send the timestamp to the drone. ;

[0077] S42. Emergency Command and Relay Vehicle (ECRV) verifies the vehicle's identity;

[0078] S421, drones Received identity pre-authentication request message Then, first check the equation. If the message is valid, it means it has not been tampered with. Then forward it to the Emergency Command and Relay Vehicle (ECRV); otherwise, reject it.

[0079] S422, Emergency Command and Relay Vehicle (ECRV) received Then, the public key reconstruction algorithm is used to reconstruct the vehicle. The identity is verified. The specific process is as follows: ECRV calculates the verification parameters. and and reconstruct the vehicle public key Verify the equation If the condition is met, then confirm the vehicle. The following is an analysis of the legitimacy of the identity and the correctness of the public key reconstruction:

[0080]

[0081] S423, Emergency Command and Relay Vehicle (ECRV) using private keys Vehicle issuance Proof of legality ,in For vehicles A false identity For vehicles public key, The time stamp is then used to return the proof to the tethered drone TUAV;

[0082] S43, TUAV certification for tethered unmanned aerial vehicles;

[0083] S431, the tethered drone TUAV utilizes ECRV's public key. For vehicles Proof of legality Verification is performed, and the formula is verified. ,in For vehicles public key, For vehicles A false identity This is a timestamp. If the equation holds true, it indicates that the vehicle... Verify the legitimacy of the identity; otherwise, refuse vehicle access. Identity request;

[0084] S432, Tethered Unmanned Aerial Vehicle (TUAV) updates accumulator value And based on the current group key version Calculate the corresponding version element , For group keys;

[0085] S433, tethered unmanned aerial vehicle (TUAV) computing vehicle Secret Value Subsequently, the tethered drone TUAV used the accumulated value. and secret value Generate vehicles Membership proof ;

[0086] S434, tethered drone TUAV (vehicle) Calculate authentication key and temporary kana and build vehicles Authentication certificate ,in, For version elements, For vehicles The secret value, For vehicles Membership certificate, This is the current timestamp. The tethered drone TUAV will then use the credentials... and temporary kana Stored in a local database;

[0087] S435 and tethered drone TUAV use GSK group key encryption for vehicle encryption. Authentication response message ,in It is the accumulated value of the accumulator. Version element The subsequent accumulated value, For drones The anonymous identifier was sent to the drone. ;

[0088] S436, drones Receive authentication response message Then, the authentication response message is decrypted using the group key GSK. Obtain vehicle Membership proof and secret value Then verify the vehicle Identity legitimacy: Calculation parameters Verify the equation The vehicle can be confirmed if the equation holds true. The analysis of the legitimacy of the identity and the correctness of the membership verification is as follows:

[0089]

[0090] S437, After verification, the drone Select random number Calculate the Chebyshev value and signature Then calculate with the vehicle Session key ,in The Chebyshev value is obtained using the session key. Encrypted vehicles Authentication certificate Then send the authentication response message Send to vehicle , For vehicles Authentication certificate, For vehicles Anonymity;

[0091] S438, to support vehicles When subsequently entering other drone electronic fences, the drone can quickly complete identity authentication. GSK uses a group key to encrypt vehicle authentication information. Broadcast to other drones ;

[0092] S439, drones Decrypting drones using group keys GSK encrypted broadcast Obtain vehicle kana and authentication key Then store it in the local cache;

[0093] S44. The vehicle and the drone complete the session key negotiation;

[0094] S441, Vehicles Receive authentication response message Subsequently, the UAV was verified based on the Chebyshev semigroup properties. Does the signature satisfy ,in For drones signature, The signature is a random number; the correctness analysis is as follows:

[0095]

[0096] S442. After verification, the vehicle Computing and Drones Session key Subsequently, the vehicle use Decrypting the ciphertext Obtain certification Thus, to obtain the vehicle Secret Value Membership certificate Authentication key and temporary kana And save it in the local cache. At this point, the vehicle... The identity pre-authentication process has been completed.

[0097] Further, step S5 includes:

[0098] S51, Vehicles Use authentication key Cryptographic Membership Proof and secret value Obtain the ciphertext ,in For timestamps;

[0099] S52, Vehicles Select random number Calculate the Chebyshev value and message verification code To drones Send cross-domain authentication request message ,in For timestamps;

[0100] S53, drones Upon receiving a cross-domain authentication request, based on the pseudonym Query locally stored vehicles The authentication information, and the authentication key. Decrypting the ciphertext ,in For version elements. Obtain the vehicle. Membership proof and secret value Then the drone Vehicle inspection Identity legitimacy: Calculation parameters Verify the equation Does the equation hold true? If the equation holds true, then the vehicle is confirmed. identity;

[0101] S54, drones Use authentication key Validate cross-origin authentication request The validity of the equation is determined by the following criteria: If the equation is true, the message is considered valid; otherwise, it is rejected.

[0102] S55, drones Select random number And calculate the Chebyshev value. ,in For the Chebyshev value, calculate the relationship with the vehicle. Session key and response messages verification code Then send the response message Send to vehicle ;

[0103] S56, Vehicles Receive response message Then, through the authentication key Verification message verification code And calculate the session key At this point, the vehicle... The cross-domain authentication process has been completed. The proof of the correctness of session key consistency is as follows:

[0104]

[0105] Meanwhile, the present invention proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed, it implements the steps of the method described in the present invention.

[0106] Furthermore, the present invention proposes a computer-readable storage medium having a computer program stored thereon, the computer program being configured to implement the steps of the method described in the present invention when invoked by a processor.

[0107] Finally, the present invention provides a computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described in the present invention.

[0108] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0109] (1) Compared with traditional cross-domain authentication schemes, this invention supports pre-authentication of the vehicle's identity and rapid cross-domain authentication after the vehicle enters the drone's electronic fence, ensuring the establishment of a reliable and secure communication channel in emergency scenarios without infrastructure.

[0110] (2) In the emergency scenario of vehicle networking, the present invention constructs a drone collaborative group authentication architecture. This architecture relies on the aerial drone group to build a temporary air-to-ground communication link, and replaces the traditional centralized infrastructure with a decentralized collaboration mode to ensure the high availability and robustness of communication between vehicles and groups in emergency scenarios, and realizes flexible and secure networking in an environment without infrastructure.

[0111] (3) Based on the Real-Or-Random (ROR) model, this invention provides formal security proof and combines informal security analysis to prove that the proposed method can significantly improve security strength compared with existing methods while maintaining computational efficiency. It can effectively resist typical attacks such as impersonation, replay and public key replacement, and supports threshold adaptive adjustment and group key update. Attached Figure Description

[0112] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0113] Figure 1 The present invention provides an overall flowchart of a method for cross-domain authentication of vehicles assisted by unmanned aerial vehicles in a vehicle-to-everything (V2X) emergency communication scenario.

[0114] Figure 2 This is a diagram of the vehicle networking system architecture in this invention.

[0115] Figure 3 A comparison chart of total computational overhead provided by this invention.

[0116] Figure 4 A comparison diagram of communication overhead during the identity authentication and key negotiation stages provided by this invention.

[0117] Figure 5 A comparison chart of total communication overhead provided by the present invention. Detailed Implementation

[0118] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. Of course, the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0119] Example 1: This Example 1 provides a method for UAV-assisted cross-domain vehicle authentication in a vehicle-to-everything (V2X) emergency communication scenario, such as... Figure 1 As shown, it includes the following steps:

[0120] S1, System initialization;

[0121] S2, drone swarm deployment;

[0122] S3, Dynamic Group Key Generation for Unmanned Aerial Vehicles;

[0123] S4. Vehicle identity pre-authentication;

[0124] S5, Vehicle Cross-Domain Authentication.

[0125] like Figure 2 As shown, the vehicle-to-everything (V2X) architecture of the unmanned aerial vehicle (UAV) assisted vehicle cross-domain authentication method includes: the trusted authority (TA), emergency command and relay vehicle (ECRV), the tethered UAV (TUAV), unmanned aerial vehicle (UAV), and on-board unit (OBU).

[0126] (1) Trusted Authority (TA): As the highest authority in the system, it is responsible for system parameter initialization, vehicle registration, and accountability assurance. In emergency scenarios, the TA maintains communication with the emergency command and relay vehicle (ECRV) via a secure satellite relay channel. Assume that the TA has sufficient computing and storage capabilities to efficiently store and back up massive amounts of vehicle and UAV data for subsequent analysis.

[0127] (2) Emergency Command and Relay Vehicle (ECRV): A mobile command platform deployed in emergency scenarios, which combines edge control and relay functions, provides continuous power supply and command and dispatch for TUAV, and maintains a secure communication link with TA. In an environment without infrastructure, it is responsible for TUAV registration and message relay.

[0128] (3) Tethered Unmanned Aerial Vehicle (TUAV): As a special type of multi-rotor UAV, it obtains a continuous power supply through a physical connection with the ECRV via a flexible rope or cable, thereby possessing the ability to hover for an extended period of time and operate with high reliability. As the manager of the UAV swarm, the TUAV is responsible for the deployment of the UAV swarm, generation of anonymous identities, initialization of electronic fence parameters, and allocation of quotas and dynamic adjustment of thresholds.

[0129] (4) Unmanned Aerial Vehicles (UAVs): As mobile aerial nodes in the system, UAVs are responsible for vehicle authentication and key negotiation within their electronic fence areas. They have the ability to be deployed and operate collaboratively. Although resources are limited, they can still efficiently complete secure communication operations under the scheduling of UAVs.

[0130] (5) On-board unit (OBU): A key device installed on the vehicle, equipped with V2X communication capability, mainly used to realize communication and information interaction between the vehicle and the outside world, and has limited computing and storage capabilities.

[0131] 1. Security Model

[0132] The security of this protocol is based on the following assumptions: the Trusted Entity (TA) is a completely trusted third party; the registration process for both vehicles and drone nodes is executed in a secure and controlled environment; the cryptographic primitives on which the protocol relies satisfy the preset security properties and are robust; the protocol execution phase excludes physical attacks and side-channel attacks; and the security analysis focuses on external active attackers in open communication channels.

[0133] Under the Random Response (ROR) model, this paper defines the adversary as a probabilistic multinomial-time adaptive attacker, whose attack capabilities are characterized as follows: It can control the open communication channels of the vehicle network, and perform eavesdropping, interception, tampering, forgery, and deletion operations on all messages transmitted in the channel; it can adaptively initiate specified key queries within multinomial time; constrained by the above security assumptions, the adversary cannot break the complete trustworthiness of the TA, nor can it destroy the core security characteristics of cryptographic primitives such as collision resistance and unforgeability; and all its attack behaviors and query decisions can be dynamically adjusted based on previously obtained channel messages, query results, and other attack information.

[0134] The security model of this scheme is defined by the game process between the challenger and the adversary. If the probability of the adversary winning the game is negligible, it can be proven that the CtVs session key is indistinguishable.

[0135] 1. Instance definition: Let... Indicates an instance, and Do not refer to vehicle instances and UAV instances.

[0136] 2. To characterize the adversary's capabilities, the adversary is allowed to initiate the following types of queries against protocol participants:

[0137] 1) Simulate the opponent Its proactive attack capability. Can be instance A message request is sent, and Challenger C returns the corresponding response according to the protocol rules.

[0138] 2) Simulate the opponent Get Instance The ability to negotiate a group session key; if the instance has not yet completed negotiation, return [the value / value]. .

[0139] 3) Simulate the opponent This undermines the user's ability. If challenger C uses... identity Executing the query will return... The private key.

[0140] 4) This function simulates an adversary's passive attack capabilities, such as eavesdropping on communication channels. The query returns all messages exchanged between protocol instances.

[0141] 5) Used to define the semantic security of the session key. This query is executed once, but can be executed at any time. The output is represented as random bits. Only when At that time, C will attack the enemy. Returns the instance's actual session key; otherwise, returns a random string of the same length as the session key. The adversary's goal is to correctly guess the bits. This distinguishes the real session key from the random string.

[0142] 3. Acceptance Status: Once the instance... Once the expected message is received, the system will enter the accept state.

[0143] 4. Fresh: If the instance An instance is considered fresh if it meets the following conditions:

[0144] (1) Example Enter the accept state;

[0145] (2) During the game, the participants were not subject to Corrupt queries;

[0146] (3) During the game, example It was not queried by Revaeal, meaning its session key was not obtained by an adversary;

[0147] 5. Definition Indicates the opponent For a fresh instance Initiate a test query and correctly guess the bit. The event. The advantage that an adversary has in breaking the semantic security of the protocol is defined as follows:

[0148]

[0149] like If the session key is negligible under any polynomial-time adversary, then the protocol satisfies the semantic security of the session key.

[0150] 2. Security Requirements

[0151] In the context of vehicle-to-everything (V2X) emergency scenarios, drone-assisted cross-domain authentication for vehicles without infrastructure faces complex scenarios involving highly dynamic nodes, open wireless channels, and multi-entity interactions. The cross-domain authentication scheme must meet multiple security requirements, including anonymity, non-forgeability, group key updates, robustness, accountability, threshold updates, share verifiability, and defense against various traditional attacks.

[0152] Anonymity: The protocol protects the true identity of vehicles and UAVs through anonymous identifiers. For vehicles, given... and ,in , The attacker cannot calculate This boils down to the CMDLP hard problem, making it impossible to calculate the vehicle's identity. Similarly, the anonymization of unmanned aerial vehicles (UAVs) is also problematic. In the case of an unknown private key Under these conditions, attackers cannot obtain the true identity of the UAV. This achieves identity anonymity protection.

[0153] Unforgeability: UAV to vehicle Send authentication response message The signature The enemy is unaware In cases where a valid signature cannot be forged, and therefore a message cannot be forged, this can be reduced to the CMDLP problem.

[0154] Group key update: To adapt to dynamic network topologies, CtVs supports group key updates when UAVs join / leave.

[0155] Robustness: A secret sharing mechanism is introduced to ensure that even if some UAVs go offline or disconnect, the remaining ones... The group key can still be reconstructed using a single UVA. .

[0156] Accountability: When a UAV releases a fake rescue message, the TUAV calculates and broadcasts the UAV's true identity based on the UAV's anonymity and its own private key, thus enabling identity accountability.

[0157] Threshold update: CtVs uses random parameters The threshold is achieved through a single round of interaction. arrive Update.

[0158] Share Verifiability: UAV verifiability parameters Using its own private key, it calculates a verification value and verifies the authenticity of the share based on the semigroup property of Chebyshev mapping polynomials, thereby resisting deceptive attacks.

[0159] 3. Security Analysis

[0160] Formal security analysis:

[0161] Based on the definition of the security model, this section demonstrates the security of the proposed solution through a game between challenger C and attacker.

[0162] Theorem: Let This indicates that an adversary can break semantic security (i.e., session key security) within polynomial time. The adversary's advantage in breaking semantic security in CtVs satisfies:

[0163]

[0164] in , and They represent the opposing side respectively. The number of hash, Send, and Execute queries. If If this can be ignored, it proves that CtVs satisfy session key security.

[0165] Proof: Session key security of CtVs through hybrid games To build, these games gradually simulate The attack process against the protocol. In each game In the middle, the event Indicates the opponent Successfully guessed random bits while executing the Test query. The incident.

[0166] Game 1: Game 1 completely simulates the execution of the real protocol under the ROR model, i.e., the adversary. Real-world interaction with the protocol. In this game, All queries can be executed according to the protocol specifications. The probability of success in this game is equivalent to... The probability of successfully attacking the real protocol. Therefore, The advantages can be expressed as:

[0167] (1)

[0168] Game 2: Game 2 simulates the opponent's eavesdropping capabilities. Challenger C maintains a list. When received Initiate a query At that time, Challenger C was Check if a corresponding value exists; if so, the challenger selects a random number. ,in The challenger setup afterwards Send h to the enemy Otherwise, the challenger retrieves the corresponding value and sends it to... Game 2 and Game 1 have the same advantages, therefore the game... and right Therefore, it is impossible to distinguish them. Thus, we can conclude:

[0169] (2)

[0170] Game 3: This game simulates an enemy's proactive attack, which is achieved through... The query was initiated, but it will terminate in the following two situations:

[0171] 1. Challenger C's response to the hash query resulted in a collision;

[0172] 2. A message exchange conflict occurs, i.e., a random number collision. and The repetition occurred.

[0173] According to the Birthday Paradox, the maximum probability of finding a hash collision is... Random numbers and Since both are simulated and follow a uniform distribution, the probability of a collision during message exchange is at most 1 / 3. Therefore, we can conclude that:

[0174] (3)

[0175] Game 4: The query simulation method in Game 4 is the same as in Game 3. Opponent Known and According to CMDLP, The probability of calculating the private key is:

[0176] (4)

[0177] Game 5: In Game 5, the opponent Attempt to guess the session key without consulting the corresponding random oracle. The premise is to obtain And the private key, therefore the probability that an adversary obtains the session key is

[0178] (5)

[0179] After the above mixed game, the probability that the opponent correctly guesses the output bit is: ,therefore

[0180] (6)

[0181] According to formulas (1), (2), and (6), it can be known that

[0182] (7)

[0183] According to formulas (3)-(5), we can know

[0184] (8)

[0185] According to formulas (7) and (8), we know that:

[0186] (9)

[0187] As derived from the above hybrid game, the advantage of an arbitrary probability multinomial-time (PPT) adversary under the ROR model in violating protocol semantic security is negligible. Therefore, the session key in this proposal satisfies semantic security under the ROR model; specifically, a PPT adversary cannot effectively distinguish between the real session key and the random key, i.e., it satisfies indistinguishability.

[0188] Example 2

[0189] To verify the performance of this invention, Example 2 compares and analyzes it with three representative existing vehicle-to-everything (V2X) identity authentication and key negotiation schemes, including Scheme 1 proposed by Wei et al. in "A lightweight and conditional privacy-preserving authenticated key agreement scheme with multi-TA model forfog-based VANETs," Scheme 2 proposed by Tan et al. in "Secure and efficient authenticated key management scheme for UAV-assisted infrastructure-less IoVs," Scheme 3 proposed by Zhang et al. in "TAGKA: threshold authenticated group key agreement protocol against member disconnect for UANET," and Scheme 4 proposed by Wang et al. in "An Accountable GAKA Protocol With Changeable Thresholds and Verifiable Shares in UAVs-Assisted IoVs for Emergency Rescue." Since the above schemes and this method are highly consistent in terms of application background and security objectives for identity authentication and key negotiation, they are highly comparable.

[0190] 1. Performance Analysis

[0191] (1) Calculation cost analysis

[0192] To compare the computational overhead of the proposed solution with existing solutions, the execution time of various operations in the proposed solution was first evaluated experimentally. The experiment was conducted on a LAPTOP-T64DTIKN computer, configured with an Intel(R) Core(TM) i5-1135G7 processor (2.40 GHz, 2419 MHz), 16 GB of memory, and a Windows 11 operating system. Cryptographic operations were simulated using Python's Charm library and cryptography library, employing elliptic curve cryptography. The hash function used is SHA-256. To reduce the error of a single measurement, each encryption operation was executed independently 1000 times. The final experimental results are expressed as the arithmetic mean. The symbolic representation and execution time of each operation are shown in Table 2 below.

[0193] Table 2. Various operations and their execution times

[0194]

[0195] In this embodiment, the proposed solution involves a single Chebyshev polynomial operation performed by the TA during the vehicle registration phase. Generate an ECRV public key and execute it twice for ordinary vehicles. Operations and 2 hash operations Generate partially anonymous parameters and key parameters; ordinary vehicles pass through twice. AND 3 The operation generates a public-private key pair. Therefore, the computational cost of the registration phase is 5. +5 .

[0196] The GAKA phase is divided into identity pre-authentication and cross-domain authentication: the identity pre-authentication phase is executed 8 times. 7 times 7 times and 1 time Cross-domain authentication is performed twice. 2 times 1 time and 1 time Therefore, the computational cost of the GAKA stage is + The key update phase adjusts the threshold using random parameters and completes the key update based on Lagrange interpolation. The computational cost of this phase is (3n+4). +n( + )+(2n+3) +(n+4) .

[0197] The computational costs of each scheme are compared in Table 3.

[0198] Table 3 Comparison of computational costs

[0199]

[0200] Scheme 1 performs only one hash operation on the identity identifier, thus having the lowest computational cost during the registration phase. Scheme 3 effectively reduces the computational cost during the registration phase by pre-calculating the secret share. Scheme 4 requires generating long-term and short-term keys for emergency vehicles, resulting in a relatively high computational cost during the registration phase. In contrast, this embodiment uses a lightweight registration process based on Chebyshev mapping, with a computational cost of 1.32ms, which is 94.4% lower than the 23.77ms registration cost of Scheme 4. A comparison of the total computational cost of this embodiment with other comparative schemes is as follows: Figure 3As shown, by Figure 3 It can be seen that although Scheme 1 has the lowest total overhead due to its use of extremely lightweight hash operations, its functionality is limited by its lack of support for dynamic key updates. Scheme 3, due to its heavy reliance on elliptic curve scalar multiplication and Lagrange interpolation, results in a quadratic increase in total overhead, bearing the heaviest burden under large-scale groups. Schemes 2 and 4, while supporting advanced security attributes, suffer from a high linear increase in total overhead due to frequent bilinear pairing and MapToPoint operations. In contrast, this embodiment uses Chebyshev polynomials and hash functions as core primitives, combined with an efficient dynamic group key management mechanism, to keep the total computational overhead linearly increasing and at a low level. Compared with other schemes, this embodiment demonstrates a better overall performance balance in terms of security, functional integrity, and system robustness, and is particularly suitable for resource-constrained UAV-assisted vehicle-to-everything (V2X) emergency communication scenarios.

[0201] (2) Communication overhead analysis

[0202] A comparative analysis of the communication overhead generated by schemes 1-4 during the identity authentication and key negotiation process is conducted, including the definition of the size of the identity. timestamp , elements on Addition Cyclic Group elements on Multiplication Cyclic Group elements on Addition Cyclic Group elements on Addition Cyclic Group elements on ciphertext Message authentication code Hash function and signature Chebyshev .

[0203] In Scheme 1, during the registration phase, the vehicle and the drone send a registration request to the TA carrying the real identity identifier (RID) and the pseudo identity identifier (PID). The communication overhead is... + +2 The GAKA phase is coordinated by fog nodes to complete group authentication: each member broadcasts a message carrying a hash value (H), an anonymity identifier, and a timestamp (T), and then completes authentication and key negotiation through multiple rounds of interaction. The communication overhead for this phase is 2(n+2). +(2n+7) +(n+4) +2 .

[0204] In Scheme 2, during the registration phase, vehicles and UAVs only need to preload system parameters and a portion of the private key, requiring no additional communication; therefore, the communication overhead during registration is 0 bytes. In the GAKA phase, the TUAV coordinates group authentication. Each member first broadcasts a message containing the public key parameters and a timestamp T, followed by the TUAV broadcasting the aggregate signature and verification commitment response. The communication overhead for the GAKA phase is (4n+7). + +(n+2) +(n+1) +3n During the key update phase, when membership changes (taking a new member joining as an example), TUAV broadcasts the new key share, and the remaining legitimate members decrypt the updated group key using the previously published key. The communication overhead for this phase is... + +(n+1)(4 + + ).

[0205] In Scheme 3, during the registration phase, the UAV joins the group via pre-shared parameters, incurring no additional communication overhead. During the GAKA phase, each member broadcasts their key contribution, including (n+1) ciphertexts C and secret shares, (2n+1) miscellaneous messages M and timestamp T, and 3(n+1) hashes H for verification. Therefore, the communication overhead for the GAKA phase is (n+1)(|C|+|Z|)+(2n+1)(|M|+|T|)+3(n+1)|H|. During the key update phase, the group administrator broadcasts an update to (n+2) members, including ciphertexts C and M, timestamp T, and hash H for verification. Therefore, the communication overhead for the key update phase is (n+2)(|C|+|M|)+(3n+4)|Z|+(2n+3)|T|+3(n+2)|H|.

[0206] In Option 4, during the registration phase, the UAV sends a registration request message to the group administrator, in which... The group administrator returns a verification message to the UAV. Therefore, the communication overhead during the registration phase is 3. +6 + During the GAKA phase, the group administrator sends an authentication message to the UAV, which contains identity information; therefore, the communication overhead is... During the key update phase, taking UAV joining as an example, the group administrator sends a key to the group. If a UAV broadcasts an update message, its communication overhead is (n+1)(2). + + ).

[0207] In this embodiment, during the registration phase, initialization and anonymization processing are performed on both the UAV and the vehicle. Before deployment, the TUAV sends a message to the UAV via a secure channel. and assign real identity identifiers. Public-private key pairs and anonymous identifiers Therefore, the communication overhead for UAV registration is byte.

[0208] Regular vehicle registration involves four-wheel interaction: the vehicle first generates a random number. And calculate partial anonymity. Send a registration request to them; they return their completely anonymous identity. Then, the vehicle sends a partial private key request. Ultimately, TA returns the public parameters and some private key-related values. Its communication overhead is Bytes. Therefore, the communication overhead during the registration phase in this embodiment is... + + + =220 bytes.

[0209] During the GAKA phase, the vehicle sends an authentication request message to the drone. It includes its own identity information, public key, and public parameters, with a communication overhead of Byte. After TUAV verifies the vehicle's identity, it sends a message to the drone. Send vehicle Authentication response message Then send the authentication response message Send to vehicle The communication overhead in this step is To achieve rapid identity verification, drones Encrypted vehicle authentication information Broadcasting to other drones incurs a communication overhead of n. Therefore, the total communication overhead in the GAKA phase is .

[0210] Taking the UAV joining scenario as an example, during the key update phase, the TUAV broadcasts a group key update message to all UAVs, with a communication overhead of (n+1)( + ).

[0211] As can be seen from the above analysis, there are significant differences in the number of communication overhead events in different schemes. Table 4 compares and calculates the communication overhead of this embodiment with that of schemes 1-4. The comparison data is shown in Table 4.

[0212] Table 4 Comparison of Communication Overhead

[0213]

[0214] The communication cost of the GAKA stage in this embodiment is compared with other comparative schemes, for example... Figure 4 As shown in the figure, the communication overhead of Scheme 1 is slightly lower than that of this embodiment, but its purely lightweight design has security weaknesses in resisting attacks such as public key replacement and tampering. This embodiment introduces a public key reconstruction algorithm, which provides higher security while maintaining low communication overhead. Compared with Schemes 2, 3, and 4, the communication efficiency is better, and the advantage becomes more significant as the group size increases. Taking a group size of 20 as an example, the communication overhead of this embodiment is reduced by 76.3%, 49.7%, and 46.1% compared with Schemes 2, 3, and 4, respectively, demonstrating its comprehensive advantages in security enhancement and scalability.

[0215] Total communication cost as Figure 5 As shown, Scheme 1 has the lowest total overhead but limited functionality; Scheme 2 has the highest overhead due to multiple rounds of interaction and share redistribution; Schemes 3 and 4 are at an intermediate level, but have relatively high constant overhead. This embodiment benefits from the use of a single-round lightweight mechanism in both the GAKA and key update phases, resulting in the smoothest growth curve of total overhead and significantly better overall communication efficiency than the comparative schemes. Therefore, this embodiment provides advanced security attributes such as variable thresholds, verifiable shares, and accountability while effectively controlling communication overhead and exhibiting good scalability with a continuous decrease in relative overhead as the group size increases. This feature makes it particularly suitable for highly dynamic, large-scale UAV-assisted, infrastructure-free vehicle-to-everything (V2X) emergency communication scenarios.

[0216] 2. Security and Functional Analysis

[0217] A comparative analysis of the safety and functionality of the proposed solution and solutions 1-4 was conducted. "√" indicates that the solution possesses the corresponding attribute, while "×" indicates that the solution cannot meet the safety requirement or has not considered it. As shown in Table 5 below, this embodiment has significant advantages over the comparative solutions in terms of both safety and functionality.

[0218] Table 5. Security and Functional Analysis

[0219]

[0220] As shown in Table 5, Schemes 1 and 2 do not consider the functional requirement of threshold variability; Scheme 3 does not analyze the accountability and security requirements; and Scheme 4 does not optimize performance. Compared to other schemes, this scheme, while meeting basic security requirements such as anonymity, non-forgeability, accountability, and forward / backward security, also possesses functions such as key update, threshold variability, and share verifiability, ensuring more comprehensive security and functional requirements. In summary, this embodiment is superior to existing schemes in terms of security and functionality, and can meet the high security and high flexibility requirements of the vehicle-to-everything (V2X) environment.

[0221] Example 3: This example proposes an electronic system, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method steps of the present invention.

[0222] Example 4: This example proposes a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the method described in this invention, which will not be repeated here.

[0223] Example 5: This example proposes a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, they implement the steps of the method described in this invention, which will not be repeated here.

[0224] It should be noted that the processing flow of embodiments 2-5 corresponds to the specific steps of the method provided in embodiment 1 of the present invention, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the method provided in embodiment 1 of the present invention.

[0225] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0226] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for cross-domain authentication of vehicles assisted by unmanned aerial vehicles (UAVs) in a vehicle-to-everything (V2X) emergency communication scenario, characterized in that, Includes the following steps: S1, System initialization; S2, drone swarm deployment; S3, Dynamic Group Key Generation for Unmanned Aerial Vehicles; S4. Vehicle identity pre-authentication; S5, Vehicle Cross-Domain Authentication.

2. The method for unmanned aerial vehicle (UAV)-assisted cross-domain authentication of vehicles in a vehicle-to-everything (V2X) emergency communication scenario according to claim 1, characterized in that, S1 includes the following steps: S11. Trusted organization (TA) initializes system parameters; S12. The trusted authority (TA) generates a key and an anonymous identifier for the vehicle. In step S11, the trusted organization (TA) initializes system parameters, including the following steps: S111, Trusted Organization (TA) based on security parameters Choose a large prime number And construct the extended Chebyshev polynomial. The trusted authority (TA) selects a hash function. ; S112, Trusted Institution (TA) selects random numbers As system parameters, among which yes A finite field of order, Given a large prime number, select a random number. As a system private key According to the extended Chebyshev polynomial Public key of computing system ,in This is the system's private key; In step S12, the trusted organization TA generates a key and an anonymous identifier for the vehicle. This process includes the following steps: S121. Trusted institution TA selects random numbers. The private key for the emergency command and relay vehicle ECRV And calculate the public key of ECRV. Trusted institution (TA) transmits public and private key pairs through a secure channel. Distributed to ECRV; S122, Vehicles Before initiating registration, first select a random number. Anonymity in calculations And send a registration request to a trusted authority (TA); S123. After receiving the registration request, the trusted authority (TA) calculates the vehicle... Another part of the anonymity and generate vehicles false identity ; S124, Vehicles Select random number And calculate the secret value. And through false identities Send a key request to a trusted authority (TA); S125, Trusted Institution TA Receives Vehicle After receiving the request, first select a random number. And calculate parameters and verification parameters and Then the common parameters Return to vehicle ; S126, Vehicles Received public parameters Then, calculate the verification parameters. and Verify the equation If the condition is not met, return failure; if the verification passes, the vehicle... The local secret value is then combined with the public parameters returned by the trusted authority (TA) to generate the vehicle. private key And calculate the vehicle public key Store public and private key pairs .

3. The method for unmanned aerial vehicle (UAV)-assisted cross-domain authentication of vehicles in a vehicle-to-everything (V2X) emergency communication scenario according to claim 1, characterized in that, S2 includes the following steps: S21. The Emergency Command and Relay Vehicle (ECRV), acting as a trusted third party, is responsible for registering and deploying the tethered unmanned aerial vehicle (TUAV). Specifically, the ECRV first selects a random number... As the private key of TUAV And calculate the public key of TUAV. Then, through a secure channel, the public-private key pair was... Distributed to TUAV; S22, Tethered Drone TUAV, is a registration for other drones in this group; specifically, Tethered Drone TUAV is a drone... Select random number As a drone The private key and its public key are calculated. Then, the public and private key pairs are transmitted through a secure channel. Assigned to drones ; S23, tethered drone TUAV is a drone Assign a unique real identity identifier That is, the true identity of the drone, and calculate the drone's identity based on a hash function. Anonymous identifier ; S24. The tethered UAV (TUAV) further performs the initialization of group security parameters. The TUAV first defines the initial group key. And set the initial version number. TUAV calculates the initial version element corresponding to the initial version number. Subsequently, the tethered UAV (TUAV) initialized the dynamic accumulator, setting its initial value to... ,in These are system parameters; S25, the tethered drone TUAV initializes the electronic fence parameters for each drone. TUAV then adjusts the parameters based on the drone's... The expected deployment location, mission requirements, and communication capabilities for drones Generate independent electronic fence parameter sets ,in, This indicates the horizontal coverage area of ​​a drone, used to describe its service boundary in the planar dimension; This indicates the permitted flight altitude range for drones, used to limit their airspace of operation in the vertical direction; This indicates the communication coverage radius of the UAV, which is used to define the effective area for establishing wireless communication between the vehicle and the UAV.

4. The method for unmanned aerial vehicle (UAV)-assisted cross-domain authentication of vehicles in a vehicle-to-everything (V2X) emergency communication scenario according to claim 1, characterized in that, S3 includes the following steps: S31, the tethered unmanned aerial vehicle (TUAV) is based on a secret sharing mechanism in a limited domain. Construct a polynomial and calculate the secret share of the group members; S32. Group members use their private keys and verification parameters to verify the validity of the secret share; S33. When the group members are dynamically adjusted, the group size changes accordingly. The threshold is dynamically adjusted according to the new group size. The group members work together to calculate the group key update based on random parameters and secret shares. In step S31, the tethered unmanned aerial vehicle (TUAV) utilizes a secret sharing mechanism within a limited domain. Construct a polynomial and calculate the secret share of each group member: S311, tethered unmanned aerial vehicle (TUAV) in a limited domain Above, among which For a prime number, construct a number of order . Secret polynomial ,in For constant terms , Belongs to a finite field , `` is a random number, representing the threshold for a drone swarm, indicating the minimum number of drones required. Only the secret share of each member can restore the group key. prime numbers and satisfy ; S312, tethered drone TUAV, through drone The hash value of the anonymous identifier As a secret polynomial The interpolated value is used to calculate the drone's value. secret share ; In step S32, group members use their private keys and verification parameters to verify the validity of their shares: S321, the tethered unmanned aerial vehicle TUAV is based on secret polynomials. For drones Secret share calculation verification parameters , secret share With verification parameters Send to drone ; S322, drone Receive secret share and verification parameters Then, using its own private key Calculate the verification value And compare it with the received verification parameters. If the equation holds true, it means that the secret share is valid. If the share is valid and has not been tampered with, it will be accepted and stored; otherwise, it will be deemed an invalid share and rejected. In step S33, when the group members are dynamically adjusted, the group size changes accordingly. The threshold needs to be dynamically adjusted based on the new group size. Group members collaboratively calculate the group key update based on random parameters and secret shares. S331, tethered unmanned aerial vehicle (TUAV) selected from the group. Each share, denoted as ,in This is the updated threshold; S332, tethered drone TUAV selects random number Calculate the random parameters of group members This is used to update the threshold, and the random parameter is defined as follows: ， ； Among them, prime numbers and satisfy , Indicates the total number of members in the drone swarm; S333. When the system calculates the group key according to the initial settings, the threshold value is: , One drone Collaborative computation of secret polynomials ,in For drones The secret share, For drones Anonymous identifier, The constant term is obtained by collaborative calculation of the Lagrange interpolation coefficients by group members. Restore group key ; S334. When the group size changes dynamically, the system updates the threshold, and the threshold value is... In this case, One drone Jointly update group key ,in It is a random parameter. , This represents the total number of drones.

5. The method for unmanned aerial vehicle (UAV)-assisted cross-domain authentication of vehicles in a vehicle-to-everything (V2X) emergency communication scenario according to claim 1, characterized in that, S4 includes the following steps: S41. The vehicle sends a pre-authentication request. S42. Emergency Command and Relay Vehicle (ECRV) verifies the vehicle's identity; S43, TUAV certification for tethered unmanned aerial vehicles; S44. The vehicle and the drone complete the session key negotiation; In step S41, the vehicle sends an identity pre-authentication request: S411, When the vehicle Driving into the drone When setting up an electronic fence, send a drone The process of sending an identity pre-authentication request is as follows: Vehicle First, select a random number. And calculate the Chebyshev value. Then generate vehicles Certification label Where H is the hash function, For vehicles A false identity For common parameters, For vehicles public key, Chebyshev value, For timestamps; S412, Vehicles Constructing an identity pre-authentication request message ,in Send the timestamp to the drone. ; In step S42, the Emergency Command and Relay Vehicle (ECRV) verifies the vehicle's identity: S421, drones Received identity pre-authentication request message Then, first check the equation. If the message is valid, it means it has not been tampered with and should be forwarded to the Emergency Command and Relay Vehicle (ECRV); otherwise, it should be rejected. S422, Emergency Command and Relay Vehicle (ECRV) received Then, the public key reconstruction algorithm is used to reconstruct the vehicle. The identity is verified, and the specific process is as follows: ECRV calculates verification parameters. and and reconstruct the vehicle public key Verify the equation If the condition is met, then confirm the vehicle. The legitimacy of one's identity; S423, Emergency Command and Relay Vehicle (ECRV) using private keys Vehicle issuance Proof of legality ,in For vehicles A false identity For vehicles public key, The time stamp is then used to return the proof to the tethered drone TUAV; In step S43, the tethered drone (TUAV) issues a vehicle certification certificate: S431, the tethered drone TUAV utilizes ECRV's public key. For vehicles Proof of legality Verification is performed, and the formula is verified. ,in For vehicles public key, For vehicles A false identity This is a timestamp; if the equation holds true, it indicates that the vehicle... Verify the legitimacy of the identity; otherwise, refuse vehicle access. Identity request; S432, Tethered Unmanned Aerial Vehicle (TUAV) updates accumulator value And based on the current group key version Calculate the corresponding version element , For group keys; S433, tethered unmanned aerial vehicle (TUAV) computing vehicle Secret Value Subsequently, the tethered drone TUAV used the accumulated value. and secret value Generate vehicles Membership proof ; S434, tethered drone TUAV (vehicle) Calculate authentication key and temporary kana and build vehicles Authentication certificate ,in, For version elements, For vehicles The secret value, For vehicles Membership certificate, The tethered drone TUAV will use the current timestamp as a certificate. and temporary kana Stored in a local database; S435 and tethered drone TUAV use GSK group key encryption for vehicle encryption. Authentication response message ,in It is the accumulated value of the accumulator. Version element The subsequent accumulated value, For drones The anonymous identifier was sent to the drone. ; S436, drones Receive authentication response message Then, the authentication response message is decrypted using the group key GSK. Obtain vehicle Membership proof and secret value Then verify the vehicle Identity legitimacy: Calculation parameters Verify the equation The vehicle can be confirmed if the equation holds true. The legitimacy of one's identity; S437, After verification, the drone Select random number Calculate the Chebyshev value and signature Then calculate with the vehicle Session key ,in The Chebyshev value is obtained using the session key. Encrypted vehicles Authentication certificate Then send the authentication response message Send to vehicle , For vehicles Authentication certificate, For vehicles Anonymity; S438, to support vehicles When subsequently entering other drone electronic fences, the drone can quickly complete identity authentication. GSK uses a group key to encrypt vehicle authentication information. Broadcast to other drones ; S439, drones Decrypting drones using group keys GSK encrypted broadcast Obtain vehicle kana and authentication key Then store it in the local cache; In step S44, the vehicle and the drone complete the session key negotiation: S441, Vehicles Receive authentication response message Subsequently, the UAV was verified based on the Chebyshev semigroup properties. Does the signature satisfy ,in For drones signature, It is a random number; S442. After verification, the vehicle Computing and Drones Session key ,vehicle use Decrypting the ciphertext Obtain certification Thus, to obtain the vehicle Secret Value Membership certificate Authentication key and temporary kana And save it in the local cache, vehicle The identity pre-authentication process has been completed.

6. The method for unmanned aerial vehicle (UAV)-assisted cross-domain authentication of vehicles in a vehicle-to-everything (V2X) emergency communication scenario according to claim 1, characterized in that, S5 includes the following steps: S51, Vehicles Use authentication key Cryptographic Membership Proof and secret value Obtain the ciphertext ,in For timestamps; S52, Vehicles Select random number Calculate the Chebyshev value and message verification code To drones Send cross-domain authentication request message ,in For timestamps; S53, drones Upon receiving a cross-domain authentication request, based on the pseudonym Query locally stored vehicles The authentication information, and the authentication key. Decrypting the ciphertext ,in For version elements, obtain the vehicle Membership proof and secret value drones Vehicle inspection Identity legitimacy: Calculation parameters Verify the equation If the equation holds true, then the vehicle is confirmed. identity; S54, drones Use authentication key Validate cross-origin authentication request The validity of the equation is determined by the following criteria: If the equation is true, the message is considered valid; otherwise, it is rejected. S55, drones Select random number And calculate the Chebyshev value. ,in For the Chebyshev value, calculate the relationship with the vehicle. Session key and response messages verification code Then send the response message Send to vehicle ; S56, Vehicles Receive response message Then, through the authentication key Verification message verification code And calculate the session key ,vehicle The cross-domain authentication process has been completed.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed, it implements the steps of the method as described in any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is configured to implement the steps of the method according to any one of claims 1 to 6 when invoked by a processor.

9. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

Images