Drone Secure Communication Protocol for Future Sensitive Applications in Military Zone

Unmanned Aerial Vehicle (UAV) plays a paramount role in various fields, such as military, aerospace, reconnaissance, agriculture, and many more. The development and implementation of these devices have become vital in terms of usability and reachability. Unfortunately, as they become widespread and their demand grows, they are becoming more and more vulnerable to several security attacks, including, but not limited to, jamming, information leakage, and spoofing. In order to cope with such attacks and security threats, a proper design of robust security protocols is indispensable. Although several pieces of research have been carried out with this regard, there are still research gaps, particularly concerning UAV-to-UAV secure communication, support for perfect forward secrecy, and provision of non-repudiation. Especially in a military scenario, it is essential to solve these gaps. In this paper, we studied the security prerequisites of the UAV communication protocol, specifically in the military setting. More importantly, a security protocol (with two sub-protocols), that serves in securing the communication between UAVs, and between a UAV and a Ground Control Station, is proposed. This protocol, apart from the common security requirements, achieves perfect forward secrecy and non-repudiation, which are essential to a secure military communication. The proposed protocol is formally and thoroughly verified by using the BAN-logic (Burrow-Abadi-Needham logic) and Scyther tool, followed by performance evaluation and implementation of the protocol on a real UAV. From the security and performance evaluation, it is indicated that the proposed protocol is superior compared to other related protocols while meeting confidentiality, integrity, mutual authentication, non-repudiation, perfect forward secrecy, perfect backward secrecy, response to DoS (Denial of Service) attacks, man-in-the-middle protection, and D2D (Drone-to-Drone) security.


Introduction
Unmanned Aerial Vehicles (UAVs) occupy an essential place in both military and civilian applications by playing a core role in criminal investigations, public safety organizations, transportation management facilities, and surveillance forces [1]. With the ability of dynamic mobility, quick reaction, and ease of deployment, UAVs offer new possibilities for different applications at a viable expense. In the last few years alone, networked UAVs have been a dominating area of research for different business organizations, such as Google, Facebook, Boeing, and Amazon.
High portability is one reason for interface twisting in UAV networking. Regardless of this, UAV-enabled systems support remote networks in the regions where physical interaction is troublesome or costly. It is apparent from the current research that UAVs are suitable for plenty of use cases, yet their deployments face a ton of difficulties and criticisms. Initially, the majority of the researches contend on the architectural structure

•
A new protocol for UAV-to-UAV and UAV-to-GCS is proposed, • A formal security analysis of the proposed protocol using BAN-logic and Scyther tool is carried out, • A detailed comparative analysis based on security property and computational overhead between the proposed and existing protocols is given, • The protocol is also implemented on a real UAV (powered by Raspberry Pi) and a Linux-based ground control station.

•
The remainder of the paper is organized as follows: In Section 2, the state-of-the-art study of existing drone communication protocols is described. In Sections 3 and 4, the proposed protocol is presented in detail, and a formal security analysis of the protocol is provided, respectively. In the final three sections, performance analysis, simulation results, and conclusion of the paper are provided, respectively.

