Method for establishing end-to-end secure communication of unmanned aerial vehicle under cloud network architecture

By providing end-to-end authentication services for drones through cloud servers, and utilizing digital signatures and the Diffie-Hellman algorithm, efficient end-to-end secure communication between drones is achieved. This solves the storage and computation pressure problem of key negotiation under the limited resources of drones, and ensures the security and effectiveness of communication.

CN117376911BActive Publication Date: 2026-07-07XIDIAN UNIV

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
XIDIAN UNIV
Filing Date
2023-09-15
Publication Date
2026-07-07

AI Technical Summary

Technical Problem

In existing drone communication, as the scale and number of end systems increase, storage pressure is high and the economic cost of large-scale certificate management is high. Furthermore, when drone resources are limited, existing key negotiation schemes require pre-storing the other party's public key or certificate information, resulting in excessive computing and communication overhead.

Method used

Adopting a cloud-network-edge architecture, the system utilizes a cloud server as a security service center to provide end-to-end authentication services for drones. By distributing publicly available authentication materials through the cloud server, it enables session key negotiation and end-to-end secure communication between drones, avoiding the need for drones to pre-store the other party's authentication materials. It also combines digital signatures and the Diffie-Hellman algorithm for key negotiation.

Benefits of technology

It reduces the computational and storage burden on drones, lowers certificate management costs, enables efficient end-to-end secure communication, resists man-in-the-middle attacks and replay attacks, and links the session key validity period to the task cycle, avoiding the harm of long-term and short-term secret leakage.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117376911B_ABST
    Figure CN117376911B_ABST
Patent Text Reader

Abstract

The application discloses a method for establishing end-to-end secure communication of unmanned aerial vehicle under cloud network architecture, and takes cloud server as a security service center to provide full-process authentication service for unmanned aerial vehicle end system; the cloud server only issues public authentication materials to unmanned aerial vehicles, and session key negotiation and establishment of end-to-end secure communication are realized between unmanned aerial vehicles; the unmanned aerial vehicle end system does not need to store authentication materials of other unmanned aerial vehicles in advance, the cloud server is driven by specific tasks, and specific authentication materials required for key negotiation are issued to unmanned aerial vehicles which need to be securely cooperated according to task requirements. The application only requires that the cloud server and any one of the unmanned aerial vehicles for key negotiation establish a communication connection, and the authentication materials issued by the cloud server can make the unmanned aerial vehicles realize key negotiation and establish an end-to-end secure channel in a specific range; different temporary public keys are used for each request message, which can effectively prevent the harm caused by long-term and short-term secret leakage.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of communication technology and relates to a method for establishing end-to-end secure communication for unmanned aerial vehicles under a cloud-network-terminal architecture. Background Technology

[0002] With the increasing demand for drone-related applications and the growing complexity of mission scenarios, the limitations of single drones in terms of computing and storage restrict their information processing capabilities under complex tasks. Multi-drone collaboration has become a new trend in drone technology development. At the same time, secure data sharing among multiple drones has become crucial. How to achieve secure communication between drones requiring secure communication has become an unavoidable and urgent problem to solve.

[0003] In achieving secure end-to-end communication, a shared key is typically used to encrypt and decrypt messages between two end systems. However, establishing or transmitting the encryption / decryption key between these two systems over an insecure communication channel remains a fundamental challenge. Existing solutions can be categorized into two types. One type involves encrypting the session key for transmission, such as RSA asymmetric encryption and ECC elliptic curve encryption. The other type involves the two end systems negotiating and calculating a common session key, such as the DH algorithm or ECDH algorithm. The former typically uses public-key encryption and private-key decryption; the sender encrypts the session key using the receiver's public key, and the receiver decrypts it using its own private key. The latter method involves sending their respective public keys over a public channel and then combining them with their private keys to calculate a common key using the DH algorithm, which serves as the session key.

