A method for transmitting and receiving flight data, a method for announcing, a method for receiving, and a computing device
By using an asymmetric encryption algorithm for signature verification and a public key verification mechanism based on a product certificate database, the problem of data tampering in UAV flight data notification schemes is solved, and secure and reliable flight data transmission is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- WEBRAY TECH BEIJING CO LTD
- Filing Date
- 2025-11-11
- Publication Date
- 2026-04-14
AI Technical Summary
In existing drone flight data notification schemes, the plaintext flight data is easily tampered with, and the encryption and decryption process is difficult to apply when the communicating parties do not know each other's identities in advance, resulting in security difficulties.
An asymmetric encryption algorithm is used to implement the signature verification mechanism. The notifying party generates a signature value using its private key and broadcasts the data. The receiving party verifies the signature value using its public key to ensure data security. The public key is stored in a product certificate database and its credibility is verified through a certificate chain.
It achieves both convenience and security in drone flight data transmission, preventing data tampering and ensuring the integrity and reliability of data transmission.
Smart Images

Figure CN121099311B_ABST
Abstract
Description
Technical Field
[0001] The embodiments in this specification belong to the field of data processing technology, and more specifically, relate to a method for transmitting and receiving flight data, a notification method, a receiving method, and a computing device. Background Technology
[0002] Drones broadcasting flight data is a fundamental means of achieving low-altitude safety supervision. Flight data can include flight status such as position, altitude, and heading. By sharing flight data in real time, mid-air collisions can be effectively avoided and airspace management can be assisted.
[0003] In existing technologies, methods for broadcasting flight data by drones can be broadly categorized into two types: reporting and notification.
[0004] The reporting scheme involves both parties knowing each other's identities in advance. The reporting party pre-sets a key pair and sends the public key used for decryption to the receiving party. When reporting flight data, the reporting party uses the private key to encrypt the flight data and then broadcasts the encrypted flight data to a preset frequency band. Since the public key is held only by the receiving party, even if the encrypted flight data can be obtained by any unit monitoring the frequency band, only the receiving party pre-designated by the reporting party can decrypt it correctly. Therefore, it can be regarded as the reporting party reporting the flight data to the receiving party.
[0005] The notification scheme is a communication scheme in which the two parties do not know each other's identities in advance. Therefore, in order to ensure that the receiver can correctly obtain the flight data of the notifying party, the notifying party needs to broadcast its own flight data in plaintext on a preset frequency band. Correspondingly, the receiver can directly obtain the flight data of the notifying party by listening to the preset frequency band. That is, any unit listening to the frequency band can obtain the flight data in plaintext.
[0006] As can be seen from the notification scheme's process, flight data broadcast in plaintext is highly susceptible to tampering and exploitation by attackers, making the process's security difficult to guarantee. However, when the communicating parties are unaware of each other's identities beforehand, the encryption and decryption processes in the reporting scheme are difficult to apply to the notification scheme.
[0007] Therefore, there is an urgent need for a technical solution to announce flight data, in order to at least partially solve the above-mentioned technical problems. Summary of the Invention
[0008] The embodiments in this specification aim to provide a method for transmitting and receiving flight data, a notification method, a receiving method, and a computing device.
[0009] This specification provides a method for transmitting and receiving flight data, the method including an announcement phase and a reception phase;
[0010] The notification phase includes:
[0011] The notifying party determines its own flight status, wherein the notifying party is the aircraft;
[0012] The notifying party uses its private key and the data to be transmitted to determine a signature value, wherein the data to be transmitted includes at least the flight status and the notifying party's unique product identification code.
[0013] The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value;
[0014] The notifying party will broadcast the data to be broadcast to a preset frequency band;
[0015] The receiving phase includes:
[0016] The receiver obtains the data to be verified from the preset frequency band, and the data to be verified has the same data structure as the data to be broadcast.
[0017] The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted.
[0018] In some embodiments, the receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted, specifically including:
[0019] The receiver determines the public key corresponding to the data to be verified based on the unique product identification code in the data to be verified.
[0020] The receiver uses the public key to decrypt the signature value in the data to be verified to obtain the decryption result. If the decryption result matches the data to be transmitted in the data to be verified, the data to be verified is determined to be secure data.
[0021] In some embodiments, the notifying party determines the signature value using its private key and the data to be transmitted, specifically including:
[0022] The notifying party processes the data to be transmitted using a target hash algorithm to obtain a first hash value;
[0023] The notifying party uses its own private key to encrypt the first hash value to obtain the signature value;
[0024] The receiver uses the public key to decrypt the signature value in the data to be verified, obtaining a decryption result. If the decryption result matches the data to be transmitted in the data to be verified, the data to be verified is determined to be secure data. Specifically, this includes:
[0025] The receiver uses the public key to decrypt the signature value in the data to be verified to obtain a decryption result; and uses the target hash algorithm to process the data to be transmitted in the data to be verified to obtain a second hash value; if the decryption result is the same as the second hash value, the data to be verified is determined to be secure data.
[0026] In some embodiments, the flight state specifically includes at least one of the following: aircraft position, aircraft speed, aircraft attitude, and current time.
[0027] In some embodiments, the notifying party determines the data to be broadcast based on the data to be transmitted and the signature value, specifically including:
[0028] The notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the message sequence number;
[0029] After the receiver obtains the data to be verified from the preset frequency band, the method further includes:
[0030] If the message sequence number in the data to be verified is the same as the message sequence number in any historical data received by the receiver in the current time period, and the data to be verified and the unique product identification code in the historical data are the same, the data to be verified is determined to be redundant data.
[0031] In some embodiments, a product certificate database is also involved, which includes a plurality of unique product identifiers for aircraft and a public key corresponding to each unique product identifier;
[0032] Based on the unique product identification code in the data to be verified, the public key corresponding to the data to be verified is determined, specifically including:
[0033] Based on the unique product identification code in the data to be verified, a search is performed in the product certificate database to determine the public key corresponding to the data to be verified.
[0034] In some embodiments, a product certificate database is also involved, which includes a number of unique product identification codes for aircraft and a certificate chain corresponding to each unique product identification code. The certificate chain includes a primary certificate and a secondary certificate. For any aircraft, the primary certificate is obtained by encrypting the public key of the aircraft and the unique product identification code using the private key of the identification code issuing authority corresponding to the aircraft. The secondary certificate is obtained by encrypting the public key of the identification code issuing authority corresponding to the aircraft and the issuing authority number using the private key of the certification authority.
[0035] The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value, specifically including:
[0036] The notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the issuing authority number;
[0037] The receiver determines the public key corresponding to the data to be verified based on the unique product identification code in the data to be verified, specifically including:
[0038] The receiver searches the product certificate database based on the unique product identification code in the data to be verified to determine the certificate chain corresponding to the data to be verified.
[0039] The certificate chain of the data to be verified is verified using the public key of the certification authority.
[0040] If, during the verification process, the issuing authority number in the secondary certificate is the same as the issuing authority number in the data to be verified, and the unique product identifier in the primary certificate is the same as the unique product identifier in the data to be verified, then the public key in the primary certificate will be used as the public key corresponding to the data to be verified.
[0041] A second aspect of this specification provides a method for notifying flight data, the method comprising:
[0042] The notifying party determines its own flight status, wherein the notifying party is the aircraft;
[0043] The notifying party uses its private key and the data to be transmitted to determine a signature value, wherein the data to be transmitted includes at least the flight status and the notifying party's unique product identification code.
[0044] The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value;
[0045] The notifying party will broadcast the data to be broadcast to a preset frequency band.
[0046] A third aspect of this specification provides a method for receiving flight data, the method comprising:
[0047] The receiver obtains the data to be verified from a preset frequency band. The data to be verified is determined based on the data to be transmitted by the corresponding aircraft and a signature value. The signature value is determined based on the private key of the corresponding aircraft and the data to be transmitted. The data to be transmitted is determined based on the flight status of the corresponding aircraft and a unique product identification code.
[0048] The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted.
[0049] A fourth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method as described in any one of the first, second, or third aspects.
[0050] This specification provides a computing device in a fifth aspect, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method as described in any one of the first, second, or third aspects.
[0051] A sixth aspect of this specification provides a computer program product including a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any one of the first, second, or third aspects.
[0052] The solution provided in the embodiments of this specification utilizes a signature verification mechanism to implement a flight data notification scheme, which can simultaneously meet the needs of convenience and security in flight data transmission, providing a feasible solution for flight data transmission. Attached Figure Description
[0053] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0054] Figure 1 This is a schematic diagram illustrating the reporting and notification schemes provided in this manual;
[0055] Figure 2 This is a flowchart illustrating a method for transmitting and receiving flight data in one embodiment of this specification;
[0056] Figure 3 This is a schematic diagram of a process for constructing a certificate chain in one embodiment of this specification;
[0057] Figure 4 This is a flowchart illustrating a method for notifying flight data with the notifying party as the executing entity, according to one embodiment of this specification.
[0058] Figure 5 This is a flowchart illustrating a method for receiving flight data with the receiver as the executing entity, as described in one embodiment of this specification. Detailed Implementation
[0059] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.
[0060] The above first introduces the technical terms used in this manual:
[0061] Asymmetric encryption algorithms: Asymmetric encryption algorithms utilize a pair of keys. This pair consists of a private key and a public key, which are used for encryption and decryption respectively (depending on the task, encryption can be performed using the private key and decryption using the public key, or vice versa). The private and public keys are mathematically related, but the other cannot be obtained by observing one. Typically, the key generator keeps the private key secret while publishing the public key to enable encrypted data transmission or signature verification. Commonly used asymmetric encryption algorithms include: Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic Curve Digital Signature Algorithm (ECDSA), SM2, etc.
[0062] Unique Product Identifier (UBI): A coding system used to uniquely identify a type of product, widely used in commodity circulation, financial supervision, equipment traceability, and other fields. For the drone industry, there are already clearly defined and standardized coding methods and structures, ensuring that the UPI uniquely identifies each drone. The UPI for a drone consists of 20 characters, including: a 4-digit manufacturer code, a 4-digit product model code, and a 12-digit product serial number. The coded characters are numbers and letters (excluding easily confused "O" and "I").
[0063] The process of broadcasting flight data from unmanned aerial vehicles (UAVs) involves two main participants: the broadcaster (in the reporting scheme, the broadcaster is also the reporter; in the notification scheme, the broadcaster is also the notifier) and the receiver. In practical applications, the broadcaster is the UAV in flight, while the receiver can be other UAVs in flight or ground units such as ground control stations (GCS). This manual does not impose specific restrictions on the receiver.
[0064] In real-world aerial operations, the units that need to know the flight status of a particular aircraft include not only ground units with relatively fixed identities, but also other aircraft in the airspace. Furthermore, before aerial operations commence, it is difficult for the aircraft to know each other's identities; that is, for the broadcaster, the identity of the receiver is unknown.
[0065] Based on the above scenarios Figure 1 The diagram illustrates the processes of the reporting and notification schemes. As shown, the receivers can include both aircraft and ground units. In the reporting scheme, the receiver can only be a ground unit. The aircraft, acting as the reporter, shares its public key with the communication platform beforehand. It can then use its private key to encrypt flight data and broadcast the encrypted flight data. The ground unit can then obtain the encrypted flight data broadcast by the reporter and decrypt it to obtain the correct flight status. In the notification scheme, the receiver can be either a ground unit or an aircraft. The broadcaster broadcasts the plaintext flight data to a preset frequency band, and the receiver can obtain the broadcaster's flight data in real time by monitoring this frequency band.
[0066] It should be noted that in the reporting scheme, the reporting party broadcasts encrypted flight data to a preset frequency band. This encrypted flight data can be obtained by any entity monitoring that frequency band, but only the recipient holding the public key can correctly decrypt it (equivalent to the reporting party only being able to transmit flight data to a pre-identified recipient). In the notification scheme, the notifying party broadcasts flight data in plaintext to a preset frequency band. This plaintext flight data can be obtained by any recipient monitoring that frequency band.
[0067] Depend on Figure 1 As can be seen, the current reporting scheme can only achieve one-way transmission from the aircraft to the ground unit. Faced with the technical problem to be solved in this embodiment (the aircraft broadcasts flight data to units of any location and identity), the reporting scheme is difficult to meet the requirements.
[0068] On the other hand, the notification scheme in the existing technology also has its shortcomings. Since the notifying party broadcasts its own flight data in plaintext in this scheme, the flight data in plaintext is very easy for attackers to tamper with or impersonate, and the integrity of the data is difficult to guarantee. In the face of flight data forged by attackers, the receiving party also lacks the means to distinguish it. Therefore, the security of directly broadcasting flight data in plaintext is difficult to meet the security requirements in actual use scenarios.
[0069] Based on the problems existing in the prior art, this embodiment provides a method for transmitting and receiving flight data. The method in this embodiment is an improvement on the notification scheme of the prior art, and uses an asymmetric encryption algorithm to implement a signature verification mechanism, thereby providing security guarantee for the broadcast of flight data.
[0070] Figure 2 This specification illustrates a flowchart of a method for transmitting and receiving flight data according to one embodiment. The method may include an announcement phase and a receiving phase. The announcement phase can be performed by the announcing party, and the receiving phase can be performed by the receiving party. It should be noted that in practical applications, the announcing party may only perform the steps corresponding to the announcement phase when there is a need to broadcast flight data; while the receiving party needs to continuously monitor a preset frequency band, and when it detects data to be verified in the expected format, it performs the steps corresponding to the receiving phase.
[0071] Before introducing each step, it is important to first clarify that, in cases such as Figure 2 In the method shown, the notifying party may be unaware of all information about the recipients—including the number and identity of the recipients; correspondingly, the recipients may also be unaware of all information about the notifying party—including the number and identity of the notifying parties. To ensure... Figure 2 For the method shown to be implemented correctly, the notifying party and the receiving party need to have a certain consensus (or this consensus can be understood as a pre-determined protocol) on the data structure of the flight data used for broadcasting. That is, the receiving party needs to know the data structure of the flight data broadcast by the notifying party to ensure that the receiving party can identify the notifying party's flight data without missing it.
[0072] For example, a pre-defined data structure for the flight data used for broadcasting can be established. The limitations of this data structure may include, but are not limited to, the total length of the flight data and the flight status category represented by each character position within the flight data. Thus, the receiver can correctly interpret the flight status of the broadcaster upon receiving the flight data.
[0073] It should be noted that, in this embodiment, depending on the perspective, the flight data used for broadcasting can be referred to as data to be broadcast (from the perspective of the announcing party) or data to be verified (from the perspective of the receiving party).
[0074] Next, we will first introduce the notification phase, which includes the following steps:
[0075] Step S201: The notifying party determines its own flight status, wherein the notifying party is the aircraft.
[0076] In this embodiment, the timing of broadcasting flight data can be determined by the notifying party. For example, the notifying party can execute the steps corresponding to the notification phase (steps S201-S207) according to a preset broadcast interval, or it can execute the steps corresponding to the notification phase at specific task nodes according to the flight mission it is performing. This specification does not impose any restrictions here.
[0077] Specifically, in step S201, the notifying party can base its notification on the current operating status of its deployed control system and / or the output parameters of its deployed sensors. In some implementations, this flight status may include at least one of the following: aircraft position, aircraft speed, aircraft attitude, and the current time.
[0078] Step S203: The notifying party uses its private key and the data to be transmitted to determine a signature value, wherein the data to be transmitted includes at least the flight status and the notifying party's unique product identification code.
[0079] After determining the flight status, the notifying party can determine the data to be transmitted based on the flight status. This data may include the notifying party's identity information in addition to the flight status. In some implementations, the notifying party's identity information may be its unique product identifier.
[0080] Typically, the identity information and flight status of the notifying party are arranged into data to be transmitted, which can be achieved by concatenating the strings corresponding to the flight status and identity information respectively.
[0081] Once the data to be transmitted is determined, the notifying party can use its private key and the data to be transmitted to determine the signature value. It should be noted that the notifying party needs to have a key pair generated according to an asymmetric encryption algorithm, and the private key used in step S203 is the private key of this key pair; on the other hand, the public key of this key pair can be made public for use in the receiving phase.
[0082] Based on the characteristics of asymmetric encryption algorithms, ciphertext encrypted with the private key of a key pair can only be correctly decrypted using the public key of the same key pair. Therefore, in this embodiment, this feature is used to implement a signature verification mechanism for flight data. In some implementations, the private key can be used to directly encrypt the data to be transmitted to obtain a signature value; in other implementations, the string at a predetermined position in the data to be transmitted can be encrypted—for example, for a 100-character data to be transmitted, the string consisting of characters 20-50 can be encrypted.
[0083] Therefore, the encrypted result is the signature value. In the subsequent receiving stage, the receiver uses the public key in the key pair to decrypt the signature value. Theoretically, the decryption result should be the same as the encrypted object of the private key (for example, if the string consisting of characters 20-50 in the data to be transmitted is encrypted in step S203, the decryption result should also be the string consisting of characters 20-50 in the data to be transmitted). Thus, if an attacker tampers with the data to be transmitted, the receiver can verify the signature value by decrypting it. Furthermore, since the private key is kept secret by the notifying party, it is difficult for an attacker to forge and generate a signature value. This process can be called the signature verification process.
[0084] In practical applications, a typical key pair for an aircraft can be generated by the aircraft manufacturer or an identification code issuing authority that issues a unique product identification code to the aircraft. The private key in this key pair can also be placed into the aircraft's computing device after generation. The identification code issuing authority can be either the manufacturer or an inspection agency that performs factory inspections on the aircraft; this will not be elaborated upon here.
[0085] Step S205: The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value.
[0086] After determining the signature value, the notifying party can concatenate the string corresponding to the data to be transmitted with the string corresponding to the signature value to obtain the data to be broadcast.
[0087] It should be noted that in step S205, the data to be transmitted can be in plaintext form. That is, in this embodiment, no additional encryption means are required; the anti-tampering mechanism for the data to be transmitted can be achieved simply by attaching a signature value to the data to be broadcast.
[0088] Step S207: The notifying party broadcasts the data to be broadcast to a preset frequency band.
[0089] Once the data to be broadcast is determined, the notifying party can broadcast the data to the preset frequency band.
[0090] As mentioned above, the notifying party and the receiving party must also have a certain consensus on the frequency band used for broadcasting. In step S207, the frequency band used to broadcast the data to be broadcast must be the same as the frequency band used to obtain the data to be verified in subsequent steps. In this embodiment, this same frequency band is referred to as the preset frequency band.
[0091] In summary, the notifying party completes the notification phase by executing steps S201-S207. In this embodiment, a notification scheme is used to realize data transmission between the notifying party and the receiving party. As can be seen from the previous introduction of the notification scheme, the execution of the notification phase does not depend on the notifying party and the receiving party knowing each other's identities in advance or the notifying party sharing its own key with the receiving party, which can meet the convenience requirements in practical application scenarios.
[0092] Next, the receiving phase will be described, which includes:
[0093] Step S209: The receiver obtains the data to be verified from the preset frequency band. The data to be verified has the same data structure as the data to be broadcast.
[0094] First, the identity of the receivers is explained. As mentioned earlier, the announcing party and the receivers need to have a certain consensus on the frequency band used for broadcasting. From another perspective, any ground unit or aircraft that has a consensus with the announcing party regarding the preset frequency band can act as a receiver. That is, during step S207, any unit that maintains monitoring of the preset frequency band can act as a receiver. The announcing party does not need to know the number or identity information of the receivers, and this specification does not impose any restrictions here.
[0095] Specifically, for the same flight data (i.e., the data to be broadcast in step S207 and the data to be verified in step S209 are the same data), step S209 is executed after step S207. However, the execution condition for step S209 is not only the completion of step S207. In practical application scenarios, to ensure that no possible flight data is missed, the receiver needs to continuously monitor the preset frequency band. When data conforming to the preset data structure is detected, that data is taken as data to be verified. That is, the actual execution condition for step S209 is that the receiver detects data conforming to the preset data structure. In practical application scenarios, there may be situations where attackers attempt to forge flight data and broadcast it. In such cases, if the forged flight data conforms to the preset data structure, step S209 can also be triggered.
[0096] Step S211: The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted.
[0097] Once the recipient obtains the data to be verified, they can use the signature verification mechanism to verify the security of the data.
[0098] Specifically, as mentioned above, since the notifying party has publicly disclosed the public key of its key pair, and the data to be verified contains the notifying party's identity information, and furthermore, the notifying party and the receiving party can reach a consensus on the encrypted object used to determine the signature value, the receiving party can obtain the notifying party's public key through this identity information, decrypt the signature value using this public key, and compare the decryption result with the string at the corresponding position in the encrypted object of the data to be verified. If the decryption result matches the string at the corresponding position, then the data to be verified can be considered untampered, i.e., the data to be verified is secure.
[0099] In some implementations, when the identity information includes a unique product identification code, the receiver determines the public key corresponding to the data to be verified based on the unique product identification code in the data to be verified. The receiver uses the public key to decrypt the signature value in the data to be verified to obtain a decryption result. If the decryption result matches the data to be transmitted in the data to be verified, the data to be verified is determined to be secure data.
[0100] Furthermore, in some implementations, a product certificate database can be pre-established, which includes unique product identifiers for several aircraft and a public key corresponding to each unique product identifier. Then, in step S211, the product certificate database is searched based on the unique product identifier in the data to be verified to determine the public key corresponding to the data to be verified.
[0101] Therefore, as long as the notifying party's unique product identifier and public key are included in the product certificate database, the receiving party only needs to know the address of the product certificate database to easily obtain the notifying party's public key. This product certificate database can be maintained by a third party other than the notifying party and the receiving party. Thus, through the product certificate database, the notifying party and the receiving party do not need to know each other beforehand, nor do they need to provide their own storage space, to achieve the sending and receiving of flight data.
[0102] It should be noted that for any aircraft, only one registration in the product certificate database is required (that is, storing the aircraft's unique product identifier and public key in the product certificate database). After registration, the aircraft can perform any number of operations at any time after registration. Figure 2 The notification phase is shown. In this embodiment, the aircraft registration process and the flight data transmission and reception process are completely decoupled. Compared with the existing technology that directly uses plaintext state for flight data broadcasting, no additional process is added in the broadcast phase.
[0103] In summary, the receiver completes the notification phase by executing steps S209-S211. This embodiment utilizes a signature verification mechanism based on a signature value to ensure the immutability of the flight status while transmitting it in plaintext. This satisfies the security requirements of flight data transmission.
[0104] like Figure 2 The method for transmitting and receiving flight data shown utilizes a signature verification mechanism, which can simultaneously meet the needs of convenience and security in flight data transmission, providing a feasible solution for flight data transmission.
[0105] In addition, to improve the computational efficiency of the signature value generation process and subsequent verification process, this embodiment may not directly encrypt the data to be transmitted, but instead encrypt the message digest of the data to be transmitted.
[0106] In some implementations, in step S203, the notifying party processes the data to be transmitted using a target hash algorithm to obtain a first hash value. The notifying party then encrypts the first hash value using its private key to obtain a signature value. Subsequently, in step S211, the receiving party decrypts the signature value in the data to be verified using the public key to obtain a decryption result; and processes the data to be transmitted in the data to be verified using the target hash algorithm to obtain a second hash value. If the decryption result is the same as the second hash value, the data to be verified is determined to be secure data.
[0107] Specifically, the message digest can be obtained by processing the data to be transmitted using a target hash algorithm. That is, the first hash value and the second hash value can be regarded as the message digest mentioned above. Since the length of the message digest is usually less than the length of Yuan Shu's data to be transmitted, it is faster to encrypt the first hash value with the private key and decrypt the second hash value with the public key, which can improve the overall implementation efficiency of this embodiment.
[0108] The target hash algorithm can be any commonly used hash algorithm, such as the MD series algorithms (MD-5, MD-4, etc.), the SHA series algorithms (SHA-256, SHA-512, etc.), the SM3 algorithm, etc. This specification does not impose any restrictions.
[0109] Of course, the message digest can also be obtained by processing the string at a preset position in the data to be transmitted using the target hash algorithm. The subsequent encryption to obtain the signature value and the decryption of the signature value to verify the data will not be described in detail in this embodiment.
[0110] In addition, to defend against replay attacks, the data to be broadcast may also include the message sequence number corresponding to that data. In some implementations, such as... Figure 2In step S205, the notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the message sequence number. Furthermore, in... Figure 2 After step S209, if the message sequence number in the data to be verified is the same as the message sequence number in any historical data received by the receiver in the current time period, and the data to be verified and the unique product identification code in the historical data are the same, the data to be verified is determined to be redundant data.
[0111] Specifically, a replay attack occurs when an attacker intercepts the broadcast data from the announcing party and repeatedly broadcasts the same data to achieve an effect similar to a Denial of Service (DoS) attack. Therefore, the receiver can preset a time period length, using the time period up to the current moment as the current time period. If a message with the same sequence number from the same announcing party has been received within the current time period, any newly received data with the same sequence number from that announcing party is considered redundant, and the current time period will not continue to process the redundant data. Since the message sequence number is in plaintext, comparing the plaintext sequence number is rapid, greatly reducing the receiver's computational cost when facing a replay attack.
[0112] The previous section described one implementation of a product certificate database. In this implementation, the database directly stores the unique product identifier (BID) and its corresponding public key for each aircraft. Typically, the process of registering the unique BID and public key in the product certificate database is performed by the BID issuing authority. In other words, the authenticity and trustworthiness of the public key in the product certificate database entirely depend on the guarantee of the BID issuing authority.
[0113] Therefore, to ensure that the public keys in the product certificate database have higher credibility, Figure 3 This diagram illustrates a flowchart of a certificate chain construction process according to one embodiment of this specification. In some implementations, when performing... Figure 2 Before the method shown, such as Figure 3The certification authority (CA) can generate its own key pair—a private key and a public key. Furthermore, for any identification code issuing authority (ICA), the ICA can generate its own key pair—a private key and a public key; the ICA can transmit its public key and issuing authority number to the CA. The CA can then use its private key to encrypt the ICA's public key and issuing authority number to obtain the corresponding secondary certificate. Further, for any aircraft with a unique product identification code issued by the ICA, the aircraft's key pair is generated by the manufacturer or the ICA. The private key in the key pair is stored in the aircraft's computing device, and the public key and the aircraft's unique product identification code are encrypted using the ICA's private key to obtain the corresponding primary certificate. Thus, each aircraft can possess its own primary certificate and a corresponding secondary certificate from the ICA, forming the aircraft's certificate chain.
[0114] Therefore, the product certificate repository can store the unique product identifier for each aircraft and the corresponding certificate chain for each unique product identifier. Furthermore, the data to be broadcast can also include the issuing authority code of the notifying party's unique product identifier, such as... Figure 2 In step S205, as shown, the notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the issuing authority number. Next, in... Figure 2 In step S211, the receiver searches the product certificate database based on the unique product identifier in the data to be verified to determine the certificate chain corresponding to the data to be verified. The receiver then uses the public key of the certification authority to verify the certificate chain of the data to be verified. If, during the verification process, the issuing authority number in the secondary certificate is the same as the issuing authority number in the data to be verified, and the unique product identifier in the primary certificate is the same as the unique product identifier in the data to be verified, the public key in the primary certificate is used as the public key corresponding to the data to be verified.
[0115] Specifically, the recipient first obtains the certification authority's public key and uses it to decrypt the secondary certificate in the certificate chain. If the issuing authority code in the secondary certificate decryption result matches the issuing authority code in the data to be verified, the first layer of verification passes. After passing the first layer of verification, the recipient continues to use the public key from the secondary certificate decryption result to decrypt the primary certificate. If the unique product identifier in the secondary certificate decryption result matches the unique product identifier in the data to be verified, the second layer of verification passes. After passing the second layer of verification, the public key in the primary certificate decryption result becomes the public key of the notifying party.
[0116] In this embodiment, a trustworthy traceability mechanism for the aircraft's public key is achieved through the construction of a certificate chain and subsequent verification of the corresponding certificate chain. If either the first or second layer of verification fails during the verification process, the aircraft's public key is untrustworthy, thereby increasing the trustworthiness of the aircraft's public key that has passed verification.
[0117] In addition, to support more diverse data transmission needs, a specific implementation of a flight data structure is given below. A single flight data entry may include a structure identifier, current time, aircraft position, unique product identifier, serial number, signature value, issuing authority number, and other status signals. These other status signals may include aircraft speed, aircraft attitude, or aircraft equipment status, etc.
[0118] The structure identifier can be a single character, and different values of the character indicate which data structure the receiver should use to interpret the flight data. For example, depending on the value of the structure identifier, the character corresponding to the current time can be located at either the beginning or the end of the flight data string; or, depending on the value of the structure identifier, a flight data may or may not include other status signals.
[0119] Therefore, the notifying party can use different data formats to determine the data to be broadcast according to its own needs, adapting to the data transmission requirements in different scenarios.
[0120] Figure 4 This specification illustrates a flowchart of a flight data notification method with the notifying party as the executing entity, according to an embodiment of the present specification. The method includes:
[0121] Step S401: The notifying party determines its own flight status, wherein the notifying party is the aircraft.
[0122] The specific implementation method of this step can be referred to the description of step S201 in the previous text.
[0123] Step S403: The notifying party uses its private key and the data to be transmitted to determine a signature value, wherein the data to be transmitted includes at least the flight status and the notifying party's unique product identification code.
[0124] The specific implementation method of this step can be referred to the description of step S204 in the previous text.
[0125] Step S405: The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value.
[0126] The specific implementation method of this step can be referred to the description of step S205 in the previous text.
[0127] Step S407: The notifying party broadcasts the data to be broadcast to a preset frequency band.
[0128] The specific implementation method of this step can be referred to the description of step S207 in the previous text.
[0129] in addition, Figure 5 This specification shows a flowchart illustrating a method for notifying flight data with the recipient as the executing entity, according to an embodiment of the present specification. The method includes:
[0130] Step S501: The receiver obtains the data to be verified from the preset frequency band, wherein the data to be verified is determined based on the data to be transmitted by the corresponding aircraft and the signature value, and the signature value is determined based on the private key of the corresponding aircraft and the data to be transmitted; the data to be transmitted is determined based on the flight status of the corresponding aircraft and the unique product identification code.
[0131] The specific implementation method of this step can be referred to the description of step S209 in the previous text.
[0132] Step S503: The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted.
[0133] The specific implementation method of this step can be referred to the corresponding description of step S211 in the previous text.
[0134] It should also be noted that the terms "unmanned aerial vehicle," "aircraft," and "drone" used in this manual are all different names for the same concept.
[0135] It should be understood that the descriptions such as "first" and "second" in this article are merely for the sake of simplicity in description and to distinguish similar concepts, and do not have any other limiting function.
[0136] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.
[0137] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0138] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. The software modules can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.
[0139] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for transmitting and receiving flight data, characterized in that, The method involves a product certificate database, which includes unique product identification codes for several aircraft and a certificate chain corresponding to each unique product identification code. The certificate chain includes a primary certificate and a secondary certificate. For any aircraft, the primary certificate is obtained by encrypting the public key of the aircraft and the unique product identification code using the private key of the issuing authority corresponding to the aircraft's identification code. The secondary certificate is obtained by encrypting the public key of the issuing authority corresponding to the aircraft's identification code and the issuing authority number using the private key of the certification authority. The issuing authority is the aircraft manufacturer or inspection agency. The method includes a notification stage and a receiving stage. The notification phase includes: The notifying party determines its own flight status, wherein the notifying party is the aircraft; The notifying party uses its private key and the data to be transmitted to determine a signature value, wherein the data to be transmitted includes at least the flight status and the notifying party's unique product identification code. The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value; The notifying party will broadcast the data to be broadcast to a preset frequency band; The receiving phase includes: The receiver obtains the data to be verified from the preset frequency band, and the data to be verified has the same data structure as the data to be broadcast. The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted. Specifically, the notifying party determines the data to be broadcast based on the data to be transmitted and the signature value, including: The notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the issuing authority number; The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted, specifically including: The receiver searches the product certificate database based on the unique product identification code in the data to be verified to determine the certificate chain corresponding to the data to be verified. The certificate chain of the data to be verified is verified using the public key of the certification authority. If, during the verification process, the issuing authority number in the secondary certificate is the same as the issuing authority number in the data to be verified, and the unique product identifier in the primary certificate is the same as the unique product identifier in the data to be verified, then the public key in the primary certificate will be used as the public key corresponding to the data to be verified. The receiver uses the public key to decrypt the signature value in the data to be verified to obtain the decryption result. If the decryption result matches the data to be transmitted in the data to be verified, the data to be verified is determined to be secure data.
2. The method as described in claim 1, characterized in that, The notifying party uses its private key and the data to be transmitted to determine the signature value, specifically including: The notifying party processes the data to be transmitted using a target hash algorithm to obtain a first hash value; The notifying party uses its own private key to encrypt the first hash value to obtain the signature value; The receiver uses the public key to decrypt the signature value in the data to be verified, obtaining a decryption result. If the decryption result matches the data to be transmitted in the data to be verified, the data to be verified is determined to be secure data. Specifically, this includes: The receiver uses the public key to decrypt the signature value in the data to be verified to obtain a decryption result; and uses the target hash algorithm to process the data to be transmitted in the data to be verified to obtain a second hash value; if the decryption result is the same as the second hash value, the data to be verified is determined to be secure data.
3. The method as described in claim 1, characterized in that, The flight status specifically includes at least one of the following: aircraft position, aircraft speed, aircraft attitude, and current time.
4. The method as described in claim 1, characterized in that, The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value, specifically including: The notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the message sequence number; After the receiver obtains the data to be verified from the preset frequency band, the method further includes: If the message sequence number in the data to be verified is the same as the message sequence number in any historical data received by the receiver in the current time period, and the data to be verified and the unique product identification code in the historical data are the same, the data to be verified is determined to be redundant data.
5. The method as described in claim 1, characterized in that, It also involves a product certificate database, which includes a number of unique product identifiers for aircraft and a public key corresponding to each unique product identifier; Based on the unique product identification code in the data to be verified, the public key corresponding to the data to be verified is determined, specifically including: Based on the unique product identification code in the data to be verified, a search is performed in the product certificate database to determine the public key corresponding to the data to be verified.
6. A method for notifying flight data, characterized in that, The method involves a product certificate database, which includes unique product identifiers for several aircraft and a certificate chain corresponding to each unique product identifier. The certificate chain includes a primary certificate and a secondary certificate. For any aircraft, the primary certificate is obtained by encrypting the aircraft's public key and unique product identifier using the private key of the issuing authority corresponding to the aircraft's identifier. The secondary certificate is obtained by encrypting the public key of the issuing authority corresponding to the aircraft's identifier and the issuing authority's number using the private key of the certification authority. The issuing authority is the aircraft manufacturer or inspection agency. The method includes: The notifying party determines its own flight status, wherein the notifying party is the aircraft; The notifying party uses its private key and the data to be transmitted to determine a signature value, wherein the data to be transmitted includes at least the flight status and the notifying party's unique product identification code. The notifying party determines the data to be broadcast based on the data to be transmitted and the signature value; The notifying party will broadcast the data to be broadcast to a preset frequency band; Specifically, the notifying party determines the data to be broadcast based on the data to be transmitted and the signature value, including: The notifying party determines the data to be broadcast based on the data to be transmitted, the signature value, and the issuing authority number.
7. A method for receiving flight data, characterized in that, The method involves a product certificate database, which includes unique product identifiers for several aircraft and a certificate chain corresponding to each unique product identifier. The certificate chain includes a primary certificate and a secondary certificate. For any aircraft, the primary certificate is obtained by encrypting the aircraft's public key and unique product identifier using the private key of the issuing authority corresponding to the aircraft's identifier. The secondary certificate is obtained by encrypting the public key of the issuing authority corresponding to the aircraft's identifier and the issuing authority's number using the private key of the certification authority. The issuing authority is the aircraft manufacturer or inspection agency. The method includes: The receiver obtains the data to be verified from a preset frequency band. The data to be verified is determined based on the data to be transmitted by the corresponding aircraft, the issuing authority number, and the signature value. The signature value is determined based on the private key of the corresponding aircraft and the data to be transmitted. The data to be transmitted is determined based on the flight status of the corresponding aircraft and the unique product identification code. The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted. The receiver verifies the security of the data to be verified based on the signature value in the data to be verified and the data to be transmitted, specifically including: The receiver searches the product certificate database based on the unique product identification code in the data to be verified to determine the certificate chain corresponding to the data to be verified. The certificate chain of the data to be verified is verified using the public key of the certification authority. If, during the verification process, the issuing authority number in the secondary certificate is the same as the issuing authority number in the data to be verified, and the unique product identifier in the primary certificate is the same as the unique product identifier in the data to be verified, then the public key in the primary certificate will be used as the public key corresponding to the data to be verified. The receiver uses the public key to decrypt the signature value in the data to be verified to obtain the decryption result. If the decryption result matches the data to be transmitted in the data to be verified, the data to be verified is determined to be secure data.
8. A computing device comprising a memory and a processor, wherein the memory stores executable code, characterized in that, When the processor executes the executable code, it implements the method of any one of claims 1-7.
Citation Information
Patent Citations
Certificate acquisition method and device, equipment and storage medium
CN114826570A
Digital signature generation and verification method and device, equipment and storage medium
CN116545630A
Unmanned aerial vehicle management method and system, nonvolatile storage medium and electronic equipment
CN119383610A
Providing automatic dependent surveillance - broadcast data for unmanned aerial vehicles
US20190019420A1