Related Works
The development era of drones and communication technologies are tremendously growing, where the various specialist service providers and equipment sellers are bringing constant flow of new advancements, such as network accessibility [8], offloading strategies [9], path planning [10], and various applications [11][12][13]. These enhancements go hand in hand with industrial advancements, such as in References [14,15]. In particular to UAVs, the ongoing improvements emphasize the information rate and security, which includes secrecy, honesty, verification, and non-denial of transmitted information. UAVs have a risk of information leakage as they are remotely controlled or operated through predetermined missions in a resource-limited environment. With this regard, the cryptographic mechanisms are well-known solutions against the attacks in most UAV-based communications, which help to design robust security services. UAV communication, in general, involves the drones, network providers, ground control stations, and trusted third parties for authentications. Every entity plays a significant role in the entire communication process to safeguard the system from security breaches. To this end, various researchers have studied multiple security issues concerning UAVs, such as eavesdropping, network jamming, weak authentication, and mobility management issues [16,17].
Seo et al. [18] proposed a security solution for drone-enabled delivery service by utilizing White-Box Cryptography (WBC) as a product assurance instrument for UAV landing points and cryptographic resources, alongside Public Key Infrastructure (PKI) as a verification and non-repudiation technique. The principal goals of the proposed protocol are assurance of a secret key, information protection during capturing, and secure storage of information. The authors considered different security properties, such as confidentiality, integrity, non-repudiation, authentication, and software protection. Kriz and Gabrlik [19] proposed the UranusLink packet-oriented communication protocol with both non-reliable and reliable transfer mechanisms that allow secure connection and packet loss detection. The authors discussed various related issues such as security, low data throughput, ability to data loss detection, and low latency. Won et al. [20] proposed a secure communication protocol for drones and smart objects that depend on an efficient Certificateless Signcryption Tag Key Encapsulation Mechanism (eCLSC-TKEM). Islam et al. [21] presented a group key distribution protocol for FANETs (Flying Ad hoc NETworks), which relies on a group leader that discharges the base station for other operations. The authors considered different FANET requirements, such as node mobility and changes in the topology. Maxa et al. [22] provided a protected UAV ad hoc reactive routing protocol (SUAP; Secure Uav Ad hoc routing Protocol) that depends on public-key cryptography, hash chains, and geological lashes. It is utilized to ensure the route discovery component giving trustworthiness, verification, and non-repudiation services, which is the expansion of the SAODV (Secure Ad hoc On-demand Distance Vector) routing protocol.
Other related researches such as Blazy et al. [23] proposed UAV-GCS Secure Communication Protocol by using efficient cryptographic techniques to ensure the confidentiality of sensed data. The authors highlight various interesting requirements, such as forensicresistant property of captured UAVs should not compromise the security of UAS (Unmanned Aerial System) or the freshness of keys, to name a few. In addition, Wang et al. [24] proposed a handover key management scheme for the LTE (Long-Term Evolution)-based UAV control system to stress on the robust and secure connection to direct and control the UAVs. The paper further discussed security prerequisites such as authentication, access control, confidentiality, integrity, and user plane traffic. A certificateless group authenticated key agreement (CL-GAKA) scheme for secure communication among untrusted parties is also proposed by Semal et al. [25]. The authors considered confidentiality, message integrity, and authenticity requirements in UAV communication along with UAV-to-UAV secure channel establishment, whereas UAV-to-Infrastructure communication, as well as the routing problem, are not discussed.
Another study that examined the security requirements of UAV communications is presented by He et al. [7]. The authors discussed specific attacks like GPS jamming, spoofing, and Wi-Fi attacks along with the countermeasures. Likewise, Kim et al. [26] proposed a mechanism to confirm deletion activities in the wake of eradicating information, regardless of whether control of a remotely conveyed UAV is lost. The authors utilized a countdown-based approach and a hash chain to validate the sender of the received messages to trigger the deletion activity, significantly after UAV communication was lost. In connection to this, the security and privacy concerns of the Internet of Drones (IoD) is studied by Wazid et al. [27]. The authors also proposed a centralized authentication and key agreement scheme. The authors cover various security requirements but lack emphasis on the forward and backward perfect secrecy and non-repudiation, which are the essential requirements in critical and sensitive drone-oriented missions.

The Proposed Protocol
This section describes a security protocol used for UAVs to communicate with monitoring UAVs and GCS. The protocol is mainly designed to serve in a military environment with two sub-protocols: SP-D2GS (Security Protocol for Drone-to-Ground Control Station) and SP-D2MD (Security Protocol for Drone-to-Monitoring Drone).