[0004] The two existing technical solutions, when achieving secure end-to-end communication between end systems, either require obtaining the other party's public key in advance or sharing their own public key information. However, they still face the following challenges: When end systems do not have third-party assistance such as cloud servers, key negotiation between end systems requires pre-storing the other party's public key and other authentication materials. As the scale and number of end systems continue to increase, the storage pressure will also increase, which is not suitable for resource-constrained end systems such as drones. When end systems have trusted third-party authorized certificates, the end system needs to verify the trustworthiness of the certificate before obtaining the public key information in the other party's certificate. However, this often introduces additional computing or communication overhead, and large-scale certificate management will bring additional cost. Summary of the Invention

[0005] The purpose of this invention is to provide a method for establishing end-to-end secure communication for drones under a cloud-network-terminal architecture, which solves the problems of the increasing number of terminal systems, high storage pressure, and high economic costs caused by large-scale certificate management in existing drone communication.

[0006] The first technical solution adopted in this invention is: a method for establishing end-to-end secure communication for drones under a cloud-network-device architecture. Based on the "cloud-network-device" secure collaborative architecture, the cloud server acts as the security service center to provide full-process authentication services for the drone terminal system. The cloud server only issues publicly available authentication materials to the drones, and the drones negotiate session keys and establish end-to-end secure communication. The drone terminal system does not need to pre-store the authentication materials of other drones. The cloud server is driven by specific tasks, determines the drones that need secure collaboration according to task requirements, and issues specific authentication materials required for key negotiation to these drones.

[0007] The invention is further characterized by:

[0008] The specific steps for establishing end-to-end secure communication for drones under a cloud-network-device architecture are as follows:

[0009] S1: The cloud server identifies drone end nodes A and B that require secure collaboration, with drone A as the requesting end node and drone B as the responding end node.

[0010] S2: After the cloud server distributes the authentication materials and signature to drone A, drone A determines the validity of the message: if the verification passes, it continues to the next step; if the verification fails, it stops.

[0011] S3: Drone A calculates the session key, generates a new short-term public-private key pair, and updates the short-term public key to the cloud server. The cloud server verifies the short-term public key. If the verification is successful, the old short-term public key is updated to the new short-term public key. If the verification fails, it is discarded.

[0012] S4: Drone A sends a message request to Drone B. Drone B verifies whether the message is fresh. If the message is fresh, it proceeds to the next step. If it is not fresh, it stops.

[0013] S5: Drone B calculates the session key, generates a new short-term public-private key pair, and updates the short-term public key to the cloud server; the cloud server verifies the short-term public key. If the verification is successful, the old short-term public key is updated to the new short-term public key; if the verification fails, it is discarded.

[0014] A cloud server is a cloud platform with high-performance computing and storage. As a control center, it is responsible for planning missions for registered drones and providing security services for them. When a specific mission requires multiple drones to collaborate, the cloud server must not only plan the flight missions and collaborating objects for the end nodes, but also establish end-to-end secure connections for both collaborating parties to ensure secure communication between the end nodes.

[0015] The specific operating steps for S2 are as follows:

[0016] S2.1: The cloud server reads the authentication materials submitted by drone A and drone B during the registration phase, specifically including drone A's long-term public key IK. A .pub and short-term public key SPK A .pub, the long-term public key IK of drone B B .pub and short-term public key SPK B .pub;

[0017] S2.2: The cloud server uses its own long-term private key IK C .priv to IK A .pub||SPK B The hash digest value of the .pub file is signed to obtain the signature Sig. CB :

[0018] Sig CB =sig_enc(IK C .priv, Hash(IK A .pub||SPK B .pub))

[0019] S2.3: Cloud servers use their own long-term private key (IK). C .priv for SPK A .pub||IK B .pub||SPK B .pub||Sig CB The hash digest value is used to sign the result, resulting in the signature Sig. CA :

[0020] Sig CA =sig_enc(IK C .priv, Hash(SPK) A .pub||IK B .pub||SPK B .pub||Sig CB ))

