A key management method, medium and device for unmanned aerial vehicles

Abstract

The present application relates to the technical field of key management, and particularly relates to a key management method for unmanned aerial vehicles, a medium and equipment, a symmetric session key uniquely associated with a flight session identifier is cooperatively generated by no less than a first preset number threshold of symmetric key generation nodes, which breaks away from single node dependence, and realizes precise matching of the key and the flight session life cycle; the key state and the flight session state are synchronized by continuously maintaining the key effective state and real-time detecting the triggering condition of the revocation condition during the flight session operation, and the security risks caused by the key being valid when the session is abnormal are avoided; after the revocation condition is triggered, the key is marked as invalid when the recommended revocation node number reaches a second preset number threshold, which avoids abnormal revocation of the key caused by single node misoperation or malicious behavior, disperses the node load, solves the performance bottleneck of centralized key management, and improves the processing efficiency and scalability.

Description

Technical Field

[0001] This invention relates to the field of key management technology, and in particular to a key management method, medium and device for unmanned aerial vehicles (UAVs). Background Technology

[0002] With the rapid development of the low-altitude economy, unmanned aerial vehicles (UAVs) have been widely used in urban inspection, logistics transportation, emergency rescue, environmental monitoring and other fields. The raw flight dynamic data generated during the flight of UAVs contains sensitive information such as position, speed and flight trajectory. The security of its transmission and management is directly related to the airspace operation order and public safety.

[0003] To ensure the security of flight dynamic data transmission, existing technologies commonly employ key management methods to encrypt and protect UAV flight dynamic data. The mainstream key management methods are mainly divided into two categories: centralized key management and simplified distributed key management. Centralized key management involves a single core node managing the generation, distribution, and revocation of UAV flight session keys. This method is simple to implement in scenarios with a small number of UAVs and low flight mission concurrency. However, when facing large-scale UAV dynamic operation scenarios, a single node struggles to handle the key generation requests from numerous flight sessions, easily creating performance bottlenecks in computation and concurrent processing. Furthermore, if the core node fails or is attacked, it can directly paralyze the entire UAV key management system, posing a serious single point of failure risk. Simultaneously, centrally generated keys are difficult to deeply bind to specific UAV flight sessions, and the key lifecycle is disconnected from the flight mission status. Revocation operations rely on manual or single-node commands, resulting in extremely low response efficiency. While simplified distributed key management introduces multiple nodes to participate in key generation, it lacks standardized constraints on node revocation judgment behavior, leading to chaotic key revocation decisions and prone to erroneous or untimely key revocation, failing to achieve refined and reliable control over UAV flight session keys.

[0004] Furthermore, some key management methods in the existing technology do not effectively combine the encryption of flight dynamic data with identity signature verification. They only use a single key to complete data encryption, which cannot verify the legitimacy of the UAV terminal. This makes it easy for data forgery and illegal terminals to impersonate and report, further reducing the security of flight dynamic data transmission.

[0005] Therefore, how to achieve distributed collaborative key generation that is deeply integrated with UAV flight sessions, complete key standardization and highly reliable collaborative revocation, and improve the security, reliability and adaptability of key management in large-scale UAV scenarios has become an urgent problem to be solved. Summary of the Invention

[0006] To address the aforementioned technical problems, the present invention provides a key management method for unmanned aerial vehicles (UAVs), which includes the following steps:

[0007] S1, when the UAV triggers a flight session establishment request, no less than a first preset threshold of symmetric key generation nodes collaboratively generate a symmetric session key that is uniquely associated with the identification information of the flight session, wherein the identification information includes at least the flight mission identifier and the flight start timestamp.

[0008] S2, the drone terminal uses the received symmetric session key and the corresponding drone manufacturer's private key to encrypt and sign the original flight dynamic data corresponding to the flight session, obtaining the data ciphertext and digital signature.

[0009] S3, the security verification node uses the received symmetric session key and the corresponding drone manufacturer's public key to decrypt and verify the received encrypted data and digital signature to obtain the plaintext flight dynamic data.

[0010] S4 maintains the symmetric session key in a valid state during normal flight session operation and detects in real time whether the preset revocation condition is triggered.

[0011] S5, when the preset revocation condition is triggered, each symmetric key generation node outputs the revocation judgment result, where the revocation judgment result is either recommended to revoke or not recommended to revoke.