Preliminary
Apart from their widespread usage in many application areas, UAVs have been extensively used in military settings, especially for the purpose of surveillance, search and rescue, national intelligence programs, reconnaissance, etc. [28]. Clearly, such operations are sensitive by nature, due to the fact that they almost always involve national secrets. Consequently, if exchanged information between the UAVs and the ground station are disclosed, it may bring a lot of damages-from risking international relationships to serious conflicts and wars. Thus, it is important to design a scheme that enables communicating entities to establish a secure channel before exchanging any sensitive information. In this section, such a security protocol that is particularly designed to operate in a military environment is described.
The intended communication between the UAVs and the GCS can be arranged in a direct or hierarchical fashion. In the former case, each of the participating UAVs exchange information with the GCS independently. That is, the UAVs establish a secure channel with the GCS first, and send the collected data through a wireless channel. Such arrangements can be secured with the SP-D2GCS protocol (shown as the golden colored arrows in Figure 1). For the hierarchical organization, a dedicated monitoring drone is responsible to collect and transmit various data from each of the assigned UAVs to the GCS. The monitoring drone, hence, acts as a middleman that executes the SP-D2MD protocol (shown as the blue colored arrow in Figure 1) between the UAVs and itself, and then transmits the collected data to GCS by using the SP-D2GCS security protocol. The details of these sub-protocols will be described in Sections 3.3 and 3.4.
Prior to the execution of the proposed protocol, however, the UAVs and the GCS need to be configured with the necessary information. First, the GCS generates the long-term private and public keys for each UAV. Then, it prepares a certificate request (CSR), based on their respective public keys and other information, and sends it to the Certificate Authority (CA). Next, it prepares unique identities (ID) for each of the participants. Once the key pairs, the certificates, and the IDs are ready, they will be securely delivered to each UAV, as shown by the green arrows in Figure 1. Furthermore, GCS and UAVs are assumed to be pre-configured with various cryptographic functions, such as digital signature algorithms (e.g., ECDSA; Elliptic Curve Digital Signature Algorithm), encryption and decryption function, cryptographic hash functions (e.g., HMAC; Hash-based Message Authentication Code), pseudo-random number generators (PRNG), etc. It is also assumed that the GCS and the UAVs are time-synchronized, and that the elliptic curve domain parameters (p, a, b, G, n, and h) are decided ahead of the communication, and are known by each of the communicating entities. Additionally, important information such as pre-shared keys (for instance PIN), IP address, type of UAV (monitoring or general drone), and operation ID (ID MISSION ) are configured by the user before the UAVs start their mission.

Threat Model
In computing, a threat can be understood as any incident that has the potential to bring loss or harm to a system. Substantially, threats are events that aim at violating the confidentiality, integrity, and availability properties of a computing system. Such threats can happen due to different vulnerabilities, which are weaknesses in the system as a consequence of design flaws, configuration mistakes, security policy inaccuracies, to name a few. Consequently, anyone with malicious intent and technical capability can exploit these vulnerabilities to launch an attack, thereby realizing the threats. Attacks can be orchestrated by two classes of an adversary: insider or external. The former refers to malicious attacks, such as replay, falsification, and masquerading, repudiation, or obstructions [29]. These attacks are typically carried out by a foe with legitimate or authorized system access. The latter represents attacks committed on a system network or computer system mainly either by exploiting a vulnerability of the system or by social engineering. These are threat actors that attempt to exploit security exposures, and they are generally located outside the firewall.
More often than not, cryptographic protocols are intended to work in an open environment where adversaries are capable of accessing the ciphered information exchanged between communicating peers. Such security schemes are often modeled with the Dolev-Yao (DY) threat model [30]. This model assumes an insecure public channel (which makes the communicating entities untrustworthy) and powerful adversaries that are capable of obtaining messages passing through the network, initiate and receive a conversation to and from other participants, and able of impersonating other entities. Despite all these capacities of the attacker, there is off-limits information. Some of this information is guessing random numbers generated from sample space and deciphering a ciphertext, enciphering a plaintext, or getting the same HMAC value without the proper key. Consequently, the protocol proposed in this work is modeled using the DY threat model, and only GCS is assumed to be fully trusted.
The assumptions we took in designing this protocol are described as follows. It is assumed that the elliptic curve domain parameters (p, a, b, G, n, and h) are decided ahead of the communication and are known by each of the communicating entities. The GCS and all affiliated drones can obtain a timestamp value indicating the current time, and have time synchronization to verify the given timestamp value from the other party. The GCS and all its drones have public/private key pairs and certificates supporting Elliptic Curve Digital Signature Algorithm (ECDSA), GCS assigns IDs to the drones and monitoring drones, and the user plans the operation through the related application and selects the drones included in the operation by using ID MISSION (the ID of the operation) and P (PIN number), which are provided before the execution of the protocol.
The proposed protocol is required to satisfy important security requirements to withstand various attacks. Some of the most important requirements are:

•
Mutual Authentication: for secure communication among a drone, a monitoring drone, and a GCS, the communicating entities need to authenticate each other mutually.

•
Strong Key Exchange: in order to assure the perfect forward secrecy of the protocol, a strong key exchange should be executed in a way that generated session keys cannot be recovered. • Confidentiality: the information exchanged between the drones and between the drone and the GCS should be protected from being accessed by unauthorized parties. • Integrity: it is critical to assure the authenticity of the information (that the information is not changed in between, and the source of information is genuine) exchanged between the communicating ends. • Non-repudiation: one of the essential security requirements in such scenarios is to make sure that the action done by one party cannot be successfully denied without others knowing about it. • Perfect Forward Secrecy: this property assures communicating parties that even if an adversary discloses a master key, old session keys will not be compromised. • Perfect Backward Secrecy: this property assures the communicating entities that even if an adversary discloses a master key, future session keys will not be compromised.

•
Protection against Denial of Service: legitimate users, such as legitimate drones, should not be denied service from a service provider, such as a GCS. • Protection against MITM (Man-In-The-Middle) attack: the protocol prevents an attacker from secretly relaying messages between the communicating ends.

SP-D2GCS
The drones and GCS should establish a secure channel and mutually authenticate each other before exchanging any sensitive information. For this, a security protocol, SP-D2GCS (Security Protocol for Drone-to-Ground Control Station), is needed that operates between the drones and the GCS. In SP-D2GCS protocol, drones and a GCS securely communicate to exchange telemetry and status information (from the drone to GCS) and commands and controls (from GCS to the drones). The D2GCS protocol consists of four message exchanges and is also compatible with the defacto MAVLink packet structure [31]. The notations used in both sub protocols (SP-D2GCS and SP-D2MD) are described in Table 1. The communication and packet structure of the D2GCS protocol is shown in Figure 2, and the details of the proposed protocol are shown in Figure 3.
(1) The first thing that happens in the SP-D2GCS protocol is for D to get the operation ID (ID MISSION ) and PIN (P) from the user. While doing so, or even before the actual protocol session starts, it can generate a random ECDH private key d D ∈ {1 . . . n − 1}, where n is the order of the group generated by G. It then calculates the ECDH public key Q D = d D • G. Now, D is ready to create a message M1, containing ID MISSION , its certificate (CERT D ), the computed public key Q D , and the current timestamp ts 1 , which is accompanied with the signature S1 computed by the ECDSA private key PR(D). To allow GCS to prevent the resource exhaustion attacks caused by the expensive public key operation, an HMAC is computed over the message M1 and signature S1 using the PIN number, P. Finally, the message M1, with the signature S1 and the message digest, is sent to GCS. (2) Upon receiving the message, GCS first checks its freshness by checking the included timestamp ts1. Once ts1 is in the acceptable threshold, it then computes HM(P, M1||S1), which is then compared with the received HMAC value. Note that doing two such verifications before the expensive public key operation, i.e., the S1 verification, helps to defend against resource exhaustion denial of service attacks. In a positive case, GCS checks the validity of the received certificate CERT D and verifies the digital signature S1 by using the public key that belongs to CERT D . If the verification of S1 holds, GCS successfully authenticates D. Now, GCS uses the same procedure D followed to prepare the ECDH private key (d GCS    An encrypt function where K is a secret key and M is an input message.

D(K, C)
A decrypt function where K is a secret key and C is a cipher message.

SP-D2MD
For cases where a dedicated monitoring drone is required to collect information from different general drones and pass this information to the ground station, a separate security protocol is required. Consequently, the SP-D2MD (Security Protocol for Drone-to-Monitoring Drone) protocol is used between a general drone D and a monitoring drone MD to perform mutual authentication and key exchange, thereby protecting their subsequent communications. Once all the information is collected by the MD, the MD uses the SP-D2GCS protocol to pass this information to GCS and receive different commands and controls from it. The communication and packet structure of this sub-protocol is shown in Figure 4, and the details are depicted in Figure 5.

Formal Security Analysis
This section puts forward the formal analysis of the proposed security protocols described in Section 3. The formal security analysis verifies whether the security protocol actually satisfies the targeted security requirements and services or not. In the past few years, the research on formal security analysis has been continuously conducted. In this paper, the proposed protocols are formally verified through modal-logic-based analysis, such as BAN Logic [32], and automation tool, such as Scyther [33].

Formal Verification with BAN-Logic
Named after its three authors, Burrows, Abadi, and Needham, BAN logic has become one of the most used verification methods to analyze security protocols formally. BAN-Logic consists of different notations and rules that are used for formal verification.
In general, formal verification through BAN-Logic is carried out in four steps: (1) idealization, (2) assumption, (3) goals, and (4) derivation. The analysis starts by idealizing the messages exchanged between the communicating parties by representing them into suitable format by which only encrypted (non-plaintext) messages are considered. Once the messages are put in this format, underlying assumptions regarding the original messages are made and formally expressed. Next, the goals are defined and expressed formally.

Notations Meanings
P believes X P believes that the message X is true P sees X P receives the message X at any point in time P said X P previously sent the message X P controls X P has jurisdiction over X Fresh (X) X is fresh P K ↔ Q K is a secret key shared between P and Q K → P K is the P's public key and L is the P's private key P K ⇔ Q K is a shared secret between P and Q {X} K X is encrypted with a key K X, Y X is combined with Y Table 3. BAN-Logic Rules.

Rule Names Rules
Message Meaning Rule (MM) P believes P K ↔Q, P sees {X} K P believes Q said X P believes P K ⇔Q, P sees X K P believes Q said X P believes K →Q, P sees {X} L −1 P believes Q said X Nonce Verification Rule (NV) P believes #(X), P believes Q said X P believes Q believes X

Idealization
The SP-D2GCS protocol is formulated into the following four idealizations.

Assumptions
The assumptions taken in the process of verification are listed below. While the assumptions A1-A4, A6, and A10 are with respect to GCS, the rest are taken by D.

Goals
The goals that are expected to be met by the SP-D2GCS protocol are listed below. They primarily illustrate mutual authentication and secure key exchange between D and GCS. Proof. Lemmas 2 and 8, above, show that g XY is securely set up between D and GCS. The private keys X and Y are immediately removed from both parties so that g XY will not be recovered in any case. Accordingly, it can be seen that the AK and EK derived from g XY support PFS and PBS.
Hence, it can be concluded from the proofs that the SP-D2GCS protocol fulfills the security requirements outlined in Section 3, which enables it to withstand known attacks.

Assumptions
The following are the assumptions considered while preparing the derivation process. The assumptions (A1)~(A6) are related to MD and the rest are related to D. From the above analysis, it is shown that the SP-D2MD protocol satisfied the goals (G1~G14). Also, the following lemmas can be derived through the satisfied requirements. Proof. The derivation result (D10) shows that the MD authenticates D. Similarly, D au-recovered under any circumstances. Hence, the authentication and encryption keys derived from g XY support PFS and PBS.
From the above proofs, we can conclude that SP-D2MD, like SP-D2GCS, is proven to satisfy mutual authentication, secure key exchange, integrity and data authentication of messages, and supports PFS, which makes it secured against known attacks.

Formal Verification with Scyther
Although the formal verification carried out by BAN-Logic validates the proposed protocol, highlighting that it meets the security goals and is secure against known attacks, BAN-Logic has found to have a limitation in pointing out some flaws [34]. Hence, for a complete formal analysis of security protocols, it is often necessary to combine BAN-Logic with automated tools such as Scyther and AVISPA (Automated Validation of Internet Security Protocols and Applications) [35]. In this paper, the automated formal verification tool Scyther is used to formally verify the SP-D2GC and SP-D2MD protocols.
Scyther, developed by Cremers in 2007, provides a graphical user interface that integrates the Command Line tool and the python scripting interface as an automated tool for formal validation. It provides validation, presentation, analysis, specification, and derivation of protocols. In particular, by providing protocol behavior classes, Scyther points out security problems through straightforward formalization and verification of protocols. The Security Protocol Description Language (SPDL) used in Scyther has a similar syntax to C/JAVA language (although case-insensitive), and defines roles as a series of events, consisting of events representing transmission and reception of information.
For protocol verification, Scyther can be used in three ways. Verification claim: verified or falsified security attributes, automatic claims: Scyther automatically generates and confirms a claim when security attributes are not specified as a claim event, and characterization: Scyther analyzes protocols and provides a finite representation of all traces, including the execution of protocol roles, so that each protocol role can be characterized. During the protocol verification process, Scyther creates an attack graph for unsafe protocols, and displays an individual attack graph for each claim. Claim events used for verification in this paper can be categorized by the functions shown in Table 4, and the details are described in Reference [26]. At first, each role is modeled in SPDL scripts. The basic roles include the D's role, the GCS's role, and the MD's role, as shown in Figure 6a-c, respectively. In addition, we included the claim events to each modeling, such as Alive, Nisynch, Niagree, Weakagree, Commit/Running, and Secret. Each roles are communicated with each other through the channel set through 'send' and 'recv'. These events check whether modeling can provide authentication and secrecy. If the proposed protocol is secure, the status of the result will show that every claim is OK. Otherwise, the result will show the process of leading to a vulnerable modeling state.
Scyther composes a communication environment based on SPDL scripts, as shown in Figure 6, and executes verification according to claim events. As shown in Figure 7, D, GCS, and MD of the proposed protocol have not been attacked against claim events such as Alive, Nisynch, Niagree, Weakagree, Commit/Running, and Secret. Consequently, the proposed protocol is proven to be secure against known attacks.

Performance Analysis
In this section, the proposed protocol is compared with four state-of-the-art security protocols [18,23,27,36], that can be deployed to protect the communication within the UAV network. The comparison is made in terms of security and computation overhead, whose results are provided in Tables 5 and 6, respectively.

Security Protocols Computational Overhead
Our Protocol SP-D2GCS SP-D2MD Step [23] -- 2C PC + 2C S + 2C SV  Table 5 provides the comparative analysis among protocols based on the security properties. It can see that the work in References [23,27] does not support non-repudiation property. Also, References [18,27] do not provide PFS. Therefore, if any long-term key used to derive past session keys has been exposed, adversaries can use the session keys to recover the encrypted messages to acquire sensitive data. Likewise, References [18,27] do not support PBS, thus causing the subsequent sessions to be vulnerable to various attacks, in case of compromise of any of the current long-term keys. Moreover, proposed protocols of References [23,36] are susceptible to DoS attacks due to resource exhaustion. Even worse, they perform high computational operation in order to support PFS and PBS, which puts a heavy burden on key updates during flight. In addition, protocols in References [18,23,36] do not support security between UAVs. As a result, it can be concluded that the designed security protocol offers better security compared to the other state-of-the-art protocols.
On the other hand, Table 6 compares the proposed protocol with the 4 protocols based on computation overhead. Similar to References [18,27], the proposed protocol cannot avoid excessive computational overhead in SP-D2GCS to support PFS and PBS. It is worth to note that such overhead is negligible because SP-D2GCS is executed only once. However, based on the strong session key, SK, derived from SP-D2GCS, SP-D2MD, which is primary executed in the proposed protocols, achieves relatively lightweight computation while meeting the security requirements.

Simulation Results
We developed the proposed security protocols using Python and tested it on an adhoc network that composed two real UAVs and a ground control station. The network architecture in the experimental simulation along with the actual experimental test bed for the proposed protocol are shown in Figures 8 and 9, respectively. The instruments used in this experiment are also listed in Table 7. The UAVs are equipped with a companion board Raspberry-Pi that is serially interfaced with the Pixhawk flight controller. The companion board enables developers to develop a self-operating UAV according to their target application. In the experiments, we create a straightforward application where UAVs and GCS simply exchange operational data or commands with each other at a predefined interval. Meanwhile, before the execution of said application, the proposed security protocols were first accomplished. During the execution of the protocols, essential metrics, such as size and transmission latency of the messages, were collected. The transmission latency refers to the amount of time for a message to travel across the network.    Table 8 shows the collected values of the target metrics. Based on this, the proposed D2GCS and D2MD security protocols have a total message size of 2411 and 781 bytes, respectively. Furthermore, the average transmission latency of each message corresponds to the number of bytes it carries. Based on our experiment, it takes approximately 213 milliseconds to establish a secure channel between UAV and GCS. Meanwhile, the execution of the D2MD security protocol takes an average of 29 milliseconds. The performance of UAVs can be significantly influenced by its power consumption and transmission latency, which can be associated to the message size of a particular key exchange protocol. With regards to the former, the size of the transmitted or received messages play an important role in extending energy lifetime of UAVs, especially when the key exchange protocol is executed during its flight. On the other hand, the latter, which is still dependent on the size of the messages, has an impact on the amount of time it takes for two parties to establish the secure channel. In relation to these factors, the relatively low message size and latency obtained from our experiment indicate that the proposed protocol has a great potential in terms of the practical aspects related to UAV network security.

Conclusions
Although UAVs play an essential role in a wide range of application areas, there are still security issues that limit their full potential in delivering the required solution. Especially in the case of military scenarios, the security and privacy of UAVs should be among the highest priority. In order to resolve the security concerns, we proposed a security protocol (with two sub-protocols, SP-D2GCS and SP-D2MD) that enables secure communication among UAVs and between the UAV and the GCS.
Our protocol can be applied in four different deployment scenarios. Scenario one consists of multiple military UAVs with inbuilt sensors that transmit traffic to each other, in which only the monitoring drone is able to communicate with GCS directly. In this case, the SP-D2GCS protocol assists the communication between the drone and GCS, while SP-D2MD is used between the drone and monitoring drone. In case 2, apart from the communication between the drones and monitoring drones, the ordinary drones themselves communicate with each other. However, similar to case 1, it is only the monitoring drone that communicates with the GCS. The third case involves direct communication between the drones and the GCS without a monitoring node sitting between them. In such case, the SP-D2GCS protocol can be used to secure the channel. The final arrangement is similar to case two, except all intercommunicating drones also communicate with the GCS directly, which uses both of the proposed sub-protocols.
Our protocol is also evaluated to prove that it meets all the security requirements described in the proposed protocol section. The proof is conducted by using two formal verification methods, BAN-Logic and Scyther. Furthermore, both sub-protocols are implemented on a real UAV (powered by Raspberry Pi) and a Linux-based ground control station and compared to other similar protocols against security and performance. The authors would like to further consider the privacy issues in UAV communication and design an adaptive security solution as their future work.