[0021] S2.4: The cloud server will respond with the long-term and short-term public key IK of node drone B. B .pub and SPK B .pub and its own signature Sig CB Sig CA Send it together to drone A, which is the requesting node;

[0022] S2.5: After receiving the authentication materials and signature sent by the cloud server, Drone A uses IK... C .pub Verify Signature Sig CADetermine the validity of the message:

[0023] Hash(SPK A .pub||IK B .pub||SPK B .pub||Sig CB ) = sig_dec(IK C .pub, Sig CA )

[0024] If the verification passes, proceed to the next step; if the verification fails, stop.

[0025] The specific operating steps for S3 are as follows:

[0026] S3.1: Drone A generates a temporary public-private key pair (EK). A .pub, EK A .priv), and uses the Diffie-Hellman algorithm and the long-term public key IK of drone B. B .pub, Short-term public key (SPK) B .pub and your own long-term private key IK A .priv, temporary private key EK A .priv calculates the intermediate value of the session key:

[0027] K1=DH(IK A .priv, SPK B .pub),

[0028] K2=DH(EK A .priv, IK B .pub),

[0029] K3=DH(EK A .priv, SPK B .pub);

[0030] S3.2: Drone A uses the key derivation function KDF and the K1, K2, and K3 calculated in the previous step to calculate the session key K. AB :K AB =KDF(K1||K2||K3);

[0031] S3.3: Drone A obtains the current timestamp T A Using long-term private key IK A .priv to IK A .pub||EK A .pub||Sig CB ||T A Signing the hash digest yields SigAB :

[0032] Sig AB =sig_enc(IK A .priv, Hash(IK A .pub||EK A .pub||Sig CB ||T A ))

[0033] S3.4: Drone A generates a new short-term public-private key pair. Using your own long-term private key IK A .priv Sign to obtain Sig AC :

[0034]

[0035] S3.5: Drone A will and signature Sig AC After successfully sending to the cloud server, delete the old short-term public-private key pair (SPK). A .pub, SPK A .priv) and the current temporary public-private key pair (EK) A .pub, EK A .priv); The cloud server receives a new short-term public key sent by drone A. and signature Sig AC Then, use the long-term public key IK of drone A. A .pub for signing Sig AC Verification required:

[0036]

[0037] If the verification passes, the old short-term public key SPK will be transferred. A .pub updated to the new short-term public key If the verification fails, discard the data.

[0038] The specific operating steps for S4 are as follows:

[0039] S4.1: Drone A transmits its long-term public key IK A .pub, Temporary public key EK A .pub, timestamp T A And the signature Sig CB and Sig AB Send it to drone B together;

[0040] S4.2: When drone B, acting as the responding endpoint, receives the request message from drone A, it first sets the timestamp T in the request message... A With the current timestamp T B For comparison, ΔT is the preset tolerable time delay; if |T B -T A If |≤ΔT, then the message is fresh and the next operation is performed; otherwise, the operation is stopped.

[0041] S4.3: Drone B uses the cloud server's long-term public key IK C .pub for signing Sig CB To determine the validity:

[0042] Hash(IK A .pub||SPK B .pub) = sig_dec(IK C .pub, Sig CB )

[0043] If verification fails, stop; if verification succeeds, use drone A's long-term public key IK. A .pub for signing Sig AB To determine the validity:

[0044] Hash(IK A .pub||EK A .pub||Sig CB ||T A ) = sig_dec(IK C .pub, Sig AB )

[0045] If the verification fails, stop; if the verification succeeds, continue to the next step.

[0046] The specific operating steps for S5 are as follows:

[0047] S5.1: Drone B uses the Diffie-Hellman algorithm and Drone A's long-term public key IK. B .pub Temporary Public Key (EK) A .pub and your own long-term private key IK B .priv, short-term private key (SPK) B .priv calculates the intermediate value of the session key:

[0048] K1 = DH(SPK) B .priv, IK A .pub),

[0049] K2=DH(IK B.priv, EK A .pub),