[0012] S6. If the number of symmetric key generation nodes that are recommended for revocation is not less than the second preset number threshold, then the symmetric session key is marked as invalid.

[0013] The present invention also provides a non-transitory computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described key management method for unmanned aerial vehicles.

[0014] The present invention also provides an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0015] This invention has at least the following beneficial effects: By having at least a first preset threshold of symmetric key generation nodes collaboratively generate a symmetric session key uniquely associated with the flight session identifier information, the generation process of the symmetric session key is freed from dependence on a single node, avoiding the key generation failure problem caused by a single point of failure. Simultaneously, binding the key with the flight mission identifier and flight start timestamp achieves precise matching of the key lifecycle with the UAV flight session, eliminating the risk of key misuse across sessions from the source. Furthermore, by continuously maintaining the symmetric key in a valid state during normal flight session operation and detecting preset revocation conditions in real time, the key state can be synchronized with the operational state of the flight session, achieving dynamic and real-time monitoring of key validity. This system effectively manages and controls the key, preventing security risks caused by the key remaining valid even when the flight session is abnormal. By triggering preset revocation conditions, the symmetric key generation nodes output revocation judgment results, and the number of nodes suggesting revocation is no less than a second preset threshold before the symmetric session key is marked as invalid. This requires multi-node collaborative confirmation for key revocation decisions, avoiding abnormal key revocation caused by misoperation or malicious behavior of a single node. Simultaneously, it distributes the computational and decision-making load of the entire key management system to multiple symmetric key generation nodes, solving the performance bottleneck problem of centralized key management in high-concurrency scenarios of large-scale UAVs. This improves the processing efficiency and scalability of the key management method, enabling it to adapt to the dynamic operational needs of large-scale UAVs. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of a key management method for unmanned aerial vehicles (UAVs) provided in Embodiment 1 of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It is understood that, where appropriate, the terms used to distinguish similar objects can be interchanged so that the invention can also be implemented in other embodiments besides the illustrated or described embodiments. Furthermore, the terms "including," "having," and any variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0020] Example 1

[0021] This first embodiment provides a key management method for unmanned aerial vehicles (UAVs), such as... Figure 1 As shown, this key management method for drones includes the following steps:

[0022] S1, when the UAV triggers a flight session establishment request, no less than a first preset threshold of symmetric key generation nodes collaboratively generate a symmetric session key that is uniquely associated with the identification information of the flight session, wherein the identification information includes at least the flight mission identifier and the flight start timestamp.

[0023] The flight session establishment request refers to the instruction sent by the UAV to the key management system before / at takeoff to request the establishment of a dedicated key management link for this flight. This includes core information such as the UAV device identifier and flight session identification information. The flight session identification information is a unique identifier for this UAV flight session, and at least includes the flight mission identifier and flight start timestamp. It can be expanded by the implementer according to actual needs, such as including the flight airspace identifier, and is the foundation for uniquely binding the key to the flight session.

[0024] The flight mission identifier is a unique code assigned to this drone flight mission, used to distinguish different flight missions, such as inspection missions and logistics missions. It is generated immediately by the key management system upon receiving the flight session establishment request. The flight start timestamp is the precise time when the drone triggered the flight session establishment request, such as a millisecond-level timestamp. It is unique and used to prevent the same drone and the same mission from generating the same key for flight sessions initiated at different times.

[0025] The symmetric key generation node is a dedicated computing node / hardware / software combination unit with cryptographic computing capabilities and distributed collaborative capabilities, built for the UAV key management system. It is the core execution carrier for realizing the collaborative generation of symmetric key thresholds for UAV flight sessions, the maintenance of key status throughout its entire lifecycle, and the consensus judgment of key revocation thresholds. Only after the node is initialized, registered, and assigned a unique identifier by the system can it participate in key-related operations for a specified flight session.

[0026] The first preset quantity threshold t is the minimum number of nodes pre-configured by the key management system to participate in the collaborative generation of symmetric session keys. Only when the number of symmetric key generation nodes participating in the collaboration is greater than or equal to the first preset quantity threshold can a unique symmetric session key be generated based on the symmetric encryption algorithm and uniquely bound to this flight session. This key serves as the unique key for subsequent encryption of flight dynamic data by the UAV terminal and decryption of data ciphertext by the security verification node, and is configured to be valid only within this flight session.

