1. Introduction
Unmanned aerial vehicle (or drone) technology has begun to be used in the private sector [
1,
2] due to technological advances such as control, communication, and cameras, unlike the past that was only used for military purposes. Drones with a higher degree of freedom can be used to provide various kinds of services [
3]. For example, drones are widely used for shooting diverse sports activities at the individual level. Amazon is conducting research on using drones for book delivery [
4], and New Zealand’s Domino pizza had succeeded in delivering pizza using drones [
5]. This mobility raises the importance of employing one or more drones in the Internet of Things (IoT) environment [
6,
7]. Drone can provide surveillance [
8] in the places or angles that humans are unable to reach due to the drone’s unlimited mobility, and it also can provide connectivity by improvising a local area network infrastructure in real-time according to the overall situation. In addition, the multi-drone system enables us to diffuse commands into and/or collect data from geographically-disperse sensor devices, which are essential functions in an IoT system, and thus, it can extend the battery life of sensor devices and reduce the cost of infrastructure deployment by collecting the data while moving.
However, there are limitations to controlling a drone based on a remote controller (RC) because it requires interaction with the controller, and it can be worse when multiple drones are employed in providing services. It is infeasible for one pilot to control several drones at the same time through multiple RCs. Even if several pilots operate drones one by one, the burden of labor costs will increase as the number of drones required for service increases. To make drone control autonomous and reduce control overhead from pilots, ground control station (GCS)-based control draws much attention in drone research and community [
9]. Using features such as waypoint flight or setpoint flight in the GCS, a drone can autonomously move to the target point without any RC operation. The GCS also makes it easy to implement a multi-drone system and its formation.
Due to its performance and purpose of the drone, the altitude at which actual drones fly is at a level that humans can see with the naked eye. As a result, drones are likely to be exposed to other people and, even more, can be physically captured by hostile persons. Attackers can then inject false data into the captured drone, or directly control the drone as if it is a normal drone. Physical capture is actually meaningful. Note that many researchers are conducting studies to catch drones by birds or make a forced landing using radio waves. Considering most drones communicate with each other based on an ad-hoc network [
10] in a multi-drone system, using the same group key for all the drones may expose all their session keys to the same hacking risk when one of the drones is captured. To show how dangerous group key usurpation is in a multi-drone system, we designed a simple scenario. In this scenario, we first extracted a secret key from the packets between the GCS and the multi-drone system with a common hacking tool. After that, we made a fake GCS and tried to send a command
disarm with the extracted group key, which forces the drone to crash. The whole process is shown in our video (
https://youtu.be/tw95S1KBlls/). Following the video, what we can see is that it is important to have strong resistance to physical capture to prevent group key exposure. The key update to prevent this exposure can cause a temporary disconnection of all the drones, which may result in a catastrophe in the control of a multi-drone system. Moreover, asymmetric key encryption based on a public key requires many operations and subsequently much computation, so it is better to exclude it if possible.
Consequently, a security scheme for a multi-drone system should have strong resistance to such physical capture. Moreover, using a symmetric key-based encryption is better than an asymmetric key-based algorithm due to the constrained resource on the drone. In this paper, we propose a saveless-based key management and delegation system for a multi-drone system. The meaning of saveless property is that the drone saves a minimum of secret data in its storage. In the proposed system, all group session keys are not the same, only drones which are same-hop from the GCS have the same group key, which is different from other group key management systems. These session keys are generated by the hash chain function, so one of the drones can know the other’s session key, and they can communicate with each other. When a physical capture occurs, which leads to changing the network topology, the GCS generates new session key and sends it to all drones except the captured drone. However, it is possible for a drone to leave the flight formation according to flight schedules or external factors, such as wind or flat battery. In order to compensate for this, the proposed system provides a readmission process for breakaway drones. We then propose the delegation system for GCS, which can be used in many scenarios. Complexity analysis shows that our algorithm can reduce storage usage and communication traffic.
The major contributions of our paper are:
We propose the saveless-based drone authentication system, which is resistant to physically capture. Following the system, all drones in the network basically have a different session key, so secret data leakage can be minimized even when one drone is captured;
We introduce the saveless-based drone delegation system. With our delegation system, the GCS can temporarily give the control right to another GCS with simple authentication.
The rest of the paper is as follows: We shows the related work in
Section 2. The proposed
saveless-based group key management system is shown in
Section 3.
Section 4 presents our drone delegation system.
Section 5 analyzes how our system is secure.
Section 6 shows the results of our system in numerical evaluation and simulation study based on actual experimental data. Finally, we conclude the paper in
Section 7.
2. Related Work
Issues related to group key management have already been studied extensively. The advantage of a group key is the ability to reduce the key size since all members in the same group share one group key to communicate with each other. For example, if all connections require different keys, the number of required keys is
. However, using the group key, the required key is only one. This idea is supposed to be used for networks whose nodes have limited calculating power and storage, such as sensor networks. Recent studies on the group key are based on attribute-based encryption [
11,
12,
13,
14]. Following this idea, it is possible to send the data to users who have appropriate attributes without additional checking attributes, unlike other algorithms. However, this idea is too heavy to directly apply to sensor networks or drone networks.
Our system is symmetric key-based key management, and movable node-based key management, which seems like a network dependent-based scheme [
15]. A network-dependent approach basically supports node moving over a widely distributed wireless network. The main point of this environment is re-keying [
16], which is introduced as a key renewal process in the proposed system. For re-keying, there are some studies to reduce the re-keying overhead. Sandirigama et al. [
17] used password-based key management with a combination of re-keying and authentication. Suganthi et al. [
18] proposed the energy efficient key management scheme by generating pair-wise keys and maintaining them without key sharing. However, these algorithms are not suitable for the drone environment.
The proliferation of the IoT network, which includes devices which have small size and limited performance but can be highly distributed with an ad-hoc-based wireless network, has been highlighted. These devices are basically operated on a group basis; the network operating environment is similar to the drone environment. Li et al. [
19] showed the secure sensor association and key management scheme in a body area network. A group of nodes establish group pairing before the deployment, then the secret keys are generated. However, the difference with the body area network is that each node in the drone network moves to a different path. Zhang et al. [
20] were able to filter the false data through group rekeying which is sent by the compromised node. Following this idea, the future key cannot be extracted without neighbor nodes, but it is not sufficient to satisfy mobility, which is important for the drone environment.
The self-healing key distribution scheme [
21,
22,
23] is useful when network status is unstable in the wireless network. In a drone environment, the self-healing property seems important since all connections are based on an ad-hoc wireless network and all nodes continuously move in 3D-based directions. However, the property is vulnerable to physical capture. Following this property, the node stores some information to restore the session key. When the node is physically captured, all data in the storage will be disclosed. In the proposed system, the only exposed data are the current session key, and the topology and session key will be changed when the system notices the physical capture attack.
3. Saveless-Based Group Key Management System
In this section, we propose a saveless-based group key management system to guarantee resistance to physical capture. This system consists of four protocols: Initial key management, node communication, group key renewal, and withdrawal management. These protocols are described in detail below.
Before introducing the protocols, some assumptions and the environments of multi-drone flight control are as follows: All drones and GCSs are connected with Wi-Fi-based ad-hoc networks. The GCS is the administrator which gives various commands and sets the course of the drones. The n drones fly following the flight path and execute the command by the GCS. The drones are located in the proximity of the GCS before the flight, which means that initial group key generation and distribution protocols are secured.
3.1. Initial Group Key Generation and Distribution Protocol
This protocol will be run before the initiation of the flight, and all communication is secured. When a key generation protocol is finished, the GCS sends the group key
to drones selected by prearranged topology with one-hop distance, since the GCS and all drones are not in operation. The drones, which receive their group key
, calculate following each of their next-hop node’s group key and then send the key to next-hop drones.
where
i will be 0 in this protocol. The idea is that the group symmetric key belongs to each drone and is different compared to other drones except the same-hop drone.
3.2. saveless-Based Communication Protocol
After the registration is over, the GCS can send some command messages, such as take-off and move to the setpoint, to the drone formation. The command message sent to the drone has to be encrypted with the group key. There are two possible types of communication protocol: GCS-to-drone broadcasting or node-to-node direct communication.
Table 1 shows notations for this protocol and the group key renewal protocol.
3.2.1. GCS-to-Drone Broadcasting Protocol
In the case of broadcasting, this type of communication is commonly used when the GCS sends the command message to the drone formation. There are two possible methods to broadcast the message: single node-based broadcasting, and forwarding-based broadcasting. Single node-based broadcasting is that a sender encrypts messages using each receiver’s group key. After that, the sender sends the appropriate message to the receiver one by one. This method seems common at our scheme, but it requires lots of overhead in the sending phase.
The forwarding-based broadcasting method is that a sender only forwards the encrypted message to next-hop receivers. The whole procedure is as follows.
A sender encrypts the message using next-hop’s group key in session
i:
The sender forwards to next-hop receivers;
The next-hop receivers get the
decrypting
with their key
:
The next-hop receivers reiterate the previous process, such as re-encrypt , using the next-hops’ session key and forward the result to their next-hop nodes.
As a result, all nodes in the network can receive the sender’s message. The encrypt function can be a commonly used symmetric encryption algorithm, such as DES or AES. The method can reduce the sending overhead compared to the previous method, and the energy consumption of intermediate drones can be also reduced since intermediate drones send the data at one time and symmetric key-based encryption and hashing does not need many computation power.
3.2.2. Node-to-Node Direct Communication Protocol
The overall process of direct communication is almost the same as the broadcasting type. A different point is that the hop distance between a sender and a receiver may be higher than one. In this case, the temporal encryption key between two nodes will become the group key value of the node, which has higher hop distance. The reason is that the node which has a lower hop number can easily calculate the higher one’s group key using the hash chain. Following Equation (
2), the message sent to the receiver is as follows:
where
is the sender’s hop number, and
is the receiver’s hop number. When two drones which are physically connected want to communicate with each other before the key renewal protocol activation, it is possible to share their hop count in this session.
3.3. Group Key Renewal Protocol
All drones in the network send a beacon message to announce their own network status. From the beacon message, the drone can see the need to update the network topology due to the position change of some drones. In this case, all group keys of the drones should be renewed to satisfy the
saveless property. The member drone sends a message that requests a routing table and group key renewal to the GCS. Then, the GCS calculates a new session’s group key as follows:
To send the new session’s group key, the GCS determines which drone is the nearest one using the general routing algorithm and reported drones’ position. The GCS then wants to forward the new group key to the new 1-hop drone; there are the following issues in broadcasting the renewed key.
The new group key has to be encrypted to send them because all drones are not close-range, in contrast to the initial key distribution protocol. Therefore, the GCS cannot use near communication or secured channel communication in this case;
The key which will be used to encrypt should be an old group key since all drones do not have the new session’s group key;
The position of all drones and routing paths is already changed, so the next-hop node may not have the when the drone’s old group key is .
The whole procedure of renewed group key distribution considering previous issues is as follows (see also
Figure 1).
Each drone periodically senses all neighbor drones;
When a drone notices that the neighbor drones has been changed, it broadcasts a request message that all drones need to report the list of their neighbor drones to the GCS;
The GCS collects the neighbor list of each drone, then calculates the new routing paths;
The GCS generates the following tuple
:
Figure 2 shows an example of the tuple. In the figure, a circle represents a drone
x, a number in the circle is
, and a blue colored text above the circle is
. When network topology has been changed like in
Figure 2b, the tuple
generated by the GCS is
;
The GCS calculates its new session key
following Equation (
4) and next-hop’s new session key
;
The GCS encrypts the
and
by Equation (
3) to forward the result message to the next-hop node. In the example, the encrypted message
which will be sent to drone 4 by the GCS is
, because drone 4’s old hop count is 2;
The nodes decrypt the encrypted message to get the new session key and find their next-hop nodes. In the example, drone 4 decrypts and gets using its old session key . After that, drone 4 can find that the next-hop nodes are drone 3 and drone 1 by checking in ;
The nodes encrypt the new session key for their next-hop nodes as the following equation:
All the next-hop nodes of the GCS just broadcast the message
to their next-hop nodes. The next-hop nodes can decrypt
since they know the
of the sender and session
i’s hop count for all nodes. In the example, drone 4 has to broadcast a new session key to drone 3 and drone 1. Therefore, the encrypted message which drone 3 and drone 1 will receive is as follows:
All drones in the drone flight formation repeat the above procedures from step (7) to step (8), then all drones can get the new group key in session .
3.4. Node Withdrawal and Re-Participation Protocol
There are two cases where a new node participates in the drone flight formation already in operation: When another GCS delegates its drone’s control, or when a drone is readmitted into the formation of the intended flight. Since a delegation case is explained in a later section; the readmission case is introduced in this subsection.
In the following flight environment or pre-populated scenario, some drones can break out of the formation. The factors that can affect the flight route of the drone are not only a natural environment, but also built environment, such as winds, rain, the position of the building or trees, etc. Some drones may be disconnected from the flight formation because of these situations. The breakaway drones can lead back to the right position of the formation due to the adjustment of an attitude control system.
The breakaway drones attempt to re-join the drone network but will be denied. First, the drones have to prove that they were not physically captured while they departed from the network. Even though this proof has been accepted, the drones cannot accept the new group key from the proposed group key renewal protocol since they do not have the group key of the last session. The GCS may change the session and run the group key renewal protocol at the moment of confirmation that some drones left the network. Initializing the session and distributing the initial group key is too dangerous in action.
Even though there are some solutions to re-authenticate the drone with a symmetric-based encryption scheme, a new re-authentication protocol is needed since it is hard to distinguish the cases between the physical capture or scheduled/adventitious breakaway. This is because our protocol guarantees
saveless property to defend the physical capture. The scheme for re-authentication consists of two parts, the withdrawal and the readmission part.
Table 2 shows notations used in the withdrawal and re-participation scheme. The whole procedures of the withdrawal part are as follows.
When the breakaway drone
is aware that the link between itself and the other drones in a formation is broken, it rapidly runs the encryption algorithm to save the information, where
r is a random nonce:
Further, it immediately replaces the key with temporary key , and the flight data with ;
After some period of time,
repeatedly generates encrypted flight data
and a new temporary key
following equations, where
j means a temporary session number:
replaces the old temporary key with a new temporary key at the indicated intervals but saves all encrypted flight data , and timestamp when is far away.
The readmission part consists of two processes: The pre-verification process and the readmission process.
Figure 3 shows the whole readmission part. When
re-meets its original formation, a pre-verification process will be started as follows.
sends the verification request message to a first node which discovers ;
sends and to the GCS, where is a random nonce of , is a hop number of , and is a current session number of ;
The GCS extracts the from since it knows the session when has been left the formation;
The GCS verifies the real position of
at
:
Further, the GCS verifies the timestamp by , where is a current time;
If the withdrawal is scheduled, the GCS can estimate the , then will be set to an appropriate time;
If the withdrawal reason is uncertainty, such as wind and obstacles, has to be very short.
If the two verification processes are completed, the GCS orders and to run a one-time key exchange protocol.
The GCS sends a message
to
as follows:
saves , then sends the to ;
decrypts the received message and saves .
In this process, the GCS can know the , because following equation , the GCS already knows and receives and from . cannot communicate with the GCS since it does not have the old session key . The above algorithm gives the one-time session key used to complete a readmission process. The readmission process involves the following steps:
sends ;
The GCS extracts from ;
The GCS verifies following two conditions:
where the first condition means how the breakaway drone has followed the correct route on average, and the second condition means whether or not the breakaway drone sharply changes its position by virtue of the attacker’s physical capture;
If the two conditions are successfully passed, the GCS sends a message which encrypts its new session key, , to ;
revokes .
4. Drone Delegation System
According to the operational scenarios, a drone flight formation can be controlled by multiple GCSs. Moreover, some GCSs can temporarily or permanently delegate the control of the drone flight when the range of operations is very large. In this case, drone delegation and ownership transfer are important things in both drone security and security performance. The drone delegation system requires two protocols: The GCS authentication protocol and the drone delegation protocol.
Table 3 shows the notation used in this section.
Figure 4 shows the whole procedure of the drone delegation system.
4.1. GCS Authentication Protocol
The whole procedure in which a delegator GCS and a mandatory GCS authenticate each other is as follows:
The delegator GCS D, which delegates its drones to the mandatory GCS M, first requests delegation to M sending ;
M sends random nonce to D;
D sends a message to M;
M sends a message to D;
Each of M and D uses the other side’s public key, and , to verify the other side’s identity, where the public keys can be gotten from the key master which manages the GCS’s public key.
4.2. Delegation Protocol
After the authentication of GCS, the next phase is drone delegation, and the mandatory GCS can control the drones with its key. An important point of the delegation is that this protocol temporarily controls the right to the mandatory GCS.
There are two cases in this protocol; the drone group belonging to D is far away from the group of M and the close case. The far case is very simple because M sends a command message to the D, in which the message is encrypted with shared key between D and M. The close case, however, M can directly send a command message to drones belonging to D. A procedure of the close case is as follows:
D decides , , and replacement key ;
D broadcasts the following message to all of the drones under its command, where
i is the current session of
D:
Some drones, which receive the broadcast message, check if
is true by a keyed hash function, and save the message, then generate a forwarding message and forward it to their next-hop drone, where
:
Repeat (2) until all drones receive the message;
D sends the following message to
M, where
is the drone’s id, and
n is the number of drone under
D:
M calculates the new route for the delegated drones;
M sends the following key renewal message to all nodes in
, where
is a delegated pair of drone
x:
Each drone in
decrypts the received message, then it sends the following message to their pair delegated drone for distributing a new session key:
The delegated nodes check using the keyed hash function and save key ;
If the previous hop node of a delegated node is also a delegated node, then the previous node runs step (8) to act as a node in .
4.3. Delegation-Based Command Protocol
Since M receives the command right temporarily in our delegation system, delegated drones have to send the update message to the M. Like many delegation protocols, we adopted the parameter as a command counter, rather than a time duration. In drone control, there is a risk of loss of control in some cases if control is provided based on duration. The process of sending and receiving commands is as follows:
When the delegated node receives a command message, it replaces the stored encrypted message following equation:
If , then the delegated node notes to M that delegation has to be renewed with
M sends the received message to D;
D verifies if delegation renewal is required by checking since D has and ;
If this verification succeeds, then D and M run the delegation protocol again.
5. Security and Usability Analysis
In this section, we show that the proposed algorithm is secure against possible attacks in a drone environment. The above four items in the table show the security analysis; the other four items represent how these systems are suitable for a drone environment.
5.1. Physical Capture Attack
As we have already noticed in the introduction and related work, the drone is easy for the attacker to capture. Following our protocol, exposed data in the drone are as follows when the drone is captured: Hashed session key, encrypted flying data of the drone, and the timestamp when the node has been hijacked. When the protocol uses the cryptographic hash function, the attacker cannot know the last session key due to the one-way property of the hash function. The encrypted flying data are protected with the last session key, as the attacker who does not know the last session key cannot decrypt this message. Even though the attacker can extract the session key from the captured drone, the network topology and session key will be updated when the capture attack is detected. After that, the extracted session key is of no use. Overall, the riskiness of key exposure depends on the security of cryptographic hash functions.
The easy method for attacking the proper network after the physical capture attack is the masquerading attack, which acts as a proper drone. The captured drone returns to the flight formation and wants to report false data to the GCS. The malicious drone will try to run a re-participation protocol to join the drone network at first, but there are two reasons it is hard to pass the conditions in the re-participation protocol. The one reason is that there is no way to modify the encrypted flight data since the attacker does not have the key. The other is that route design considering cross-validation analysis by the neighbors of the captured drone can easily defend this attack, even though the session key is exposed.
It seems to be a threat to the drone environment when the drone near the GCS is physically captured. Following our protocol, the drone near the GCS has low hash chains, so it can generate the child node’s session key with ease. Therefore, the attacker which captures the drone near the GCS seems to disrupt the service by maliciously controlling many child nodes. However, this attack cannot succeed in two possible cases. In the first case, when the drone deployment and the GCS is physically near, the operator can observe the drone network with the naked eye. In this case, the operator will easily notice the physical capture attack and run an emergency mode to return the other nodes. In the second case, even the distance between the drone network and the GCS is too large to see with the naked eye, our system runs the key renewal protocol after the beaconing period. There is not enough time for the captured drone to come back in the beaconing period. Moreover, the returned drone’s re-joining into the deployment will be failed by the node withdrawal and re-participation protocols.
5.2. Forward and Backward Secrecy
To satisfy the forward secrecy [
15], a drone cannot acquire the group key in any way while it is away from the flight formation. By the key renewal protocol, there is no relationship between the current master session key
and the next master session key
. A specific node’s session key is calculated with a hash chain function. The idea using these facts is that the breakaway node cannot generate an expected next session key with its secret information. The backward secrecy is satisfied if the new member joining the group cannot decrypt the ciphertext before then. The proposed system guarantees the backward secrecy due to the similar reason of forward secrecy.
5.3. Key Independence
The characteristic of hash function and hash chain function and the key between different session and different hops guarantee independence. Especially since the random nonce is included in the input of the next session key generation, key independence is satisfied. A possible concern is that the node can acquire its children’s session key only using the hash function. However, by considering the concept of a group key, where all group members share the keys, our system satisfies key independence.
5.4. Usability Analysis
Guaranteeing the security requirement is indispensable, but satisfying with the concept of usability is also important. As in
Table 4, each group key management scheme is designed for its own target system, such as the body area network and wireless sensor network. The attributes and the requirement conditions for the drone network environment are different from other network environments. The systematic attributes for the drone network environment are mobility, multi-hop-based communication, message broadcasting availability, and delegation support. Other algorithms can guarantee some attributes, but our algorithm is the most suitable for the drone environment.
5.5. Networking Issue
Drones networks with high mobility in real environments are vulnerable to hidden node problems. This paper basically focuses on the physical capture attack and the key management, but we briefly explain how the proposed system can cope with this problem. In our service scenario, the drone network is configured with a tree topology, and the GCS is a root node. When the key renewal protocol starts, all drones in the network change their antennas to listening mode. Only drones which receive the key renewal message from the GCS (or their parent nodes) can change their antennae into transmission mode. According to this procedure, our protocol follows a top–down communication method. Since this method transmits data from the root node to leaf node following a fixed order, it is possible to say that the method is scheduled. Therefore, our protocol can reduce the hidden node problem without any modification. Additionally, by adding transmission order data into the key renewal message, the hidden node problem can be nearly resolved.
7. Conclusions
In this paper, we proposed an authentication and delegation system which is appropriate for a GCS-based multi-drone control system that is necessary for the IoT environment to compose and operate it. Compared to a general group key management scheme, the proposed system is focused on the physical capture attack that is a critical threat to the multi-drone system. Therefore, the proposed system is based on the idea that storing secret data, such as a group key, flight data, and operational intelligence, will be a minimized, so-called saveless property. The proposed key distribution protocol is based on the saveless property. It also includes key renewal and a node re-participation protocol to apply unconstrained mobility, which is the core attribute of drone environment. We additionally proposed the drone delegation system for delegating control right to other GCSs by the drone’s operation and position. The complexity analysis shows that the algorithm can reduce storage space without any additional overhead. The simulations based on the data from experiments verify that our system is suitable in the real-world environment.
As future work, we would like to reduce the proposed key management and delegation protocol to work with very small IoT devices that have limited computation power, and to find a proper key renewal period that satisfies a low computation cost and more security guarantee.