[0050] K3 = DH(SPK) B .priv, EK A .pub);

[0051] S5.3: Drone B uses the key derivation function KDF and the K1, K2, and K3 calculated in the previous step to calculate the session key K. AB :K AB =KDF(K1||K2||K3);

[0052] S5.4: Drone B generates a new short-term public-private key pair. Using your own long-term private key IK B .priv Sign to obtain Sig BC :

[0053]

[0054] S5.4: After drone B resumes network communication with the cloud server, it updates its short-term public key. and signature Sig BC After successfully sending to the cloud server, delete the old short-term public-private key pair (SPK). B .pub, SPK B .priv);

[0055] S5.5: The cloud server receives a new short-term public key from drone B. and signature Sig BC Then, use the long-term public key IK of drone B. B .pub for signing Sig BC Verification required:

[0056]

[0057] If the verification passes, the old short-term public key SPK will be transferred. B .pub updated to the new short-term public key If the verification fails, discard.

[0058] Key innovations of this invention:

[0059] (1) Based on the cloud-network-device security collaboration architecture, the cloud server acts as the UAV control center while providing full-process security services, offering authentication and key negotiation services for all registered UAVs. A single UAV node can establish an end-to-end secure channel with the target UAV through a single round of communication based on the authentication materials issued by the cloud server, thus achieving secure collaboration. On the one hand, this can alleviate the pressure on UAVs in terms of computing and storage, and on the other hand, it can minimize the message interaction between UAVs.

[0060] (2) As long as the cloud server establishes a network connection with either of the drones in the key negotiation, the drones in both parties can still conduct key negotiation and establish an end-to-end secure channel within a specific range through the authentication materials issued by the cloud server.

[0061] (3) The end-to-end secure communication establishment method proposed in this invention uses long-term, short-term and temporary public-private key pairs with different validity periods when the two UAVs calculate the session key. Combined with digital signature technology and DH key negotiation algorithm, it can realize the verification of message validity and freshness. At the same time, it satisfies that the negotiated session key is only valid during the task execution period, which can effectively resist man-in-the-middle attacks and replay attacks, and ensure the forward security of the session key.

[0062] The beneficial effects of this invention are:

[0063] (1) More reasonable allocation of system resources: The cloud server, as the control center, is driven by specific tasks when planning end system tasks, determines the end node drones that need to be securely coordinated, and provides full-process security services for the drones; the end node drones do not need to store additional authentication materials in advance, nor do they need a complicated certificate management mechanism, which greatly reduces the various expenses of resource-constrained end systems such as drones, and maximizes the advantages of cloud servers in computing and storage.

[0064] (2) Lower requirements for control link stability: The high dynamic operation of UAVs often causes the control link between the cloud server and the UAV to be intermittent. This invention only requires the cloud server to establish a communication connection with either of the UAVs of the two parties involved in the key negotiation. Through the authentication materials issued by the cloud server, the two UAVs can achieve key negotiation and establish an end-to-end secure channel within a specific range.

[0065] (3) Enhanced Session Key Security: When calculating the session key, this invention uses a long-term public-private key pair combined with a digital signature algorithm to authenticate messages, preventing man-in-the-middle attacks. Using long-term, short-term, and temporary public-private key pairs, along with verifiable timestamps in the request message, combined with a multi-round DH algorithm for key negotiation, it can resist replay attacks and ensure forward security. Each key negotiation session additionally uses a temporary public-private key pair; that is, each request message uses a different temporary public key, effectively preventing harm caused by the leakage of long and short-term secrets.

[0066] (4) Session key validity period is linked to the task cycle: Since the UAV updates the short-term public key stored on the cloud server after calculating the session key, the previous authentication materials and session key will become invalid once the current task ends, effectively linking the validity period of the session key to the task cycle. The negotiated session key is only valid during the execution period of this task, and even if the current session key is leaked, it will not cause harm to previous or subsequent tasks. Attached Figure Description