[0027] As described above, by having at least a first preset threshold of symmetric key generation nodes collaboratively generate symmetric session keys, key generation is freed from dependence on a single node, avoiding the single point of failure risk of centralized key management. At the same time, the computational load of key generation is distributed to multiple nodes, effectively solving the performance bottleneck problem in high-concurrency scenarios of large-scale UAVs and improving the efficiency and reliability of key generation. By generating symmetric session keys that are uniquely associated with the identification information of the flight session, the symmetric session keys are deeply bound to the current flight mission and flight start time, achieving precise matching of the key lifecycle with the flight session. This eliminates the risk of key abuse across sessions and tasks, and leakage of long-term valid keys from the source, improving the uniqueness and anti-cracking resistance of key management.

[0028] In one specific implementation, prior to S1, the key management method for UAVs also performs system initialization, including the following steps:

[0029] A unique public and private key is generated for each drone manufacturer.

[0030] Write the private key to the corresponding drone terminal and synchronize the public key to the corresponding security verification node.

[0031] Each symmetric key generation node is registered and assigned a unique node identifier.

[0032] Each drone terminal is registered, and its unique device identifier is uniquely bound to the corresponding drone manufacturer's identifier.

[0033] In this embodiment, the public and private keys are key pairs in an asymmetric encryption algorithm, and they are one-to-one and indivisible. This embodiment uses asymmetric encryption algorithms (such as RSA and ECC) to generate exclusive key pairs for each drone manufacturer. By leveraging the characteristic of asymmetric encryption that "content encrypted by the private key can only be decrypted by the public key, and content encrypted by the public key can only be decrypted by the private key," it provides an algorithmic foundation for the subsequent digital signature of the drone terminal and the signature verification of the security verification node.

[0034] The private key is a confidential key, held exclusively by the corresponding drone manufacturer. It can be stored in the drone terminal's secure storage area (such as a Hardware Security Module (HSM) or Trusted Execution Environment (TEE)) via hardware flashing / firmware implantation. This is a non-physical, contactless writing process, and once written, it cannot be retrieved or tampered with by conventional means. The public key is a public key that can be legally distributed and stored in a key management system. The manufacturer's public key can be distributed to all security verification nodes responsible for verifying drone data from that manufacturer via an encrypted communication channel. After synchronization, the security verification nodes store the public key in their local encrypted cache for subsequent signature verification. Each drone manufacturer's key pair is independently generated and unique, serving as the core identifier distinguishing the legitimate identity of drone terminals from different manufacturers.

[0035] The core of distributed threshold collaboration is that multiple nodes participate in computation based on identifiers and collaborate according to share. Each symmetric key generation node needs to be assigned a unique identifier to ensure that it has a unique computational dimension during polynomial construction, key share calculation, and Lagrange interpolation key recovery, thus avoiding confusion in node calculation results. Specifically, when a symmetric key generation node first connects to the key management system, it submits a registration application. After reviewing the node's hardware performance, communication capabilities, and security level, the system assigns it a unique node identifier, such as a unique numeric or character identifier, and records information such as the node's service status, collaborative capabilities, and region. Only after completing registration can the symmetric key generation node join the key generation node group.

[0036] A unique device identifier is a unique hardware identifier for a drone terminal, such as a device serial number (SN), MAC address, or unique serial number on the drone's fuselage. It is a physical identifier that distinguishes different drone terminals and is globally unique. A manufacturer identifier is a unique identifier assigned to each drone manufacturer by the key management system, and it is associated one-to-one with the corresponding public / private key and drone terminal.

[0037] When verifying a drone's digital signature, the security verification node must first identify the manufacturer of the terminal and then retrieve the corresponding manufacturer's public key to complete the verification. Therefore, it is necessary to bind the terminal device identifier with the manufacturer identifier to form a "terminal-manufacturer-public key" association link. Specifically, before a drone terminal is put into operation, the drone manufacturer submits the terminal's unique device identifier, manufacturer identifier, and other information to the key management system. After reviewing the terminal information, the system uniquely binds the terminal device identifier with the manufacturer identifier and enters it into the encrypted database to complete the identity registration. Only after registration can the drone terminal initiate a flight session establishment request.

