1. Introduction
The increasing demand for unmanned aerial vehicles (UAVs) and Internet of Drones (IoD) in civil and military applications has been noticed in the last few decades [
1]. IoD usually consists of a number of drones, ground control stations (GCS), and a communication network for data exchange. Drones can obtain information through sensors and exchange information through the network. They can also communicate with GCS and other drones for proper navigation [
2]. The available space of the air traffic network (ATN) is much larger than that of the ground traffic network (GTN). Reasonable use of the ATN can reduce the burden of the GTN. Furthermore, using ATN can also avoid the congestion of the GTN. Therefore, many companies try to use drones as air transport tools for cargo transportation, so as to promote logistics efficiency [
3].
During long-distance flights, drones are likely to enter other IoD domains where they need to pass identity authentication and obtain necessary information such as flight routes to continue their tasks. In the IoD, wireless communication between drones is easy to eavesdrop on, resulting in information leakage [
4,
5,
6,
7]. Furthermore, attackers can conduct replay attacks or identity forgery to interrupt the IoD [
8,
9,
10]. In addition, once drone transportation forms a complete industry, the number of drones may be quite large. The resource overhead of complex authentication mechanisms, such as computation and storage, is a huge challenge for identity authentication servers [
11,
12,
13]. At the same time, it also increases the cross-domain waiting time for drones to obtain necessary information.
Centralized authentication techniques [
14,
15,
16] are widely adopted in traditional information systems. However, in an IoD environment, if conventional centralized authentication approaches are applied, the workload of the authentication service center increases exponentially as the system scales up [
17]. Therefore, traditional authentication technology is not suitable for the IoD environment. At present, there are also some studies using public key infrastructure (PKI), trusted third party (TTP), or blockchain technology to verify the identity of the drone and the authenticity of the task [
18,
19]. The existing methods are shown in
Figure 1a. However, the existing studies rarely consider the efficiency of cross-domain authentication in the case of a large number of drones. Additionally, when the number of drones is large, the time cost of cross-domain authentication is also very high.
When facing a large number of drones, existing drone cross-domain authentication methods lead to a surge in communication and computational costs for the IoD, increase the waiting time of the drones, and further reduce the overall operational efficiency of the IoD. At the same time, the existing methods cannot guarantee the anonymity of drones when performing the task, and attackers can obtain the connection between the sender and receiver through the identity and task information of the drone, which may leak the user’s privacy. Therefore, existing methods cannot meet the cross-domain authentication requirements for large-scale drone cargo transportation scenarios. Therefore, we propose a novel cross-domain authentication scheme for the IoD based on blockchain technology.
Blockchain has the advantages of decentralization, openness, being tamper-proof, traceability, and anonymity [
20]. The decentralization is consistent with the distributed network structure of the IoD. Furthermore, the openness can well satisfy the requirements for drones to join and leave the network freely [
21]. The advantages of being tamper-proof and traceability ensure the reliability and non-repudiation of data in the network, and the advantage of anonymity protects the data by addressing with address instead of addressing with identity. However, there are three potential challenges to using blockchain for authentication. (1) In the IoD, there are various types of data and the scale of data is large, meaning the single-chain structure may lead to query inefficiency and throughput bottleneck. (2) In the authentication process, a large number of drones may cause a high authentication delay time and increase the waiting time of drones. (3) The authentication server needs to authenticate the UAV identity information, verify the transaction in the blockchain, and upload the task information. A large number of drones to be authenticated may cause server interruptions.
To address the above challenges, we propose an efficient cross-domain authentication scheme based on blockchain. As shown in
Figure 1b, the main idea is that drones should authenticate each other before cross-domain authentication to form a mutually endorsed group. To ensure that the identities and tasks of drones in each group are real and trusted, we designed an authentication mechanism based on domain signature, encryption, and domain private chain. In this way, drones with the same out-of-domain range (Rout) compose a drone group. Considering the continuity of drone tasks in the process of cross-domain tasks, we designed a notification mechanism between domains combined with the concepts of token, permission, and authority. The main contributions of this paper are as follows.
(1) We propose an efficient blockchain-based cross-domain authentication scheme for the Internet of Drones (BCDAIoD). By using a consortium chain with a multi-chain architecture, the proposed method can query and update different types of data efficiently, which can also facilitate the domain management node to manage and control the drones. Additionally, we describe the mission model of the drones.
(2) In order to improve the efficiency of the cross-domain authentication of drones, we designed an establishment method of drone groups and a group cross-domain authentication method based on blockchain, encryption, and challenge–response game. By mutual authentication before cross-domain authentication, drones can compose drone groups to lighten the authentication workload of domain management nodes and improve the efficiency of cross-domain authentication.
(3) We propose a notification mechanism between domains that can enable the management node of the next domain to know the task information of the drones in advance. The management node of the next domain can plan space resources reasonably and plan the flight path for drones in advance, which can also ensure the continuity of the tasks of drones.
The remainder of this article is organized as follows. The literature is reviewed in
Section 2. The framework of BCDAIoD, the consortium blockchain architecture, and the mission model of the drones are presented in
Section 3. In
Section 4, we first propose the single-drone cross-domain authentication method. Then, we propose the establishment mechanism of drone groups, the drone group cross-domain authentication method, and the notification mechanism between domains.
Section 5 describes the simulation experiments and shows the experimental evaluation results of the BCDAIoD method. In
Section 6, we analyze the security of BCDAIoD. Finally,
Section 7 concludes this paper.
2. Related Works
- (1)
IoD management scheme
IoD has received widespread attention due to its potential application prospects. Therefore, there are studies targeting the management scheme of IoD. In order to facilitate the information acquisition of drones and users in IoD, Al-Hilo et al. [
22] proposed a collaborative and management framework between UAVs and roadside units. Arafeh et al. [
23] proposed a blockchain-based UAV management method that can verify the authenticity of information in IoD networks. By using blockchain and trust policies, García-Magariño et al. [
24] proposed a UAV management approach which can also maintain security in IoD by corroborating information about events from different sources. However, the above UAV management framework mainly focuses on data security and neglects the management efficiency when facing a large number of drones. Additionally, the blockchain-based methods have not been able to reasonably partition the data storage on the chain, leading to low query efficiency and data isolation.
- (2)
Cross-domain authentication scheme based on cryptography
During the task execution, drones need to verify their identity through cross-domain authentication. Meanwhile, in order to address potential threats, researchers have proposed some cross-domain authentication schemes based on cryptography. To protect drones against various types of possible attacks, Wazid et al. [
25] proposed a remote authentication and key management scheme. Srinivas et al. [
26] designed a three-factor authentication scheme which relies on elliptic-curve cryptography (ECC). Tanveer et al. [
27] leveraged ECC along with symmetric encryption and hash function, and proposed a robust authentication mechanism for IoD. For the sensitive environment in which an attacker might trap data from the open network channel, Jan et al. [
28] proposed a verifiably secure ECC-based authentication scheme for IoD. Additionally, Rajamanickam et al. [
29] proposed an ECC-based authentication protocol for insider attack protection in IoD scenarios that can protect the IoD from several known attacks, especially insider attacks. Ever et al. [
30] proposed a secure authentication framework using elliptic-curve crypto-systems to ensure data confidentiality. However, the above methods guarantee the security of IoD by performing multiple process parameter calculations on the device, registration center, and control center, which increase the computational burden.
- (3)
Cross-domain authentication scheme based on blockchain
Considering the interoperability and complexity characteristics of IoD systems, many existing research studies have applied blockchain technology in the cross-domain authentication area of IoT systems. To solve the single point of failure problem, Feng et al. [
31] employed blockchain and multiple signatures based on threshold sharing to build a cross-domain authentication framework. To avoid reliance on a trusted third party, Shen et al. [
32] introduced a consortium blockchain to construct trust among different domains and present an efficient blockchain-assisted secure device authentication mechanism. By using a hierarchy of local and global smart contracts, Gauhar et al. [
33] proposed a decentralized blockchain-based authentication mechanism which uses a proof-of-authenticity mechanism to find and retrieve device hashes stored in local blockchain. Zhang et al. [
34] proposed a thoroughly cross-domain authentication scheme based on blockchain, allowing participants from different domains with different settings to complete the authentication. However, the above methods neglect the anonymity of drones when performing the task, which may leak the user’s privacy. Additionally, the methods do not take into account the communication and computational costs of IoD when facing a large number of drones.
4. Cross-Domain Authentication of Drones
Drones may fly to other domains during the execution of tasks. Therefore, we designed a UAV cross-domain authentication method combining public key infrastructure and blockchain technology. In this section, we first propose a single-drone cross-domain authentication method. Then, considering that the cross-domain authentication of a large number of UAVs may cause a long waiting time for UAVs, we propose an establishment mechanism of UAV groups and a drone group cross-domain authentication method. Additionally, we propose a notification mechanism between domains to let the s prepare for UAV cross-domain and path planning in advance.
4.1. Single-Drone Cross-Domain Authentication Method
The single-drone cross-domain authentication method is shown in
Figure 5. This method uses public key infrastructure and a challenge–response mechanism to ensure the authenticity of the UAV’s identity, and ensures the authenticity of the UAV’s task by querying the
chain of the
. At the same time, a session key can also be generated during this process.
When drone
wants to fly to the next domain (
),
firstly send its cross-domain request (
) to the
in charge of
(
). The
can be expressed as Equation (7), where
represents the cross-domain request and
represents the
of
encrypted with the private key of the current domain
.
After receiving the
from
,
uses the
to decrypt the
to obtain the
. Then,
checks whether there is the incomplete
chain transaction
of the corresponding
. The
can be generated through the notification mechanism (detailed in
Section 4.4). Then,
searches the
chain to obtain the public key (
) of
according to the
. If
exists,
sends a random number
with
encryption to
as a challenge
. Then,
decrypts
with
to obtain
, and sends back
+ 1 and a random number
with
encryption as a response,
. Then,
checks
to determine whether
has the declared identity and obtains
y. If
passes the verification,
sends back a response,
, as a confirmation message. Then, the session key between
and
can be generated by
.
In this way,
can determine the identity and task information of
. Then,
sends the
to
. The
of
can be expressed as Equation (8), where,
represents the device ID of
in the
,
represents the time stamp of the
,
represents the permission that
has for obtaining the necessary information, and
represents the hash value of the combination of
,
, and
.
Finally,
obtains its
and uses the
to obtain the flight path and other necessary information from the
of the next domain. At the same time,
updates the
chain by using the method proposed in
Section 4.4.
In the UAV cargo transportation scenario, there are many UAVs flying to the same next domain. Therefore, we propose a method of drone group cross-domain authentication to improve the efficiency of UAV cross-domain authentication. The idea of this method is that UAVs compose a group through mutual authentication before the cross-domain authentication. In this way, the proposed method can lighten the authentication workload of the
and improve the speed of the UAV cross-domain authentication. The method is mainly divided into two stages: (1) the formation of a UAV group (in
Section 4.2), and (2) the cross-domain authentication of a UAV group (in
Section 4.3).
4.2. Establishment Mechanism of UAV Groups
The establishment mechanism of UAV groups mainly includes two parts: (1) the method of building a new drone group and (2) the method of joining a drone group. In the process of building or joining a drone group, drones need to use verification strategies to verify each other. The verification strategy is shown in
Figure 6.
When drone
and drone
start the verification,
firstly sends its verification information
to
.
can be expressed as Equation (9), where,
represents the two-way authentication request,
represents the
of
encrypted with the private key of the current domain
, and
represents the
block height of the block that includes the task information of
.
After receiving the verification information from , uses the to decrypt the to obtain the . Then, searches the local according to and queries whether the corresponding information is there. If is bigger than the block height of the local , it updates the from the . After that, obtains the public key () of from the . Then, a random number is encrypted by as a challenge , and sends its and to .
After receiving the
and
,
decrypts the
to obtain the
. Additionally,
searches the local
according to
and queries whether the corresponding information is there. If
is bigger than the block height of the local
, it updates the
from the
. Then,
obtains the public key (
) of
from the
. Additionally,
decrypts the
with
to obtain
, and sends back
+ 1 and a random number
with
encryption as a response,
. According to the notification mechanism between domains described in
Section 4.4, local
s saved by drones store task information for a period of time in the future, and the
s can be updated by drones after mutual authentication. Therefore, in theory, drones do not need or rarely need to update blocks through the
, and they only need to update blocks through the
at most once during a two-way authentication period.
Next, decrypts with and checks whether + 1 is received within a certain period of time to determine whether has the declared identity. Then, obtains and sends back a response, , to . After receiving the , decrypts the with and checks the response. After successful identity authentication, the session key between and can be generated by . Then, and can communicate with each other and update their s.
By using the proposed verification strategy, drones can confirm each other’s identity, generate session keys, and update the
s. In the process of moving, drones try to join a group or build a new one, as shown in
Figure 7.
- (1)
Method of building a new drone group
During flight in the current domain, a drone
broadcasts to inquire whether there is a drone group with the same
. If there is no drone group,
tries to build a new group and continues to broadcast to inquire whether there are drones with the same
. If
finds other drones with the same
, the drones and
send each other verification information, verify each other (as shown in
Figure 6), and then reach consensus to build a group. Usually, the number of initial group members is small (about 2–4 drones). In order to stabilize the drone group, the initial members need to authenticate each other and build communication links with a session key.
Each drone group selects a group leader
by voting. For cross-domain authentication,
generates a member list,
, of the drone group. The
can be expressed as Equation (10), where
represents the
of
. Then, the drones compose a drone group successfully.
- (2)
Method of joining a drone group
If finds a group after broadcasting, it sends verification information to the group leader () to join the group. Then, randomly chooses one drone to verify the together. After that, determines whether can join the group according to the authentication result. If passes the verification, adds the and public key of to the maintained by itself, and send its to . Then, saves the and broadcasts its own as a confirmation of joining the group. Additionally, the other drones in the group update their .
At the same time, in order to prevent the loss of drones, the drones in the group send inquiry and response signals regularly. Additionally, drones with forged identities cannot build or join a group because they cannot send the correct response.
4.3. Drone Group Cross-Domain Authentication Method
The drone group cross-domain authentication method proposed in this paper is shown in
Figure 8. When a drone group is ready for cross-domain authentication, the group leader of the group (
) sends a group cross-domain request (
) to the
of the next domain (
). The
sent by
can be expressed as Equation (11), where
represents the group cross-domain request,
represents the
of
encrypted with the private key of the current domain
(
), and
is the group member list of
.
After receiving the
from
,
verifies the group leader through the single-drone cross-domain authentication method proposed in
Section 4.1. Then,
obtains the
. If
passes validation,
sends
a
. After receiving the
,
sends a group cross-domain signal to the drone group. Then, the other drones in the group send group cross-domain requests to
. The group cross-domain request sent by
(
) can be expressed as Equation (12), where
represents the device ID on the PBC and a random number
encrypted with the public key of
. Additionally,
is generated by
after
joins or builds a group.
After receiving the , decrypts the to obtain the of . Additionally, checks whether the incomplete chain transaction of the corresponding is there. Then, searches the chain to obtain the public key of . Additionally, decrypts the to obtain the and of . If is in the , generates the for according to the equivalence between and . Next, sends a response, , to . After decrypting and obtaining , can generate a session key by .
In this way,
verifies the drones and distributes the
s to the drones in the group. Finally, the drones in the group obtain their
s and use their
s to obtain the flight path and other necessary information from
. At the same time,
updates the
chain by using the method proposed in
Section 4.4.
4.4. Notification Mechanism between Domains
When a drone enters a new domain, the of the domain needs to publish a transaction to the chain for uploading and updating the task information of the drone. After reaching a consensus, a packages a certain number of transactions and generates a new block on the chain. The s of the other domains query the chain at regular intervals and collect the task information of drones flying to their own domains. In this way, the s can plan the path for the drones in advance according to the , the destination, and other information of the task. The specific method is as follows.
In the domain
, the
of
(
) uses Algorithm 1 to find the transactions of the next domain (
), which is
, at regular intervals. Firstly, the algorithm obtains the latest block height of the
chain. Then, it searches blocks that have not been queried to obtain the transactions that include the latest drone task information. By comparing the
in the transaction (
.
) and the
of
(
), the algorithm determines whether the next domain in the transaction is the current domain, and then saves the task information. Then,
obtains the list of transactions (
) and the latest block height (
).
Algorithm 1. Task information query algorithm. |
Input: Mission, // Mission chain and the block height of the last query. |
Output: , // List of transactions and the latest block height. |
1. Initialize variable // Initialize the latest block height. |
2. Initialize variable // Initialize the list of transactions. |
3. = getHeight() // Obtain the latest block height of the
chain. |
4. for in range(,) // Search blocks that have not been queried. |
5. = read() // Read the transactions on the blocks. |
6. if(. = = ) // Determine whether the next domain in the is the current domain. |
7. .add() // Save the task information. |
8. else continue
|
9. end if |
10. end for |
11. return , |
When it has obtained the
and the relevant task information,
calls on Algorithm 2 to preprocess the tasks. For each transaction in the
, the algorithm receives
, and
from the transaction. Then, it calls on the path planning algorithm to plan a flight path for the drone and obtain the
ID of the next domain (
), the range out of the current domain (
), and the current expected time cost out of the domain (
). For drone cross-domain authentication, the algorithm reads the
chain and obtains the public key (
) of
. Then, it reads the
chain and obtain the
of the drone. Additionally, it generates the device ID in this domain (
) and the permission (
) for the drone. Then, the algorithm submits the transaction (
,
,
) to the
. In this way, the PBC of the drone currently flying to the next domain has the information about the drones performing tasks in that domain for a period of time in the future. Additionally, it generates an incomplete
chain transaction,
, and the
in
is updated when the drone arrives. At the same time,
packages the
transactions and generates a new block on the
at certain intervals, or the number of transactions meets the requirement.
Algorithm 2. Task preprocessing algorithm. |
Input: |
Output: , , , |
1. Initialize variable , // Initialization range and expected time cost out of the current domain. |
2. Initialize variable // Initialization variable of the next domain. |
3. Initialize variable
// Initialization variable of the current domain. |
4. for each transaction in |
5. Get from the transaction. |
6. Use path planning algorism to plan flight path for the drone and get , and . |
7. Read chain and get the of . |
8. Read chain and get the of the drone. |
9. Create and // Generate device ID in this domain and the permission for the drone. |
10. submit(, , ) -> // Submit the transaction to the . |
11. // Generate the chain transaction. |
12. end for |
13.
packages transactions and generates a new block on the at certain intervals or the number of transactions meets the requirement. |
14. return , , , . |
When a drone
has passed the cross-domain authentication and entered the domain
,
uses Algorithm 3 to publish a transaction for updating the task information of
. Above all,
obtains the task start time (
) of
in the domain. Then,
calculates the expected time out of the domain by
. After that, the
chain transaction including the task information of
is published, which can be expressed as
. We consider that all the
s in the
are trusted. Therefore, this paper uses the Raft consensus mechanism to package the transactions and generate new blocks. In addition, the
,
, and
generated in Algorithm 2 are sent to the
during the cross-domain authentication process.
Algorithm 3. Task information update algorithm. |
Input: Mission information |
Output: True or False |
1. Initialise variable isUploaded = FALSE // Initialization variable, upload success or not. |
2. Get task start time () of in the domain. |
3. Compute // Calculate the expected time out of the domain. |
4.
// Generate transaction including task information of . |
5. Publish the to the chain. |
6. isUploaded = TRUE // Upload successfully. |
7. return isUploaded.
|
6. Security Analysis
We used the widely used Dolev and Yao (DY) threat model [
35] to evaluate the security of the proposed method. In the DY threat model, a malicious attacker (MA) can inject, delete, eavesdrop, forge, or modify the exchanged messages over a public channel [
36]. In this way, an MA can perform various security attacks on drones or CNs. The possible attacks and descriptions are as follows:
- (1)
Replay attack: An MA replays authentication messages to deceive the .
- (2)
Forgery attack: An MA generates an illegal or false ID to deceive the .
- (3)
Impersonation attack: An MA obtains authentication messages by impersonating terminals or eavesdropping on a channel, and impersonates a legitimate device to deceive the .
- (4)
Man-in-the-middle attack: An MA captures authentication messages and spoofs both parties of the communication.
- (5)
Database tampering: An MA attempts to tamper with the identity information in the database to pass the authentication.
Additionally, we made two assumptions: (a) The private keys of the
s and drones are not revealed; and (b) An MA cannot deduce the private key from the public key, or it takes a lot of time. Considering the potential threats, we analyzed and compared the proposed scheme with the existing cross-domain authentication methods in terms of mutual authentication, cross-domain authentication, decentralization, anonymity, task path untraceability, path planning in advance, resilience to replay attacks, resilience to forgery attacks, resilience to impersonation attacks, resilience to man-in-the-middle attacks, and resilience to database tampering. The security analysis and comparison results are shown in
Table 5.
All the methods can well support mutual authentication and cross-domain authentication functions. At the same time, due to the use of blockchain technology and temporary intradomain ID methods, our method also has good decentralization and anonymity. Drones have different temporary IDs in different domains, and their device IDs on the and all mission information can only be queried by the consortium nodes. Therefore, an MA cannot obtain the complete flight path of the drone, namely, task path untraceability. The notification mechanism between domains designed in this paper allows s to plan their paths in advance, which can improve their perception of the overall network situation. For possible attacks, we make the following analysis:
- (1)
Resilience to replay attacks: During the process of cross-domain authentication, the s and drones use PKI and a challenge–response mechanism to perform identity authentication and generate a session key. An MA cannot obtain useful information through this attack.
- (2)
Resilience to forgery attacks: The s need to query the chain and the chain transaction to confirm identity, and an MA cannot forge identity on the consortium chain.
- (3)
Resilience to impersonation attacks: Unregistered drones cannot obtain a legal , public key, and private key. In the process of the challenge–response game, an MA cannot decrypt the ciphertext to complete the verification. Therefore, it is difficult to implement an impersonation attack.
- (4)
Resilience to man-in-the-middle attacks: The communication data are encrypted by a public key or session key, which solves the problem of private data leakage. Even if the data are captured, the MA cannot decrypt the ciphertext to obtain the message.
- (4)
Resilience to database tampering: The important data are stored on the consortium blockchain. Only when the MA holds more than 51% of the nodes can it change the data in the blockchain, which is impracticable.
7. Conclusions
During long-distance flights for cargo transportation, drones need to apply cross-domain authentication mechanisms to enter the next domain. However, due to public wireless communication channels, drones are vulnerable to various security attacks in the process of cross-domain authentication. When facing a large number of cross-domain requests from drones, a CN requires significant computational and time overhead, which may lead to long waiting times for the cross-domain authentication of drones. To address this problem, we proposed BCDAIoD, an efficient blockchain-based cross-domain authentication scheme for the Internet of Drones. The BCDAIoD method includes a single-drone cross-domain authentication method, an establishment mechanism of drone groups, a drone group cross-domain authentication method, and a notification mechanism between domains. By taking advantage of blockchain, PKI, and the challenge–response game, BCDAIoD can ensure the authenticity and integrity of data, and can effectively prevent various attacks on drones and CNs. Furthermore, BCDAIoD uses the CBC and notification mechanism between domains to enable CNs to plan paths for drones in advance, which can further improve the efficiency of drone cross-domain authentication and task execution. The main contribution of this article is that BCDAIoD can improve the efficiency and security of the cross-domain authentication of drones. Experiment results show that the cross-domain authentication time cost and computational overhead of BCDAIoD are significantly lower than those of the existing state-of-the-art methods when facing a large number of drones.
Nevertheless, there are still limitations when applying BCDAIoD. First, blockchain brings additional communication and storage costs to the drone network. For example, drones in the IoD communicate with each other and update their local blockchains. Second, a small number of drones flying to the same destination or drones being far apart from each other may lead to drone group establishment failure. Hence, to address the above limitations, we seek to further simplify storage data in the block and design block pruning algorithms for the PBC to reduce communication and storage costs in future extensions of this work. At the same time, we will also attempt to design an optimization algorithm that dynamically adjusts between single-drone and drone group cross-domain methods based on the current state of IoD.