[0067] Figure 1 This is a schematic diagram illustrating the principle of the cloud-network-end architecture of the present invention;

[0068] Figure 2 This is a schematic diagram of the system architecture composition based on the cloud-network-terminal architecture of the present invention;

[0069] Figure 3 The flowchart illustrates a method for establishing end-to-end secure communication between unmanned aerial vehicles (UAVs) based on a cloud-network-device architecture, as provided in this embodiment of the invention. Detailed Implementation

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

[0071] Example 1

[0072] The communication system of the present invention, as follows Figure 1-2 As shown, a cloud server is a cloud platform with high-performance computing and storage. As a control center, it is responsible for planning missions for registered drones and providing security services for them. In particular, when a specific mission requires multiple drones to collaborate, the cloud server must not only plan the flight missions and collaborating objects for the end nodes, but also establish end-to-end secure connections for both collaborating parties to ensure secure communication between the end nodes.

[0073] End system nodes are terminal devices, which can be manned or unmanned systems, and have basic network connection and communication functions, as well as limited computing and storage functions;

[0074] The communication network is unrestricted; it can be a wired network or a wireless network.

[0075] Example 2

[0076] The present invention discloses a method for establishing end-to-end secure communication for drones under a cloud-network-device architecture. Based on a "cloud-network-device" secure collaborative architecture, the cloud server acts as a security service center to provide full-process authentication services for the drone terminal system. The cloud server only issues publicly available authentication materials to the drones, and the drones negotiate session keys to establish end-to-end secure communication. The drone terminal system does not need to pre-store the authentication materials of other drones. The cloud server is driven by specific tasks, determines the drones that need secure collaboration based on task requirements, and issues the specific authentication materials required for key negotiation to these drones.

[0077] Example 3

[0078] (1) Drone registration stage

[0079] Before deploying a drone, it needs to be registered on a cloud server.

[0080] The drone needs to send its authentication materials, including its long and short public keys and its short public key, to the cloud server through a secure channel. The cloud server, in turn, needs to send its public key to the registered drone through a secure channel. Specifically, taking drone X as an example, the steps are as follows:

[0081] 1) Drone X generates a long-term public-private key pair (IK). X .pub, IK X .priv), where IK X .pub serves as the unique identifier for drone X;

[0082] 2) Drone X generates a short-term public-private key pair (SPK). X .pub, SPK X .priv);

[0083] 3) Drone X will have a long-term public key IK x .pub, Short-term public key (SPK) x The .pub file is sent to the cloud server for registration via a secure channel; a short-term public-private key pair with a limited validity period is used to bind the execution time of the task to the validity period of the generated session key; a temporary public-private key pair is generated temporarily each time a key is negotiated to prevent the leakage of session keys caused by the leakage of long and short-term keys.

[0084] 4) After receiving the authentication materials sent by drone X, the cloud server securely stores them and stores its public key IK. C Send the .pub file to drone X;

[0085] 5) Drone X will transfer the public key IK of the cloud server. C .pub files are securely stored on the onboard storage device.

[0086] (2) End-to-end secure communication establishment phase

[0087] Based on specific task requirements, when multiple drones need to collaborate to complete a task, the task planning module of the cloud server determines the drone nodes that need to establish end-to-end secure communication and provides authentication and key negotiation services for these drone nodes.

[0088] Furthermore, the cloud server needs to identify the drone that is the requesting node and the drone that is the responding node for the authentication service.

[0089] Taking drone endpoints A and B as an example, where drone A is the requesting endpoint and drone B is the responding endpoint, as follows: Figure 3 As shown, the specific steps are as follows:

[0090] 1) The cloud server is driven by specific tasks to determine the drone end nodes A and B that need to cooperate securely, with drone A as the requesting end node and drone B as the responding end node.

[0091] 2) The cloud server reads the authentication materials submitted by drone A and drone B during the registration phase, specifically including drone A's long-term public key IK. A .pub and short-term public key SPK A .pub, the long-term public key IK of drone B B .pub and short-term public key SPK B .pub;