[0038] The above-mentioned system initialization operations, including manufacturer key generation, key distribution synchronization, node registration and identification, and terminal identity binding, enable the entire UAV key management system to have a legitimate identity authentication system and a standardized distributed node collaboration foundation. This provides a feasible prerequisite for subsequent threshold collaborative key generation, data encryption signing and decryption verification, and avoids the security risks of illegal manufacturers, illegal terminals, and illegal nodes accessing the system from the source, ensuring the legality, uniqueness, and verifiability of all subsequent key management operations.

[0039] In one specific embodiment, S1 includes the following steps:

[0040] S11. According to the preset splicing order, the flight mission identifier, the flight start timestamp, and the one-time random number generated collaboratively by the symmetric key generation node are spliced ​​together to obtain the information string.

[0041] S12, calculate the core key state corresponding to the flight session by using a cryptographic hash function to calculate the information string.

[0042] S13. Within a preset finite field, a reference polynomial of order t-1 is constructed based on the symmetric key generation node, where t is the first preset quantity threshold and the core key state quantity is the constant term of the reference polynomial.

[0043] S14, calculate the value of the self-node identifier of each symmetric key generation node on the reference polynomial, as the key share held by each symmetric key generation node.

[0044] S15, based on the number of symmetric key generation nodes and their corresponding key shares, the core key state is collaboratively recovered using the Lagrange interpolation algorithm.

[0045] S16. Based on the recovered core key state, a symmetric session key is generated through a key derivation function.

[0046] S17, the symmetric session key is sent to the corresponding drone terminal and security verification node respectively.

[0047] The one-time random number is a random number collaboratively generated by the symmetric key generation nodes participating in the key management of the current flight session using a cryptographic random number generation algorithm. It is used only for key generation in this flight session, destroyed immediately after generation, and not reused, thus improving the randomness and resistance to cracking of the key. Those skilled in the art will recognize that any existing cryptographic random number generation algorithm falls within the protection scope of this invention, such as CTR_DRBG and HMAC_DRBG, and will not be elaborated upon here.

[0048] The preset concatenation order is a predefined information concatenation rule of the key management system, such as "flight mission identifier → flight start timestamp → one-time random number". By using a fixed order, the information strings of the same flight session are guaranteed to be unique, and inconsistent hash results are avoided due to disordered concatenation order.

[0049] By leveraging the one-wayness and uniqueness of hash functions, the concatenated information string is transformed into a fixed-length, irreversible core key state quantity. This compresses the original information length and enhances the security of the key seed. Specifically, all symmetric key generation nodes participating in the key management of the current flight session call the same cryptographic hash function (such as SHA-256) to calculate the information string and verify the consistency of the hash calculation result. Once confirmed to be correct, the hash value is determined as the core key state quantity for this flight session, providing secure basic parameters for subsequent polynomial construction and key derivation.

[0050] The default finite field is usually a finite field of large prime numbers, such as GF(p), where p is a large prime number of 2048 bits or more. All polynomial calculations and key share calculations are completed within this finite field to avoid security risks such as integer overflow and reversible calculations.

[0051] Let n be the total number of symmetric key generation nodes participating in the current flight session key management. Based on the Shamir's Secret Sharing principle of threshold cryptography, if the core key state (secret) is to be split into n shares, at least t shares are needed to recover the secret (core key state). Therefore, the t-1 order polynomial is the mathematical carrier for realizing this split.

[0052] Specifically, n symmetric key generation nodes jointly and randomly select t-1 coefficients, namely a1, a2, ..., a1, within a preset finite field. t-1 Using the core key state variable as a constant term a0, we construct the reference polynomial of order t-1: f(x) = a0 + a1×x + a2×x 2 +……+a t-1 ×x t-1During system initialization, a unique digital identifier is assigned to each symmetric key generation node as its own node identifier, such as 1, 2, 3, etc., and is used as the x-value of the reference polynomial. The result of substituting the node identifier into the reference polynomial is the key share held by each symmetric key generation node.

[0053] Since the t-1 order polynomial can be uniquely determined by t distinct points, after collecting the key shares of t symmetric key generation nodes, the Lagrange interpolation algorithm is executed to reverse-engineer and recover the core key state quantity, which serves as the constant term of the reference polynomial, and the recovery result is verified to be consistent with the core key state quantity generated by S12, so as to ensure that there are no calculation errors.

[0054] Furthermore, all symmetric key generation nodes participating in the current flight session key management call the same key derivation function, using the recovered core key state as input, to derive a symmetric session key of a specified length (128 / 256 bits), and verify that the derivation results of all nodes are consistent to ensure the uniqueness of the key. Those skilled in the art will recognize that any key derivation function in the prior art falls within the protection scope of this invention, such as HKDF, PBKDF2, etc., and will not be elaborated upon here.

[0055] As described above, by concatenating flight session feature information with a one-time random number and hashing it to generate the core key state quantity, the core key seed has the characteristics of being session-specific and random and unpredictable, thus preventing the key from being cracked or reused in advance.

[0056] By constructing a reference polynomial of order t-1 within a finite field and splitting the key shares, the core key state is distributed and stored across multiple nodes, with no single node able to access it independently, thus solving the single-point leakage risk of centralized key storage.

[0057] By using Lagrange interpolation to collaboratively recover the core key state, key generation must meet the threshold node collaboration requirements, thus preventing a few nodes from maliciously generating incorrect keys and improving the security and reliability of key generation.

[0058] In one specific implementation, n ≧ 2×t-1.

[0059] It should be noted that, based on the security optimal configuration of threshold cryptography, when the total number n of symmetric key generation nodes participating in the key management of the current flight session satisfies n≥2×t-1, it can tolerate a maximum of t-1 nodes failing, being hijacked, or maliciously providing incorrect key shares / revocation judgment results, while still ensuring that no less than t normal nodes complete the key collaboration operation.

[0060] In practical applications, the values ​​of n and t can be flexibly adjusted according to the security level of different flight sessions. For example, for classified flight missions, t=5 and n can be 9, 10, 11, etc. For ordinary inspection missions, t=2 and n can be 3, 4, 5, 6, etc., so as to balance security and resource utilization and adapt to the needs of different drone application scenarios.

[0061] As described above, by setting the numerical relationship between the total number of symmetric key generation nodes and the first preset threshold, the key management process has the fault tolerance capability of t-1 nodes. Even if some nodes are offline, fail, or are attacked, the normal execution of key generation and revocation can still be guaranteed, thus improving the robustness and availability of the distributed key management system.

[0062] S2, the drone terminal uses the received symmetric session key and the corresponding drone manufacturer's private key to encrypt and sign the original flight dynamic data corresponding to the flight session, obtaining the data ciphertext and digital signature.

[0063] Among them, the raw flight dynamic data is the flight status data collected in real time by the UAV during the flight session, such as position, speed, altitude, flight trajectory, and onboard equipment status. It is plaintext data without any encryption processing and is considered sensitive information. Direct transmission of such data makes it easy to be stolen and tampered with.

[0064] In one specific embodiment, S2 includes the following steps:

[0065] S21, the UAV terminal uses a symmetric session key to encrypt the original flight dynamic data, obtaining ciphertext data.

[0066] S22, perform hash digest calculation on the raw flight dynamic data to obtain the data digest.

[0067] S23. Use the private key corresponding to the drone terminal to encrypt the data digest to obtain a digital signature.

[0068] S24, upload the encrypted data and digital signature to the secure verification node.

[0069] The UAV terminal uses the received symmetric session key to perform symmetric encryption on the original flight dynamic data, converting plaintext into ciphertext that cannot be directly read, thus ensuring the confidentiality of data transmission.

[0070] Simultaneously, the original flight dynamic data is hashed and digested, and asymmetric signature is performed using the manufacturer's private key pre-stored in the terminal to generate a digital signature as an electronic credential for terminal identity and data integrity. Finally, the encrypted data and digital signature are packaged into a reporting data packet according to the system's preset format, and auxiliary information such as terminal device identifier, flight session identifier, and timestamp are added. Through the terminal's built-in encrypted communication module, the reporting data packet is sent to the corresponding security verification node assigned by the system via an encrypted link to ensure that the security verification node can simultaneously complete data decryption and identity / integrity verification.

[0071] S3, the security verification node uses the received symmetric session key and the corresponding drone manufacturer's public key to decrypt and verify the received encrypted data and digital signature to obtain the plaintext flight dynamic data.