[0092] 3) Cloud servers use their own long-term private key (IK) C .priv to IK A .pub||SPK B The hash digest value of the .pub file is signed to obtain the signature Sig. CB :

[0093] Sig CB =sig_enc(IK C .priv, Hash(IK A .pub||SPK B .pub))

[0094] 4) Cloud servers use their own long-term private key (IK) C.priv for SPK A .pub||IK B .pub||SPK B .pub||Sig CB The hash digest value is used to sign the result, resulting in the signature Sig. CA :

[0095] Sig CA =sig_enc(IK C .priv, Hash(SPK) A .pub||IK B .pub||SPK B .pub||Sig CB ))

[0096] 5) The cloud server will respond with the long-term and short-term public key IK of node drone B. B .pub and SPK B .pub and its own signature Sig CB Sig CA Send it together to drone A, which is the requesting node;

[0097] 6) After receiving the authentication materials and signature sent by the cloud server, drone A uses IK... C .pub Verify Signature Sig CA Determine the validity of the message:

[0098] Hash(SPK A .pub||IK B .pub||SPK B .pub||Sig CB ) = sig_dec(IK C .pub, Sig CA )

[0099] If the verification passes, proceed to the next step; if the verification fails, stop.

[0100] 7) Drone A generates a temporary public-private key pair (EK). A .pub, EK A .priv), and uses the Diffie-Hellman algorithm and the long-term public key IK of drone B. B .pub, Short-term public key (SPK) B .pub and your own long-term private key IK A .priv, temporary private key EK A .priv calculates the intermediate value of the session key:

[0101] K1=DH(IKA .priv, SPK B .pub),

[0102] K2=DH(EK A .priv, IK B .pub),

[0103] K3=DH(EK A .priv, SPK B .pub);

[0104] 8) Drone A uses the KDF (Key Derivation Function) and the K1, K2, and K3 calculated in the previous step to calculate the session key K. AB :K AB =KDF(K1||K2||K3);

[0105] 9) Drone A obtains the current timestamp T A Using long-term private key IK A .priv to IK A .pub||EK A .pub||Sig CB ||T A Signing the hash digest yields Sig AB :

[0106] Sig AB =sig_enc(IK A .priv, Hash(IK A .pub||EK A .pub||Sig CB ||T A ))

[0107] 10) Drone A transmits its long-term public key IK A .pub, Temporary public key EK A .pub, timestamp T A And the signature Sig CB and Sig AB Send it to drone B together;

[0108] 11) Drone A generates a new short-term public-private key pair. Using your own long-term private key IK A .priv Sign to obtain Sig AC :

[0109]

[0110] 12) Drone A will After the SigAC signature is successfully sent to the cloud server, the old short-term public-private key pair (SPK) is deleted. A .pub, SPK A .priv) and the current temporary public-private key pair (EK) A .pub, EK A .priv);

[0111] 13) When drone B, acting as the responding endpoint, receives the request message from drone A, it first sets the timestamp T in the request message to... A With the current timestamp T B For comparison, ΔT is the preset tolerable time delay; if |T B -T A If |≤ΔT, then the message is fresh and the next operation is performed; otherwise, the operation is stopped.

[0112] 14) Drone B uses the long-term public key IK of the cloud server. C .pub for signing Sig CB To determine the validity:

[0113] Hash(IK A .pub||SPK B .pub) = sig_dec(IK C .pub, Sig CB )

[0114] If verification fails, stop; if verification succeeds, use drone A's long-term public key IK. A .pub for signing Sig AB To determine the validity:

[0115] Hash(IK A .pub||EK A .pub||Sig CB ||T A ) = sig_dec(IK C .pub, Sig AB )

[0116] If the verification fails, stop; if the verification succeeds, continue to the next step.

[0117] 15) Drone B uses the Diffie-Hellman algorithm and Drone A's long-term public key IK. B .pub Temporary Public Key (EK) A .pub and your own long-term private key IK B .priv, short-term private key (SPK) B.priv calculates the intermediate value of the session key:

[0118] K1 = DH(SPK) B .priv, IK A .pub),

[0119] K2=DH(IK B .priv, EK A .pub),

[0120] K3 = DH(SPK) B .priv, EK A .pub);

[0121] 16) Drone B uses the KDF (Key Derivation Function) and the K1, K2, and K3 calculated in the previous step to calculate the session key K. AB :K AB =KDF(K1||K2||K3);

[0122] 17) Drone B generates a new short-term public-private key pair. Using your own long-term private key IK B .priv Sign to obtain Sig BC :

[0123]

[0124] 18) After drone B resumes network communication with the cloud server, it updates its short-term public key. and signature Sig BC After successfully sending to the cloud server, delete the old short-term public-private key pair (SPK). B .pub, SPK B .priv);

[0125] 19) The cloud server receives a new short-term public key from drone A. and signature Sig AC Then, use the long-term public key IK of drone A. A .pub for signing Sig AC Verification required:

[0126]

[0127] If the verification passes, the old short-term public key SPK will be transferred. A .pub updated to the new short-term public key If the verification fails, discard the data.

[0128] Similarly, the cloud server receives a new short-term public key from drone B. and signature Sig BC Then, use the long-term public key IK of drone B. B .pub for signing Sig BC Verification required:

[0129]

[0130] If the verification passes, the old short-term public key SPK will be transferred. B .pub updated to the new short-term public key If the verification fails, discard the data.

[0131] This invention is based on a "cloud-network-device" secure collaborative architecture, fully leveraging the powerful computing and storage capabilities of cloud servers. The cloud server acts as a security service center, providing end-to-end authentication services for edge systems such as drones. Since communication between the cloud server and drones is an insecure open channel, the cloud server should avoid directly distributing session keys for encrypted communication to drones. Instead, the cloud server only issues publicly available authentication materials to drones, allowing drones to negotiate session keys and establish end-to-end secure communication. End systems like drones do not need to pre-store authentication materials for other drones. The cloud server is task-driven, identifying drones requiring secure collaboration based on task requirements and issuing the specific authentication materials needed for key negotiation to these drones.

[0132] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for establishing end-to-end secure communication for unmanned aerial vehicles (UAVs) under a cloud-network-device architecture, characterized in that: Based on the "cloud-network-terminal" security collaboration architecture, and with the cloud server as the security service center, it provides full-process authentication services for drone terminal systems; The cloud server only sends publicly available authentication materials to the drones, and the drones negotiate session keys and establish end-to-end secure communication. The drone-based system does not require pre-storing authentication materials for other drones. The cloud server is task-driven, identifying the drones requiring secure collaboration based on task requirements and distributing the necessary authentication materials for key negotiation to these drones; specifically as follows: S1: The cloud server identifies drone end nodes A and B that require secure collaboration, with drone A as the requesting end node and drone B as the responding end node. S2: After the cloud server distributes the authentication materials and signature to drone A, drone A determines the validity of the message: if the verification passes, it continues to the next step; if the verification fails, it stops. The specific operating steps for S2 are as follows: S2.1: The cloud server reads the authentication materials submitted by drone A and drone B during the registration phase, specifically including drone A's long-term public key. and short-term public keys The long-term public key of drone B and short-term public keys ; S2.2: Cloud servers use their own long-term private keys. right The hash digest value is used to sign the result to obtain the signature. : S2.3: Cloud servers use their own long-term private keys. right The hash digest value is used to sign the result to obtain the signature. : S2.4: The cloud server will respond with the long-term and short-term public keys of node drone B. and and his own signature , Send it together to drone A, which is the requesting node; S2.5: After receiving the authentication materials and signature sent by the cloud server, Drone A uses... Verify signature Determine the validity of the message: in, This is the long-term public key for the cloud server; If the verification passes, proceed to the next step; if the verification fails, stop. S3: Drone A calculates the session key, generates a new short-term public-private key pair, and updates the short-term public key to the cloud server. The cloud server verifies the short-term public key. If the verification is successful, the old short-term public key is updated to the new short-term public key. If the verification fails, it is discarded. S4: Drone A sends a message request to Drone B. Drone B verifies whether the message is fresh. If the message is fresh, it proceeds to the next step. If it is not fresh, it stops. S5: Drone B calculates the session key, generates a new short-term public-private key pair, and updates the short-term public key to the cloud server; the cloud server verifies the short-term public key. If the verification is successful, the old short-term public key is updated to the new short-term public key; if the verification fails, it is discarded.