[0072] In one specific embodiment, S3 includes the following steps:

[0073] S31, the security verification node uses the symmetric session key to decrypt the ciphertext of the data to obtain the plaintext of the reference data to be verified.

[0074] S32, perform hash digest calculation on the plaintext of the reference data to obtain the verification digest.

[0075] S33. Use the public key corresponding to the security verification node to decrypt the digital signature and obtain the original data digest.

[0076] S34. If the verification digest and the original data digest are consistent, then the reference data plaintext is determined to be the flight dynamic data plaintext.

[0077] Among them, the security verification node, as the legitimate recipient of the symmetric session key, holds the same key as the drone terminal, and can therefore uniquely restore the plaintext data corresponding to the ciphertext. If the ciphertext is tampered with during transmission or decrypted using an incorrect key, the plaintext data with a valid format cannot be obtained, and the data can be directly determined to be abnormal.

[0078] By leveraging the collision resistance and avalanche effect of cryptographic hash functions, if the original flight dynamic data reported by the UAV terminal is not tampered with, the decrypted reference data plaintext will be completely consistent with the original flight dynamic data on the terminal side, and the hash digests generated by the two will also be completely identical; if the original flight dynamic data is tampered with during transmission or on the terminal side, the hash digest of the reference data plaintext will be significantly different from the original data digest on the terminal side.

[0079] Therefore, by comparing the verification digest with the original data digest bit by bit, if the two are completely consistent, it is determined that the original flight dynamic data has not been tampered with, and the reference data plaintext is marked as valid flight dynamic data plaintext for subsequent business processing; if the two are inconsistent, it is determined that the original flight dynamic data has been tampered with on the transmission or terminal side, and preset abnormal handling operations need to be performed, such as discarding data, recording terminal abnormalities, triggering alarms, etc., and no invalid data is transmitted to the business layer.

[0080] S4 maintains the symmetric session key in a valid state during normal flight session operation and detects in real time whether the preset revocation condition is triggered.

[0081] During the normal operation phase of a flight session, from its establishment until no revocation conditions are triggered, the symmetric key generation node participating in the key management of the current flight session will uniformly mark the symmetric session key corresponding to this flight session as valid and synchronize it to the security verification node, ensuring that the UAV terminal and the security verification node can use the key to complete data encryption, decryption and verification normally.

[0082] Meanwhile, the symmetric key generation node collects flight session status, UAV equipment status, and task execution status in real time through the system data link, and performs real-time matching and detection with preset revocation conditions. Once any revocation condition is detected, the subsequent key revocation process is immediately initiated, realizing real-time linkage and precise synchronization between key status and flight session status.

[0083] During normal operation of the flight session, the symmetric key generation node can refresh and confirm the key validity status according to a preset heartbeat period, such as 1 second / 5 seconds, to avoid loss of status markers due to system failure.

[0084] In one specific implementation, the preset cancellation conditions include one of the following: the flight plan time has ended, the UAV status is abnormal, a forced cancellation command has been received, or the UAV has not reported flight dynamic data for a preset duration.

[0085] Correspondingly, the symmetric key generation node acquires in real time the planned end time of the flight mission, the real-time geographical location of the UAV, the operating status of the UAV's onboard equipment, the command information issued by the system, and the data reporting records from the UAV to the security verification node through a unified status acquisition link. The acquired real-time data is matched against preset revocation conditions one by one using standardized rules. The matching process is executed synchronously by no fewer than t symmetric key generation nodes to ensure the accuracy of the detection results.

[0086] Once any symmetric key generation node detects a revocation condition, it immediately synchronizes the trigger information and detection criteria to all symmetric key generation nodes. After consensus confirmation among the nodes, this serves as the formal trigger signal to initiate the key revocation process. If no revocation condition is detected, the key remains valid while maintaining the real-time nature of the detection link until the flight session terminates normally.

[0087] It should be noted that the preset cancellation conditions cover core drone flight scenarios such as normal mission completion, equipment malfunction, active control, and data loss. All conditions are OR logic, and the system will be triggered if any one of them is met. The system can be flexibly selected according to the security level of the drone application scenario. For example, all conditions can be used for classified flight missions, while some conditions can be used for ordinary inspection missions.