2. The method for establishing end-to-end secure communication for unmanned aerial vehicles under a cloud-network-terminal architecture as described in claim 1, characterized in that, The cloud server is a high-performance computing and storage cloud platform. As a control center, it is responsible for planning missions for registered drones and providing security services for them. When a specific mission requires multiple drones to collaborate, the cloud server not only plans the flight missions and collaborating objects for the end nodes, but also establishes end-to-end secure connections between the collaborating parties to ensure secure communication between the end nodes.

3. The method for establishing end-to-end secure communication for unmanned aerial vehicles under a cloud-network-device architecture as described in claim 1, characterized in that, The specific operating steps for S3 are as follows: S3.1: Drone A generates a temporary public-private key pair. It uses the Diffie-Hellman algorithm and the long-term public key of drone B. Short-term public keys and your long-term private key Temporary private key Calculate the intermediate value of the session key: , , ; S3.2: Drone A uses the key derivation function KDF and the result calculated in the previous step... , , Calculate session key : ; S3.3: Drone A obtains the current timestamp Use long-term private key right Sign the hash digest to obtain : S3.4: Drone A generates a new short-term public-private key pair. Use your own long-term private key right Obtain by signing : S3.5: Drone A will and signature After successfully sending to the cloud server, delete the old short-term public / private key pair. and the current temporary public / private key pairs ; The cloud server received a new short-term public key from drone A. and signature Then, use the long-term public key of drone A. For signature Verification required: If the verification passes, the old short-term public key will be transferred. Update to the new short-term public key If the verification fails, the data will be discarded.

4. The method for establishing end-to-end secure communication for unmanned aerial vehicles under a cloud-network-terminal architecture as described in claim 3, characterized in that, The specific operating steps for S4 are as follows: S4.1: Drone A will send its long-term public key Temporary public key timestamp and signature and Send it to drone B together; S4.2: Drone B, acting as the responding endpoint, receives the request message from Drone A and first sets the timestamp in the request message... With current timestamp In comparison, For the preset tolerable time delay, if If the message is fresh, proceed to the next step; otherwise, stop. S4.3: Drone B uses the long-term public key of the cloud server. For signature To determine the validity: If verification fails, stop; if verification succeeds, use drone A's long-term public key. For signature To determine the validity: If the verification fails, stop; if the verification succeeds, proceed to the next step.

5. The method for establishing end-to-end secure communication for unmanned aerial vehicles under a cloud-network-terminal architecture as described in claim 4, characterized in that, The specific operating steps for S5 are as follows: S5.1: Drone B uses the Diffie-Hellman algorithm and Drone A's long-term public key. Temporary public key and your long-term private key Short-term private key Calculate the intermediate value of the session key: , , ; S5.3: Drone B uses the key derivation function KDF and the result calculated in the previous step... , , Calculate session key : ; S5.4: Drone B generates a new short-term public-private key pair. Use your own long-term private key right Obtain by signing : S5.4: After drone B resumes network communication with the cloud server, it updates its short-term public key. and signature After successfully sending to the cloud server, delete the old short-term public / private key pair. ; S5.5: The cloud server receives a new short-term public key from drone B. and signature Then, use the long-term public key of drone B. For signature Verification required: If the verification passes, the old short-term public key will be transferred. Update to the new short-term public key If the verification fails, the data will be discarded.