[0088] S5, when the preset revocation condition is triggered, each symmetric key generation node outputs the revocation judgment result, where the revocation judgment result is either recommended to revoke or not recommended to revoke.

[0089] When any preset revocation condition is detected and the trigger signal is synchronized to all symmetric key generation nodes participating in the current flight session, each symmetric key generation node independently completes the revocation rationality verification based on its own collected flight session status and revocation condition triggering basis. It does not negotiate in advance with other symmetric key generation nodes or interfere with each other's judgment process. Finally, each symmetric key generation node outputs a unique revocation judgment result.

[0090] S6. If the number of symmetric key generation nodes that are recommended for revocation is not less than the second preset number threshold, then the symmetric session key is marked as invalid.

[0091] The second preset threshold is the minimum number of nodes that agree to complete the key revocation decision. Its value can be flexibly configured according to the security level of the drone flight scenario. For example, the second preset threshold for classified flights is 5, and the second preset threshold for ordinary flights is 3.

[0092] The above-mentioned threshold-based determination avoids misjudgment or malicious behavior by a few nodes that could lead to incorrect or illegal key revocation, thus ensuring the security and rigor of key revocation decisions.

[0093] In one specific implementation, after marking the symmetric session key as invalid, the key management method for UAVs further includes the following steps:

[0094] S7, stop providing symmetric session keys to drone terminals and security verification nodes.

[0095] S8, clear the symmetric session key stored in the symmetric key generation node.

[0096] S9 prohibits processing requests for data decryption or verification based on symmetric session keys.

[0097] Specifically, after marking the entire symmetric session key as invalid, the symmetric key generation nodes participating in the current flight session key management immediately initiate subsequent security cleanup operations. First, they stop providing any related services for the invalid key to the UAV terminal and security verification nodes, cutting off the link from the key service supply side. Then, they clear the invalid key stored locally on all symmetric key generation nodes, eliminating the risk of leakage from the key physical storage side. Finally, the symmetric key generation nodes work with the security verification nodes to uniformly prohibit the processing of all decryption and verification requests based on the invalid key, completely rejecting its use from the key service request side.

[0098] The above three steps are progressive and form a closed loop, realizing the control of service termination, storage clearing and request rejection of invalid keys. This ensures that invalid keys are not used, stored and used in the entire system, forming a complete key revocation chain from marking invalid to complete disabling, making the key revocation operation highly reliable and secure.

[0099] The above-mentioned method, through the collaborative generation of symmetric key generation nodes (no fewer than a first preset threshold number) to uniquely associate a symmetric session key with the flight session identifier, eliminates the dependence on a single node in the symmetric session key generation process, avoiding key generation failure due to single-point-of-failure issues. Simultaneously, binding the key with the flight mission identifier and flight start timestamp achieves precise matching of the key's lifecycle with the UAV flight session, eliminating the risk of key misuse across sessions from the source. By continuously maintaining the symmetric key in a valid state during normal flight session operation and real-time detecting preset revocation conditions, the key state can be synchronized with the flight session's operational state, achieving dynamic and real-time control over key validity and preventing... The security risks posed by keys remaining valid during abnormal flight sessions are addressed by implementing a new mechanism. This mechanism requires multiple nodes to collaboratively confirm key revocation decisions, avoiding abnormal revocations caused by single-node errors or malicious actions. Furthermore, it distributes the computational and decision-making load of the entire key management system across multiple symmetric key generation nodes, resolving the performance bottleneck of centralized key management in high-concurrency scenarios involving large-scale UAVs. This improves the processing efficiency and scalability of key management methods, adapting to the dynamic operational needs of large-scale UAVs.

[0100] Example 2

[0101] Embodiment 2 of the present invention provides a non-transitory computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiment. The at least one instruction or at least one program is loaded and executed by the processor to implement the key management method for UAVs provided in the above embodiment.

[0102] Example 3

[0103] Embodiment 3 of the present invention provides an electronic device, which includes a processor and the non-transitory computer-readable storage medium of Embodiment 2 of the present invention.

[0104] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A key management method for unmanned aerial vehicles (UAVs), characterized in that, The key management method for UAVs includes the following steps: S1, when the UAV triggers a flight session establishment request, at least a first preset threshold of symmetric key generation nodes collaboratively generate a symmetric session key uniquely associated with the identification information of the flight session, wherein the identification information includes at least a flight mission identifier and a flight start timestamp. S1 includes the following steps: S11, according to a preset splicing order, the flight mission identifier, the flight start timestamp, and the one-time random number jointly generated by the symmetric key generation node are spliced ​​together to obtain an information string; S12, calculate the information string according to the cryptographic hash function to obtain the core key state quantity corresponding to the flight session; S13, within a preset finite field, a reference polynomial of order t-1 is constructed based on the symmetric key generation node, where t is a first preset quantity threshold, and the core key state quantity is a constant term of the reference polynomial. S14, calculate the value of the self-node identifier of each symmetric key generation node on the reference polynomial, as the key share held by each symmetric key generation node; S15, based on the number of symmetric key generation nodes and their corresponding key shares not less than the first preset threshold, the core key state quantity is collaboratively recovered using the Lagrange interpolation algorithm; S16, Based on the recovered core key state, the symmetric session key is generated through a key derivation function; S17, the symmetric session key is sent to the corresponding drone terminal and security verification node respectively; S2, the drone terminal uses the received symmetric session key and the private key of the corresponding drone manufacturer to encrypt and sign the original flight dynamic data corresponding to the flight session to obtain data ciphertext and digital signature; S3, the security verification node uses the received symmetric session key and the corresponding drone manufacturer's public key to decrypt and verify the received encrypted data and digital signature to obtain the plaintext flight dynamic data; S4. During normal operation of the flight session, maintain the symmetric session key in a valid state and detect in real time whether a preset revocation condition is triggered. S5, when the preset revocation condition is triggered, each symmetric key generation node outputs the revocation judgment result, wherein the revocation judgment result is either recommended to revoke or not recommended to revoke; S6. If the number of symmetric key generation nodes that are recommended for revocation is not less than the second preset number threshold, then the symmetric session key is marked as invalid.

2. The key management method for unmanned aerial vehicles according to claim 1, characterized in that, Prior to S1, the key management method for UAVs also performs system initialization, including the following steps: Generate a unique public and private key for each drone manufacturer; Write the private key into the corresponding drone terminal, and synchronize the public key to the corresponding security verification node; Each symmetric key generation node is registered and assigned a unique node identifier; Each drone terminal is registered, and its unique device identifier is uniquely bound to the corresponding drone manufacturer's identifier.

3. The key management method for unmanned aerial vehicles according to claim 2, characterized in that, S2 includes the following steps: S21, the UAV terminal uses the symmetric session key to encrypt the original flight dynamic data to obtain the ciphertext data; S22, perform hash digest calculation on the original flight dynamic data to obtain a data digest; S23, use the private key corresponding to the drone terminal to encrypt the data digest to obtain a digital signature; S24, upload the encrypted data and the digital signature to the security verification node.

4. The key management method for unmanned aerial vehicles according to claim 2, characterized in that, S3 includes the following steps: S31, the security verification node uses the symmetric session key to decrypt the ciphertext of the data to obtain the plaintext of the reference data to be verified; S32, perform hash digest calculation on the plaintext of the reference data to obtain a verification digest; S33, use the public key corresponding to the security verification node to decrypt the digital signature to obtain the original data digest; S34, if the verification digest and the original data digest are consistent, then the reference data plaintext is determined to be the flight dynamic data plaintext.

5. The key management method for unmanned aerial vehicles according to claim 4, characterized in that, S3 also includes the following steps: If the verification digest and the original data digest are inconsistent, the verification is deemed to have failed, and data discarding, abnormal recording, or alarm operations are performed according to preset rules.

6. The key management method for unmanned aerial vehicles according to claim 1, characterized in that, The preset cancellation conditions include one of the following: the flight plan time ends, the UAV status is abnormal, a forced cancellation command is received, or the UAV fails to report flight dynamic data for a preset duration.

7. The key management method for unmanned aerial vehicles according to claim 1, characterized in that, The key management method for UAVs also includes the following steps: S7, stop providing the symmetric session key to the drone terminal and the security verification node; S8, Clear the symmetric session key stored in the symmetric key generation node; S9, Prohibit the processing of requests for data decryption or verification based on the symmetric session key.

8. A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the key management method for unmanned aerial vehicles as described in any one of claims 1-7.

9. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 8.

Images