Blockchain-Assisted Secure and Lightweight Authentication Scheme for Multi-Server Internet of Drones Environments

Abstract

Unmanned aerial vehicles (UAVs) have seen widespread adoption across diverse sectors, including agriculture, logistics, surveillance, and disaster management, due to their capabilities for real-time data acquisition and autonomous operations. The integration of UAVs with Internet of Things (IoT) systems further amplifies their functionality, enabling sophisticated applications such as smart city management and environmental monitoring. In this context, blockchain technology plays a pivotal role by providing a decentralized, tamper-resistant ledger that facilitates secure data exchange between UAVs and connected devices. Its transparent and immutable characteristics mitigate the risk of a single point of failure, thereby enhancing data integrity and bolstering trust within UAV–IoT communication networks. However, the interconnected nature of these systems introduces significant security challenges, including unauthorized access, data breaches, and a variety of network-based attacks. These issues are further compounded by the limited computational capabilities of IoT devices and the inherent vulnerabilities of wireless communication channels. Recently, a lightweight mutual authentication scheme using blockchain was presented; however, our analysis identified several critical security flaws in these existing protocols, such as drone impersonation and session key disclosure. To address these vulnerabilities, we propose a secure and lightweight authentication scheme for multi-server UAV–IoT environments. The proposed protocol effectively mitigates emerging security threats while maintaining low computational and communication overhead. We validate the security of our scheme using formal methods, including the Real-Or-Random (RoR) model and BAN logic. Comparative performance evaluations demonstrate that our protocol enhances security while also achieving efficiency, making it well-suited for resource-constrained IoT applications.

1. Introduction

The rapid evolution of unmanned aerial vehicles (UAVs), commonly referred to as drones, has positioned them as indispensable tools across a variety of industrial fields, including agriculture [1], logistics [2], environmental surveillance, and emergency response [3]. The integration of UAVs with the Internet of Things (IoT), often referred to as the Internet of Drones (IoD), has further augmented their utility, enabling more sophisticated and interconnected applications. This facilitates advanced use cases like smart city infrastructure management, environmental monitoring, and disaster response. By harnessing the capabilities of IoT devices, UAVs can perform real-time data analysis and autonomous operations, contributing to a smarter and more responsive network ecosystem. Their growing deployment in both civilian and industrial contexts reflects their versatility and potential for streamlining operations and enhancing decision-making capabilities.

However, the interconnected nature of IoD systems introduces new and complex security challenges [4]. The integration of UAVs with IoT devices creates a broader attack surface, making these systems vulnerable to various cybersecurity threats, including unauthorized access, data breaches, and sophisticated network attacks such as Man-in-the-Middle (MitM) and Denial of Service (DoS) [5,6]. According to the 2023 ThreatLabz report, IoT-targeted cyber attacks have grown by 400% compared to 2022 [7]. The situation is exacerbated by the inherent constraints of IoT devices, such as limited computational power and memory, which restrict the application of conventional security mechanisms. Moreover, the wireless communication channels utilized by UAVs are particularly susceptible to eavesdropping and signal interference, further increasing the risk of data breaches and malicious attacks.

To address these vulnerabilities, lightweight authentication schemes have been proposed [8], focusing on reducing computational and communication overhead while ensuring the scalability and responsiveness of the IoD systems. The challenge lies in developing robust security protocols that can provide efficient authentication and data integrity without imposing significant performance burdens, especially given the resource-constrained nature of many IoT devices and UAVs. Traditional centralized authentication approaches, which rely on a single trust authority (TA), present additional limitations, including a single point of failure and challenges in maintaining data privacy and control. These centralized systems are particularly vulnerable to attacks that can compromise the entire network if the central server is breached. In contrast, the adoption of decentralized technologies such as blockchain can help mitigate these risks [9,10]. Blockchain’s decentralized ledger provides a tamper-resistant mechanism for secure data exchange, eliminating the need for a central authority and enhancing data privacy. By distributing control across multiple nodes, blockchain technology increases the flexibility and resilience of the IoD network, making it better suited to handle dynamic and evolving threats. Figure 1 illustrates the structure of blockchain-assisted multi-server IoD environments. However, there are several constraints and challenges that need to be addressed when utilizing blockchain. One persistent issue is the scalability problem, as an increase in the number of blockchain nodes inherently leads to greater computational overhead and latency. The issues of latency and energy consumption are particularly critical when deploying blockchain networks with resource-constrained IoT devices and drones [11], as an increase in the number of blockchain nodes inherently results in higher computational overhead and increased latency. Furthermore, requiring the additional nodes to transmit and process the necessary information can result in low energy efficiency.

In 2023, Wang et al. [12] proposed a blockchain-based lightweight authentication protocol in IoD. However, we found that their scheme was vulnerable to drone impersonation and session key disclosure attacks. Furthermore, the scheme failed to provide validity of login and key agreement. In this paper, we propose a lightweight authentication scheme for blockchain-assisted multi-server IoD environments. Our protocol addresses the identified security gaps in existing schemes by using physical unclonable functions (PUFs) and blockchain technology. The proposed scheme minimizes the growth of data volume and computational load as the number of users increases. As a result, our protocol maintains a minimal impact on overall system performance, ensuring its suitability for resource-constrained IoT and drone networks, even in large-scale deployments. The proposed scheme provides strong mutual authentication, data integrity, and confidentiality while minimizing computational and communication costs. To validate the security of our protocol, we employ formal methods such as the Real-Or-Random (RoR) model and BAN logic. Comparative performance evaluations also demonstrate the efficiency and suitability of our protocol for resource-constrained IoT applications, making it a viable solution for secure and scalable IoD networks.

1.1. Our Contributions

The primary goal of our research is to design a lightweight and secure authentication scheme for blockchain-assisted multi-server IoD environments. It is crucial to develop protocols that enhance security while also optimizing performance to meet the resource constraints of IoT devices. In response to this need, we present an Authenticated Key Agreement (AKA) protocol that addresses the limitations of existing schemes while introducing improvements in both security and efficiency. The key contributions of our proposed scheme are detailed as follows:

(1)

We provide a thorough review of Wang et al.’s protocol, discussing the attacks it has been found vulnerable to and the security weaknesses it exhibits.

(2)

We propose a lightweight and secure protocol that addresses the vulnerabilities identified in Wang et al.’s scheme while being more suitable for blockchain-assisted multi-server IoD environments.

(3)

We validate our proposed protocol through formal analysis using widely accepted methods such as RoR and Ban logic, as well as informal analysis, to ensure it meets essential security requirements within the threat model. Furthermore, we evaluate its efficiency by comparing computation and communication costs with other relevant studies, demonstrating its suitability for IoD environments.

1.2. Organization of This Article

In Section 2, we discuss existing research on security protocols in UAV communication environments. Section 3 introduces preliminaries to aid in the understanding of this paper. Next, in Section 4, we provide a comprehensive review and cryptanalysis of Wang et al.’s protocol, highlighting its security issues. In Section 5, we propose a new protocol that addresses the security weaknesses of Wang et al.’s protocol. Section 6 presents a security analysis of the proposed protocol, and performance analyses, i.e., communication and computation costs, are shown in Section 7. Finally, Section 8 concludes the paper and discusses future research directions.

2. Related Works

Despite the numerous benefits of IoD environments, securing the communication remains a significant challenge due to the inherent vulnerabilities of wireless communication channels and the resource constraints of IoT devices. In response, extensive research has focused on developing efficient and secure authentication protocols.

2.1. Lightweight Authentication Protocols for IoD

The concept of lightweight cryptographic protocols has gained traction in the IoD domain due to the limited computational resources of UAVs and IoT devices. In 2019, Wazid et al. [13] introduced a lightweight mutual authentication scheme utilizing XOR operations and one-way hash functions. Their protocol incorporated a three-factor login system with fuzzy extractors, leveraging biometric information to enhance security. However, cryptanalysis revealed vulnerabilities such as user impersonation and privileged insider attacks, which compromised the scheme’s effectiveness in real-world scenarios. Similarly, Srinivas et al. [14] presented an IoD authentication protocol that utilized fuzzy extractors and aimed to provide three-factor security. While the protocol reduced computation costs, it suffered from scalability issues and was later found to be vulnerable to impersonation attacks and session key leakage by Ali et al. [15]. They also proposed a similar scheme with a focus on biometric-based authentication, but it failed to address issues of server spoofing and session key disclosure. In 2020, Zhang et al. [16] proposed a lightweight protocol characterized by low computation and communication costs, asserting its safety against various attacks. However, Hussain et al. [17] discovered that Zhang et al.’s protocol was vulnerable to privileged insider attacks, impersonation attacks on servers, drones, and users, and it failed to guarantee mutual authentication. Additionally, it was found to be susceptible to replay and DoS attacks.

2.2. ECC-Based Authentication Protocols for IoD

Hussain et al. [18] proposed a protocol for ECC-based IoD environments using a three-factor approach. They claimed that the protocol achieved a reasonable balance between security and efficiency. However, Wu et al. [19] reported that the protocol by Hussain et al. was vulnerable to drone capture attacks, privileged insider attacks, and session key disclosure attacks. Additionally, Zhang et al. [20] identified further issues related to impersonation attacks and session key exposure. In the same year, Chaudhry et al. [21] introduced a protocol using ECC and hash functions. However, Das et al. [22] revealed that this protocol was vulnerable to impersonation attacks on drones and servers and to ephemeral secret leakage (ESL) attacks. In 2022, Tanveer et al. [23] incorporated advanced cryptographic primitives like Authenticated Encryption with Associated Data (AEAD) and Elliptic Curve Digital Signature Algorithm (ECDSA). Despite the enhanced security features, these protocols often suffer from high computational costs and limited scalability, making them less suitable for large-scale IoD deployments. Furthermore, these schemes do not fully address the anonymity and untraceability requirements.

2.3. Blockchain-Based Authentication Protocols for IoD

In 2020, Beral et al. [24] introduced a protocol utilizing blockchain technology in IoD environments. They claimed the protocol’s efficiency and stability by employing ECC encryption techniques. However, in 2021, Chaudhry et al. [21] criticized Beral et al.’s protocol for having high computation and communication costs unsuitable for IoD, and for being vulnerable to drone impersonation, man-in-the-middle attacks, replay attacks, and failing to ensure anonymity. In the same year, Irshad et al. [25] proposed an ECC-based data delivery and collection scheme using blockchain. However, their scheme has weaknesses such as key escrow, lack of unlinkability, and cross-domain authentication. In 2022, Feng et al. [26] proposed a blockchain-based cross-domain authentication scheme. They employed multiple signatures based on threshold sharing to provide reliable communication between cross-domain devices. Unfortunately, they failed to achieve perfect forward secrecy (PFS) and anonymity properties, including vulnerability to ESL attacks.

These studies and their findings are summarized in

Table 1. Cryptographic technologies and properties of the related schemes for IoD environments.

Scheme	Cryptographic Primitives	Contributions	Limitations
Wazid et al. [13]	XORHash functionFuzzy extractor	Lightweight authentication Three-factor security	Vulnerable to various attacks including user impersonation, device impersonation, stolen verifier attack Lack of user untraceability
Srinivas et al. [14]	XORHash functionFuzzy extractor	Lightweight authentication Three-factor security	Vulnerable to various attacks including impersonation attack, stolen verifier attack Lack of user untraceability and scalability
Ali et al. [15]	Symmetric keyHash functionFuzzy extractor	Three-factor security	Vulnerable to various attacks including server spoofing, forgery, session key disclosure attack
Zhang et al. [16]	XORHash function	Lightweight authentication Low computation and communication cost	Vulnerable to various attacks including privileged insider attack, drone impersonation attack, parallel session key attack, reply attack, DoS attack Lack of mutual authentication
Hussain et al. [18]	ECCSymmetric keyHash function	Three-factor security	Vulnerable to various attacks including drone impersonation, session key leakage attack, privileged insider attack, drone capture attack
Tanveer et al. [23]	ECCAEADECDSA	Protected against various attacks	Lack of drone anonymity, drone capture attack High computation and communication cost; low efficiency for drone communications
Bera et al. [24]	ECCSymmetric keyBlockchain	Drone-to-drone/drone-to-station authentication Blockchain-based access control	Vulnerable to various attacks including drone impersonation attack, replay attack, lack of anonymity High computation and communication cost
Chaundhry et al. [21]	ECCSymmetric keyCertificate	Drone-to-drone/drone-to-station authentication Certificate-based access control	Vulnerable to various attack including drone impersonation, impersonation attack, ESL attack
Irshad et al. [25]	ECCSymmetric keyBlockchain	Blockchain-based access control	Lack of key escrow and cross-domain authentication Unlinkability
Feng et al. [26]	ECCThreshold sharingBlockchain	Cross-domain authentication	Vulnerable to ESL attacks Lack of PFS and ESL

. The review of the existing research indicates a persistent trade-off between security, efficiency, and scalability in current authentication protocols for IoD environments. Many of the proposed schemes either achieve high security at the expense of increased computational overhead or focus on lightweight designs that fail to provide comprehensive protection against emerging threats. Notably, the challenges of ensuring mutual key agreement, protecting against drone capture attacks, and maintaining anonymity remain inadequately addressed. Additionally, the reliance on centralized trust authorities (TAs) in several protocols introduces a single point of failure, undermining the overall resilience of the network.

Our proposed scheme seeks to bridge these gaps by introducing a decentralized, lightweight authentication protocol for blockchain-assisted IoD environments that leverages a combination of PUFs and robust cryptographic techniques. By addressing the identified weaknesses and incorporating advanced security features, our protocol aims to provide a balanced solution that ensures both high security and efficient performance.

3. Preliminary

In this preliminary section, we will introduce and explain the foundational concepts necessary for a comprehensive understanding of the subsequent material.

3.1. Physical Unclonable Function

A PUF is a security mechanism that leverages unique, random variations in physical devices to generate a “fingerprint” or trust anchor. These variations are typically found in manufacturing processes and are impossible to replicate, making PUFs ideal for creating a unique identifier for each device. PUFs follow a straightforward structure, producing a deterministic response (R) to a given input challenge (C), expressed mathematically as follows:

$$\begin{array}{c}\hfill R\in {\{0,1\}}^k=PUF(C\in {\{0,1\}}^k)\end{array}$$

(1)

While the manufacturing process for integrated circuits (ICs) is uniform, each IC exhibits slight, random variations due to inherent physical factors, making it impossible to create identical ICs [27,28]. This uncontrollable randomness ensures that each PUF generates a unique response to the same challenge. However, because PUFs are deterministic one-way functions, the same PUF will always return the same response for a given challenge. Consequently, the Hamming distance ($HD$) between the responses of $PU{F}_1$ to different challenges, $C_a$ and $C_b$, can be used to measure their difference and is typically greater than a defined error tolerance (e):

$$\begin{array}{c}\hfill Pr[HD(PU{F}_1\left(C_a\right),PU{F}_1\left(C_b\right))>e]=1-\epsilon \end{array}$$

(2)

Likewise, the response comparison between two different PUFs, $PU{F}_1$ and $PU{F}_2$, to the same challenge $Ca$, follows

$$\begin{array}{c}\hfill Pr[HD(PU{F}_1\left(C_a\right),PU{F}_2\left(C_a\right))>e^{\prime }]=1-\epsilon \end{array}$$

(3)

In this paper, PUFs are leveraged to strengthen Wang et al.’s scheme by addressing physical attacks on drones. To safeguard stored information on compromised drones, each drone receives a series of challenge values from the connected server during the registration process. This approach enhances security while also mitigating the risk of key compromise in scenarios involving physical tampering or device capture.

3.2. Blockchain

Blockchain records transactions through a decentralized and distributed ledger made up of multiple nodes, ensuring the integrity and transparency of the data without the need for a central authority [29]. Blockchain can be categorized into public blockchain, private blockchain, and consortium blockchain based on their governance system. In a public blockchain, anyone can participate in the consensus process in a public environment without the need for an administrator, and no permission is required. Additionally, anyone can validate transactions, and no special authorization is needed to read transaction data. In contrast, a private blockchain is managed by a single owner who oversees the consensus process. Only authorized nodes can act as validators to verify transactions. Moreover, the reading rights of transactions can either be unrestricted for anyone or limited to predefined nodes with permission. Lastly, a consortium blockchain is similar to a private blockchain in that only preselected nodes function as validators and data reading rights can be selectively granted. However, it differs in its management structure; a consortium blockchain is governed by multiple owners with decentralized control across different hardware, rather than being managed by a single owner. In IoD environments, a public blockchain can gurantee decentralization. However, it can impose a high storage burden on users and drones, which can reduce network efficiency in practical environments. Although a private blockchain can guarantee network efficiency compared to the public blockchain, it is centralized and can have single-point-of-failure problems. Therefore, in this paper, we utilize consortium blockchain to ensure both data integrity and decentralization and it can be suitable for practical IoD environments.

3.3. Threat Model

We employed the Dolev–Yao (DY) attack model, which is widely utilized in numerous studies, such as those by [23,30], to assess the security of schemes. Using the assumptions of the DY model, we defined the capabilities of the adversary A and conducted attacks on both Wang et al.’s scheme and our proposed scheme.

(1)

According to the DY model, none of the entities participating in the communication can be trusted, and the communication channels are considered insecure. Therefore, adversary A is assumed to have the capability to compromise drones, users, and even connected servers.

(2)

The adversary can eavesdrop on, modify, delay, or delete messages transmitted over the communication channels.

(3)

Adversary A can hijack a legitimately registered drone and perform physical analysis attacks to extract credentials stored in its internal memory. Similarly, A can seize IoT devices such as user’s mobile devices to obtain information stored during the registration process.

(4)

Adversary A can access information stored in the blockchain network. However, A does not have the authority to modify or delete this information.

3.4. System Model

In this paper, the blockchain layer of the proposed protocol’s system model is composed of a consortium blockchain. In a realistic industry setting, using blockchain in an untrusted environment presents certain limitations for public blockchains [31]. To protect sensitive information about users or drones in a blockchain-assisted UAV environment, an elevated degree of trust in the management system is required. A consortium blockchain, wherein preselected servers that render services to users participate as validators, significantly enhances the system’s trustworthiness. Furthermore, it offers higher transaction throughput compared to public blockchains, while providing a decentralized infrastructure, ensuring a more pleasant user experience. The detailed system model is outlined below and is illustrated in Figure 2.

(1)

Connected Server $C{S}_k$: The connected servers exist in the form of a consortium blockchain. Pre-selected servers possess shared secret parameters and manage the registration information of users and drones. It is assumed that the servers are semi-trusted, and external entities can access the information stored on the blockchain.

(2)

User’s IoT devices $U_j$: The user first undergoes the registration process through the nearest connected server, $C{S}_k$. Through this process, the user’s registration information is stored on the blockchain and later used during the session key agreement process with the drone the user intends to operate. It is assumed that the user is untrusted, with the possibility of malicious users or exposure of stored information.

(3)

Drone $D{R}_i$: The drone registers its information through the connected server responsible for its service area via the registration process. It is assumed that the drone is untrusted, with the possibility of malicious drones or exposure of stored information.

(4)

Blockchain: The consortium blockchain is maintained by connected servers. The blockchain is initialized by system administrator in the setup phase. Users can read and access the blockchain, yet do not have the ability to upload transactions or participate in consensus.The blockchain stores registration information of drones and users, and all transactions are uploaded after practical byzantine fault tolerance (PBFT) consensus of the connected servers that keep the blockchain.

3.5. Notation

Notations used throughout this paper are shown in

Table 2. Notations.

Notation	Meaning
$D{R}_i$	$i_{th}$ Drone
$U_j$	$j_{th}$ User
$C{S}_k$	$k_{th}$ Connected Server
$x_{C{S}_k}$	Shared secret key between $CS$
$r_1,r_2,r_3,r_4,r_5$	Random numbers
$RT{S}_{D{R}_i},RT{S}_{U_j}$	Registration time stamp of $D{R}_i,U_j$
$PI{D}_{D{R}_i},PI{D}_{U_j}$	Pseudonym ID of $D{R}_i,U_j$

.

4. Overview and Cryptanalysis of Wang et al.’s Scheme

This section provides an overall review of Wang et al.’s scheme. We then explain the vulnerabilities we identified through cryptanalysis. A total of five security weaknesses were discovered, including drone impersonation, session key disclosure, key agreement failure, an invalid login phase, and concerns regarding session key security.

4.1. Overview

In this section, we briefly review the process of Wang et al.’s lightweight blockchain-enhanced mutual authentication protocol. Before executing the following processes, the system setup phase initializes the blockchain and adjusts parameters such as the hash function $h(·)$ and the range of the random nonce $r_i$. Although Wang et al.’s system model does not clearly specify which blockchain is used, it states that established platforms like Ethereum and EOS are used for system stability.

4.1.1. Drone Registration Phase

All drones $D{R}_i$ undergo the following registration process on the blockchain network through a connected server:

(1)

$C{S}_k$: Select a random nonce $r_1$ and identity $I{D}_{D{R}_i}$ for $D{R}_i$. Compute pseudo-identities for $D{R}_i$ and $C{S}_k$ as $PI{D}_{D{R}_i}=h(I{D}_{D{R}_i}\Vert r_1)$ and $PI{D}_{C{S}_k}=h(I{D}_{C{S}_k}\Vert r_1)$. Then, use the registration timestamp $RT{S}_{D{R}_i}$ to generate an ephemeral credential as $E{C}_{D{R}_i}=h(I{D}_{D{R}_i}\Vert r_1\Vert RT{S}_{D{R}_i})$. Upload $\{I{D}_{D{R}_i},PI{D}_{D{R}_i},E{C}_{D{R}_i},PI{D}_{C{S}_k}\}$ to the SC.

(2)

$D{R}_i$: Receive $\left\{I{D}_{D{R}_i},PI{D}_{D{R}_i},E{C}_{D{R}_i},PI{D}_{C{S}_k}\right\}$ from $C{S}_k$ through security channel, and store them to its memory.

4.1.2. User Registration Phase

All users $U_j$ undergo the following registration process on the blockchain network through a connected server:

(1)

$U_j$: Select its own identity $I{D}_{U_j}$ and password $P{W}_{U_j}$, and choose a random nonce $r_2$. Then, compute $RP{W}_{U_j}=h(P{W}_{U_j}\Vert r_2\Vert I{D}_{U_j})$ and send $\{I{D}_{U_j},RP{W}_{U_j}\}$ to $C{S}_k$ through a secure channel.

(2)

$C{S}_k$: After receiving the registration data, $C{S}_k$ chooses a random nonce $r_3$ for $U_j$. Subsequently, it computes pseudo-identities for the user and server as $PI{D}_{U_j}=h(I{D}_{U_j}\Vert r_3)$ and $PI{D}_{C{S}_k}=h(I{D}_{C{S}_k}\Vert r_3)$. Finally, it uses the registration timestamp to create an ephemeral credential as $E{C}_{U_j}=h(I{D}_{U_j}\Vert r_3\Vert RT{S}_{U_j}\Vert RP{W}_{U_j})$ and uploads $\{I{D}_{U_j},PI{D}_{U_j},E{C}_{U_j},PI{D}_{C{S}_k}\}$ to the SC.

(3)

$C{S}_k$: The server gathers the following computed information and sends it to the user: $\{I{D}_{U_j},PI{D}_{U_j},E{C}_{U_j},PI{D}_{C{S}_k},LPI{D}^{allD{R}_i}\}$. Here, $LPI{D}^{allD{R}_i}$ is a list of pseudo identities of currently available registered drones.

(4)

$U_j$: The user’s device stores the information $\{I{D}_{U_j},PI{D}_{U_j},E{C}_{U_j},PI{D}_{C{S}_k},LPI{D}^{allD{R}_i}\}$ in its memory.

4.1.3. AKA Phase with User Login

All users $U_j$ undergo the following registration process on the blockchain network through a connected server.

(1)

$U_j$: The user inputs their login information, $I{D}_{U_j}$ and $P{W}_{U_j}$. To authenticate the user for login, the user’s device computes $RP{W}_{U_j}^{*}=h(P{W}_{U_j}\Vert r_2\Vert I{D}_{U_j})$ and compares it with the stored $RP{W}_{U_j}$ to verify the user’s identity.

(2)

$U_j$: The user computes the following messages using the stored information and sends them through a public channel along with the timestamp $T{S}_1$: $M_1=h(PI{D}_{C{S}_k}\Vert T{S}_1)\oplus PI{D}_{Ui}$, $M_2=h(PI{D}_{U_j}\Vert PI{D}_{C{S}_k}\Vert E{C}_{U_j}\Vert T{S}_1)\oplus PI{D}_{D{R}_i}$, $M_3=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert E{C}_{U_j}\Vert T{S}_1)$.

(3)

$C{S}_k$: Upon receiving $\{M_1,M_2,M_3,T{S}_1\}$, $C{S}_k$ executes the following steps in the $UserAuth$ function of the $SC$. First, it verifies the validity of $T{S}_1$. Then, it calculates $PI{D}_{U_j}=M_1\oplus h(PI{D}_{C{S}_k}\Vert T{S}_1)$ and $PI{D}_{D{R}_i}=M_2\oplus h(PI{D}_{U_j}\Vert PI{D}_{C{S}_k}\Vert E{C}_{U_j}\Vert T{S}_1)$. Using these calculated values, it generates $M_3^{*}=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert E{C}_{U_j}\Vert T{S}_1)$ and compares it with the received $M_3$ to authenticate the user.

(4)

$C{S}_k$: If the user is authenticated, the $DroneAuth$ function selects a random nonce $r_4$ and computes the user’s new ephemeral credential as $E{C}_{U_j}^{NEW}=h(E{C}_{U_j}\Vert r_4)$. It then generates the following messages: $M_4=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert T{S}_2)\oplus PI{D}_{U_j}$, $M_5=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\oplus r_4$, $M_6=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\oplus E{C}_{U_j}^{NEW}$, $M_7=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2\Vert E{C}_{U_j}^{NEW})$. These messages, along with the current timestamp $T{S}_2$, are sent to $D{R}_i$ via an open channel.

(5)

$D{R}_i$: Upon receiving the message, the drone $D{R}_i$ verifies the validity of the timestamp $T{S}_2$ and then performs the following calculations: $PI{D}_{U_j}=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert T{S}_2)\oplus M_4$, $r_4=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\oplus M_5$, $E{C}_{U_j}^{NEW}=M_6\oplus h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)$ and $M_7^{*}=h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2\Vert E{C}_{U_j}^{NEW})$.

(6)

$D{R}_i$: After completing these calculations, it compares the received $M_7$ with the generated $M_7^{*}$ for verification. If the verification is successful, it generates the session key $S{K}_{D{R}_i-U_j}$ between $D{R}_i$ and $U_j$ as follows: $S{K}_{D{R}_i-U_j}=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert r_4\Vert E{C}_{U_j}^{NEW}\Vert T{S}_3)$. Finally, it generates the following messages along with the current timestamp $T{S}_3$ and sends them to $U_j$: $M_8=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_3)\oplus r_4$, $M9={(S{K}_{D{R}_i-U_j}\oplus T{S}_3)}^{64bits}$.

(7)

$U_j$: Upon receiving the message from the drone, the user verifies the validity of the timestamp $T{S}_3$ and obtains $r_4$ using the following calculation:$r_4=M_8\oplus h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_3)$. Finally, the user generates the session key $S{K}_{D{R}_i-U_j}$ by computing $S{K}_{D{R}_i-U_j}=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert r_4\Vert E{C}_{U_j}^{NEW}\Vert T{S}_3)$. The user then verifies the session key by checking ${(S{K}_{D{R}_i-U_j}\oplus T{S}_3)}^{64bits}\stackrel{?}{=}{M}_9$.

4.2. Cryptanalysis

4.2.1. Drone Impersonation Attack

Wang et al. [12] claimed that their scheme is resilient to drone impersonation attacks and session key disclosure. However, our analysis reveals that an adversary can successfully impersonate a legitimate drone and derive the session key by leveraging information obtained from a compromised drone through the following method.

By analyzing the internal structure and characteristics of the UAV’s hard chip, A can extract crucial parameters related to the stored system or attempt additional security attacks [32]. Therefore, in this case, the attacker can obtain the following values stored within the drone: $\{I{D}_{D{R}_i},PI{D}_{D{R}_i},E{C}_{D{R}_i},PI{D}_{C{S}_k}\}$. Subsequently, A can eavesdrop on $\{M_4,M_5,M_6,M_7,T{S}_2\}$ from the open channel and calculate $\{PI{D}_{U_j}$, $r_4$, $E{C}_{U_j}^{NEW}\}$ from the messages by the following computations:

$$\begin{array}{ccc}\hfill PI{D}_{U_j}& =& M_4\oplus h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert T{S}_2)\hfill \end{array}$$

(4)

$$\begin{array}{ccc}\hfill r_4& =& M_5\oplus h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\hfill \end{array}$$

(5)

$$\begin{array}{ccc}\hfill E{C}_{U_j}^{NEW}& =& M_6\oplus h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\hfill \end{array}$$

(6)

Since the values stored in the drone are not encrypted or otherwise protected, an attacker who seizes the drone can easily compute the above values. With these computed values, adversary A can then derive the session key $S{K}_{D{R}_i-U_j}$, and subsequently generate message $M_8$, $M_9$ by the following computations:

$$\begin{array}{ccc}\hfill S{K}_{D{R}_i-U_j}& =& h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert r_4\Vert E{C}_{U_j}^{NEW}\Vert T{S}_3)\hfill \end{array}$$

(7)

$$\begin{array}{ccc}\hfill M_8& =& h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_3)\oplus r_4\hfill \end{array}$$

(8)

$$\begin{array}{ccc}\hfill M_9& =& {(S{K}_{D{R}_i-U_j}\oplus T{S}_3)}^{64bits}\hfill \end{array}$$

(9)

Therefore, the attacker can use the information obtained from the compromised drone to create and send valid messages $M_8$ and $M_9$ to the user. This enables the attacker to deceive the user into believing they are communicating with a legitimate drone. Additionally, the attacker can calculate the session key and disclose it externally, posing security threat.

4.2.2. Session Key Disclosure

As demonstrated in the above attack, it was confirmed that hijacking a drone can lead to session key disclosure. However, adversary A can also compute the session key between user $U_j$ and drone $D{R}_i$ using information posted on the blockchain network. Adversary A can obtain the values of User $U_j\{PI{D}_{U_j},PI{D}_{C{S}_k},E{C}_{U_j}\}$ and Drone $DR\left\{E{C}_{D{R}_i}\right\}$ stored on the blockchain and intercept messages $M_1$, $M_5$, and $M_6$ communicated over the open channel. Using these values, A can compute $PI{D}_{D{R}_i}$, $r_4$, and $E{C}_{U_j}^{new}$ through the following equations:

$$\begin{array}{ccc}\hfill PI{D}_{D{R}_i}& =& M_1\oplus h(PI{D}_{U_j}\Vert PI{D}_{C{S}_k}\Vert E{C}_{U_j}\Vert T{S}_1)\hfill \end{array}$$

(10)

$$\begin{array}{ccc}\hfill r_4& =& M_5\oplus h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\hfill \end{array}$$

(11)

$$\begin{array}{ccc}\hfill E{C}_{U_j}^{NEW}& =& M_6\oplus h(E{C}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert T{S}_2)\hfill \end{array}$$

(12)

Ultimately, adversary A can compute session key SK, thereby deriving the session key between User U and the target Drone DR as follows:

$$\begin{array}{ccc}\hfill S{K}_{D{R}_i-U_j}& =& h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert PI{D}_{C{S}_k}\Vert r_4\Vert E{C}_{U_j}^{NEW}\Vert T{S}_3)\hfill \end{array}$$

(13)

Due to this potential security threat, [33] recommended that all information uploaded to the blockchain network should be encrypted as ciphertext. Studies such as [9,34,35] also advocate for limiting the information posted on the blockchain or using cryptographic techniques like ECC to safeguard the data. Wang et al.’s scheme did not consider the potential for such risks, resulting in the exposure of the session key.

4.2.3. Key Agreement Failure

Upon scrutinizing the registration procedures for both the drone and the user, distinct $PI{D}_{CS}$ are generated in each process. In the drone registration phase, a random nonce $r_1$ created by the connected server is utilized to produce $PI{D}_{C{S}_k}$. Conversely, in the user registration sequence, a different random nonce $r_3$ is employed to formulate $PI{D}_{C{S}_k}$. These uniquely generated $PI{D}_{C{S}_k}$ are subsequently employed in the authentication process and are directly utilized to generate the session key $S{K}_{D{R}_i-U_j}$.

$$\begin{array}{ccc}\hfill PI{D}_{C{S}_k}& =& h(I{D}_{C{S}_k}\Vert r_1)\hfill \end{array}$$

(14)

$$\begin{array}{ccc}\hfill PI{D}_{C{S}_k}& =& h(I{D}_{C{S}_k}\Vert r_3)\hfill \end{array}$$

(15)

However, since the disparate $PI{D}_{C{S}_k}$ values for the drone and the user are used directly to generate the session key without being shared, the two entities ultimately derive different session keys. Consequently, Wang et al.’s scheme fails in achieving key agreement.This implies that secure communication between the two entities is not possible, thus compromising the reliability of the security system.

4.2.4. Invalid Login Phase

When the user initially registers their information, they store the following details on their IoT device for future login processes: $\{RP{W}_{U_j},I{D}_{U_j},PI{D}_{U_j},E{C}_{U_j},PI{D}_{C{S}_k},LPI{D}^{allD{R}_i}\}$. During the subsequent login process, the user calculates $RP{W}_{U_j}^{*}=h(P{W}_{U_j}\Vert r_2\Vert I{D}_{U_j})$ and checks if $RP{W}_{U_j}^{*}\stackrel{?}{=}RP{W}_{U_j}$ to verify the validity of the login attempt. However, since the $r_2$ used in generating $RP{W}_{U_j}^{*}$ is not stored on the user’s device and there is no method to regenerate the randomly created value from the registration process, it is impossible to produce the valid $RP{W}_{U_j}^{*}$ for comparison. Therefore, in Wang et al.’s scheme, the user cannot successfully log in.

4.2.5. Session Key Security Concerns

Based on the hash function length, the SK used in Wang et al.’s scheme is 160 bits. At the end of the scheme, Drone DR sends $M9$ as a validation message to user U over an open channel. $M9$ consists of the first 64 bits of the XOR result of the completed $SK$ and the public $TS$ value. Consequently, eavesdropping adversary A can calculate the first 64 bits of $SK$. While this reduces communication costs due to shorter messages, it simultaneously lowers the security of the session key by reducing its undisclosed length.

This approach poses a significant security risk. By disclosing the first 64 bits of the session key, the adversary’s task of guessing or brute-forcing the remaining 96 bits becomes considerably easier. This reduction in the effective key length drastically decreases the overall strength of the encryption, making it more susceptible to attacks.

5. Proposed Scheme

This section provides a detailed explanation of the proposed protocol. The protocol consists of five phases, starting with the setup phase. Following this, the user and drone registration processes take place, after which the authentication and key agreement phase is executed between the user and the drone that the user wishes to access. Finally, a drone revocation phase is included, if required. The smart contract used in the proposed scheme is shown in Algorithm 1.

Algorithm 1. Update Smart Contract

Input: $\{PID,E{C}^T,R,RTS\}$

Output: bool

struct$BC\{$

32 bit $PID$

32 bit $E{C}^T$

160 bit $Random$

DateTime $RTS$

$\left\}StructBC\right[]BC$

if $msg.sender!=CS$ then

return false;

else

for $i=1;i\le BC.size\left(\right);i++$ do

if $BC\left[\right].PID=PID$ then

Function $Update\_SC(PID,E{C}^T,R,RTS)$;

return true;

end if

else for

if $i>BC.size\left(\right)$ then

Function $Create\_SC(PID,E{C}^T,R,RTS)$

return true;

end if

end if

5.1. Setup Phase

In the system setup phase, the system administrator generates some parameters for the proposed scheme and initial blockchain. These parameters include public and private parameters like long-term secret key $x_{cs}$, one-way collision-resistant hash function $h(·)$, and range for random number r, where $x_{cs}$ is shared by all connected servers (CSs).

5.2. Drone Registration

(1)

$C{S}_k$: Choose the identity $I{D}_{D{R}_i}$ of $D{R}_i$. Next, select a random nonce $r_1$ and a challenge $C{C}_i$. We recommend the use of a strong PUF for enhanced security and have therefore assumed the length of $C{C}_{D{R}_i}$ to be at least 32 bits. Calculate the pseudonym ID of $D{R}_i$ as $PI{D}_{D{R}_i}=h(I{D}_{Dj}\Vert RT{S}_{D{R}_i})$ using the registration timestamp $RT{S}_{D{R}_i}$. Then, compute $E{C}_{D{R}_i}=h(I{D}_{D{R}_i}\Vert x_{C{S}_k}\Vert r_1\Vert RT{S}_{D{R}_i})$ and $E{C}_{D{R}_i}^T=E{C}_{D{R}_i}\oplus h(x_{C{S}_k}\Vert RT{S}_{D{R}_i})$. Use the calculated values $\{PI{D}_{D{R}_i},E{C}_{D{R}_i}^T,r_1,RT{S}_{D{R}_i}\}$ to invoke Algorithm 1 and register the information of $D{R}_i$ on the blockchain. Finally, transmit $\left\{I{D}_{D{R}_i},C{C}_i,E{C}_{D{R}_i}\right\}$ to $D{R}_i$ through a secure channel.

(2)

$D{R}_i$: Using the received challenge $C{C}_{D{R}_i}$, obtain the value of $C{R}_{D{R}_i}=\mathit{PUF}\left(C{C}_{D{R}_i}\right)$. Then, calculate $Cer{t}_{D{R}_i}=E{C}_{D{R}_i}\oplus h(C{R}_{D{R}_i}\Vert I{D}_{D{R}_i})$. Finally, store $I{D}_{D{R}_i},Cer{t}_{D{R}_i}$, $C{C}_{D{R}_i}$ in memory.

5.3. User Registration

(1)

$U_j$: Choose identity $I{D}_{U_j}$ and password $P{W}_{U_j}$. Then, use these values to compute $RP{W}_{U_j}=h(I{D}_{U_j}\Vert P{W}_{U_j})$ and send the registration message $I{D}_{U_j}$.

(2)

$C{S}_k$: Verify whether the received $I{D}_{U_j}$ is a new identity, and if so, proceed with the following steps. First, select a random nonce $r_2$. Calculate the pseudonym identity $PI{D}_{U_j}$ as $PI{D}_{U_j}=h(I{D}_{U_j}\Vert RT{S}_{U_j}\Vert x_{C{S}_k})$. Next, compute $E{C}_{U_j}=h(PI{D}_{U_j}\Vert RT{S}_{U_j}\Vert r_2\Vert x_{C{S}_k})$ and $E{C}_{U_j}^T=E{C}_{U_j}\oplus h(x_{C{S}_k}\Vert RT{S}_{U_j})$. Use the calculated values $\{PI{D}_{U_j},E{C}_{U_j}^T,r_2,RT{S}_{U_j}\}$ to invoke Algorithm 1 and store $U_j$’s registration information on the blockchain. Send $\{PI{D}_{U_j},E{C}_{U_j},I{D}_{C{S}_k}\}$ through a secure channel.

(3)

$U_j$: Select a new random nonce $r_3$. Calculate $Cer{t}_{U_j}=E{C}_{U_j}\oplus h(r_3\Vert P{W}_{U_j})$ and store $\{RP{W}_{U_j},PI{D}_{U_j},Cer{t}_{U_j},I{D}_{C{S}_k},r_3\}$ in memory.

5.4. Login and AKA Phase

For users and drones to securely share a session key for communication, they first mutually authenticate through a connected server to verify the legitimacy of their identities. The detailed process is outlined below and is illustrated in Figure 3.

(1)

$U_j$: The user inputs their login information, $I{D}_{U_j}$ and $P{W}_{U_j}$. To authenticate the user for login, the user’s device computes $RP{W}_{U_j}^{*}=h(I{D}_{U_j}\Vert P{W}_{U_j})$ and compares it with the stored $RP{W}_{U_j}$ to verify the user’s identity.

(2)

$U_j$: Calculate $E{C}_{U_j}^{*}=Cer{t}_{U_j}\oplus h(r_3\left|\right|P{W}_{U_j})$; then, select a random nonce $r_4$. Generate the temporary ID $TI{D}_{U_j}=h(E{C}_{U_j}\Vert r_4\Vert PI{D}_{U_j})$ for this communication. Next, compute the messages $M_1,M_2,M_3,V_1$ in the following order: $M_1=(I{D}_{C{S}_k}\Vert T{S}_1)\oplus PI{D}_{U_i}$, $M_2=h(PI{D}_{U_j}\Vert E{C}_{U_j}\Vert T{S}_1)\oplus PI{D}_{D{R}_i}$, $M_3=h(PI{D}_{U_j}\Vert I{D}_{C{S}_k}\Vert E{C}_{U_j}\Vert T{S}_1)\oplus TI{D}_{U_j}$, $V_1=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert E{C}_{U_j}\Vert T{S}_1)$. Generate the timestamp $T{S}_1$ and send $M_1,M_2,M_3,V_1,T{S}_1$ to $C{S}_k$ via an open channel.

(3)

$C{S}_k$: Verify whether the timestamp $T{S}_1$ is valid by checking $|T{S}_1-T{S}_c|\leqq \Delta T$. Calculate $PI{D}_{U_j}=M_1\oplus h(I{D}_{C{S}_k}\Vert T{S}_1)$ and fetch the registration information of $U_j$ from the blockchain using $PI{D}_{U_j}$. Perform the operations $E{C}_{U_j}=E{C}_{U_j}^T\oplus h(x_{C{S}_k}\Vert RT{S}_{U_j})$, $PI{D}_{D{R}_i}=M_2\oplus h(PI{D}_{U_j}\Vert E{C}_{U_j}\Vert T{S}_1)$, and $V_1^{*}=h(PI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert E{C}_{U_j}\Vert T{S}_1)$ in sequence. Verify the message $V_1$ by checking $V_1^{*}\stackrel{?}{=}{V}_1$. If $V_1$ is valid, proceed to the next step.

(4)

$C{S}_k$: Calculate the temporary ID $TI{D}_{U_j}=M_3\oplus h(PI{D}_{U_j}\Vert I{D}_{C{S}_k}\Vert E{C}_{U_j}\Vert T{S}_1)$ for $U_j$. Use $PI{D}_{D{R}_i}$ to fetch the registration information of $D{R}_i$ from the blockchain, with whom $U_j$ wishes to communicate. Compute $C{R}_{D{R}_i}=C{R}_{D{R}_i}^T\oplus h(x_{C{S}_k}\Vert RT{S}_{D{R}_i})$. Finally, generate the message $M_4=h(C{R}_{D{R}_i}\Vert PI{D}_{D{R}_i}\Vert T{S}_2)\oplus TI{D}_{U_j}$, $V_2$ = $h(C{R}_{D{R}_i}$$\Vert PI{D}_{D{R}_i}\Vert TI{D}_{U_j}\Vert T{S}_2)$, and timestamp $T{S}_2$, and send $M_4,V_2,T{S}_2$ to $D{R}_i$ via an open channel.

(5)

$D{R}_i$: Verify whether the timestamp $T{S}_2$ is valid by checking $|T{S}_2-T{S}_c|\leqq \Delta T$. Use the PUF attached to the device and the stored challenge value $C{C}_{D{R}_i}$ to generate the response $C{R}_{D{R}_i}$. Perform the operations $TI{D}_{U_j}=M_4\oplus h(C{R}_{D{R}_i}\Vert PI{D}_{D{R}_i}\left|\right|TI{D}_{U_j}\Vert T{S}_2)$ and $V_2^{*}=h(C{R}_{D{R}_i}\left|\right|PI{D}_{D{R}_i}\left|\right|T{S}_2)$ in sequence, then verify the message $V_2$ by checking $V_2^{*}\stackrel{?}{=}{V}_2$. If $V_2$ is valid, proceed to the next step.

(6)

$D{R}_i$: Select a random nonce $r_5$ and generate the temporary ID $TI{D}_{D{R}_i}=h(C{R}_{D{R}_i}\Vert r_5\Vert$$TI{D}_{U_j})$ for this communication. Next, calculate the session key $S{K}_{D{R}_i-U_j}=h(TI{D}_{U_j}\left|\right|$$TI{D}_{D{R}_i}\Vert T{S}_3)$ and generate the message $M_6=h(TI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert T{S}_3)\oplus TI{D}_{D{R}_i}$, $V_3=h(TI{D}_{U_j}\left|\right|TI{D}_{D{R}_i}\Vert S{K}_{D{R}_i-U_j}\left|\right|PI{D}_{D{R}_i}\Vert T{S}_3)$, and timestamp $T{S}_3$, then send $M_6,V_3,T{S}_3$ to $U_j$ via an open channel.

(7)

$U_j$: Verify whether the timestamp $T{S}_3$ is valid by checking $|T{S}_3-T{S}_c|\leqq \Delta T$. Calculate $TI{D}_{D{R}_i}=M_6\oplus h(TI{D}_{U_j}\Vert PI{D}_{D{R}_i}\Vert T{S}_3)$ and the session key $S{K}_{D{R}_i-U_j}=h(TI{D}_{U_j}\Vert$$TI{D}_{D{R}_i}\Vert T{S}_3)$. Compute $V_3^{*}=h(TI{D}_{U_j}\Vert TI{D}_{D{R}_i}\Vert S{K}_{D{R}_i-U_j}\Vert PI{D}_{D{R}_i}\Vert T{S}_3)$ and verify the message by checking $V_3^{*}\stackrel{?}{=}{V}_3$.

5.5. Drone Revocation Phase

(1)

$C{S}_k$: Choose the $D{R}_i$’s new challenge $C{C}_{D{R}_i}^{new}$ and new $I{D}_{D{R}_i}^{new}$. Then, calculate $PI{D}_{D{R}_i}^{new}=h(I{D}_{Dj}^{new}\Vert RT{S}_{D{R}_i})$, $E{C}_{D{R}_i}^{new}=h(I{D}_{D{R}_i}^{new}\Vert x_{C{S}_k}\Vert r_1\Vert RT{S}_{D{R}_i})$, and $E{C}_{D{R}_i}^{Tnew}=E{C}_{D{R}_i}^{new}\oplus h(x_{C{S}_k}\Vert RT{S}_{D{R}_i})$. Use Algorithm 1 with the information $\{PI{D}_{D{R}_i}^{new}$, $E{C}_{D{R}_i}^{Tnew}\}$ to update the information on the blockchain. Next, send $\{I{D}_{D{R}_i}^{new},C{C}_i^{new},E{C}_{D{R}_i}^{new}\}$ to the drone.

(2)

$D{R}_i$: Using the newly issued challenge $C{C}_{D{R}_i}^{new}$, perform the following operations: $C{R}_{D{R}_i}^{new}=\mathit{PUF}\left(C{C}_{D{R}_i}^{new}\right)$, $Cer{t}_{D{R}_i}^{new}=E{C}_{D{R}_i}^{new}\oplus h(C{R}_{D{R}_i}^{new}\Vert I{D}_{D{R}_i}^{new})$. Finally, update the memory with the new values $\{I{D}_{D{R}_i}^{new},Cer{t}_{D{R}_i}^{new},C{C}_{D{R}_i}^{new}\}$.

6. Security Analysis

6.1. Security Analysis Using AVISPA Tool

AVISPA is a simulation tool for conducting security analysis of communication protocols [36]. This tool is particularly useful in detecting man-in-the-middle attacks, replay attacks, and eavesdropping attacks when verifying the stability of communication processes. AVISPA allows for the creation of security protocol models using the high-level protocol specification language (HLPSL), enabling users to define the behavior of entities and the objectives of the protocol. To perform this security analysis, AVISPA utilizes four back-end engines: (1) On-the-Fly Model-Checker (OFMC), (2) Constraint Logic-based Attack Searcher (CL-AtSe), (3) SAT-based Model Checker (SATMC), and (4) Tree Automata-based Protocol Analyzer (TA4SP). AVISPA automatically simulates potential attack scenarios to assess the protocol’s robustness. AVISPA supports the analysis of a wide range of security protocols, including those used in wireless networks, IoT systems, and blockchain environments.

We conducted AVISPA verification on the mutual authentication and key agreement phase between the drone and the user in our proposed protocol. Figure 4 illustrates the roles of the user and drone as defined in the HLPSL code [37]. The results are shown in Figure 5. Since SATMC and TA4SP do not support bitwise XOR operations, the results are based on the OFMC and CL-AtSe back-ends, shown sequentially. As evidenced by the results, the proposed protocol is confirmed to be secure against replay attacks and man-in-the-middle attacks on both back-ends.

6.2. Formal Security Analysis Using BAN Logic

We perform the BAN logic analysis [38] to prove the correctness of the proposed protocol. The BAN logic analysis is a formal analysis technique that verifies whether the communicating entities have correctly agreed on a session key through their shared keys. We explain the notations used in BAN logic in

Table 3. Notations and meanings in BAN logic.

Notation	Meaning
$c_1,c_2$	Communication entities
$m_1,m_2$	Statements
$c_1|\equiv m_1$	$c_1$ believes $m_1$
$c_1|\sim m_1$	$e_1$ once said $m_1$
$c_1\Rightarrow m_1$	$e_1$ controls $m_1$
$c_1⊲m_1$	$e_1$ receives $m_1$
$\#m_1$	$m_1$ is fresh
${\left\{m_1\right\}}_K$	$m_1$ is encrypted with K
$c_1\stackrel{K}{\leftrightarrow }{c}_2$	$e_1$ and $e_2$ have shared key K

and conduct BAN logic analysis.

1.

Message meaning rule (MMR):

$${\displaystyle \frac{c_1|\equiv c_1\stackrel{K}{\leftrightarrow }{c}_2,c_1⊲{\left\{m_1\right\}}_K}{c_1|\equiv c_2|\sim m_1}}$$

2.

Nonce verification rule (NVR):

$${\displaystyle \frac{c_1|\equiv \#\left(m_1\right),c_1|\equiv c_2|\sim m_1}{c_1|\equiv c_2|\equiv m_1}}$$

3.

Jurisdiction rule (JR):

$${\displaystyle \frac{c_1|\equiv c_2|⟹m_1,c_1|\equiv c_2|\equiv m_1}{c_1|\equiv m_1}}$$

4.

Belief rule (BR):

$${\displaystyle \frac{c_1|\equiv (m_1,m_2)}{c_1|\equiv m_1}}$$

5.

Freshness rule (FR):

$${\displaystyle \frac{c_1|\equiv \#\left(m_1\right)}{c_1|\equiv \#(m_1,m_2)}}$$

6.2.1. Goals

The goals of our scheme in BAN logic analysis are as follows:

• Goal 1: $U_j|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i$
• Goal 2: $U_j|\equiv D_i|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i$
• Goal 3: $D_i|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i$
• Goal 4: $D_i|\equiv U_j|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i$

6.2.2. Assumptions

The BAN logic assumptions of our protocol are as follows:

• $A_1$: $C{S}_k|\equiv \#\left(T{S}_1\right)$
• $A_2$: $D_i|\equiv \#\left(T{S}_2\right)$
• $A_3$: $U_j|\equiv \#\left(T{S}_3\right)$
• $A_4$: $C{S}_k|\equiv U_j\stackrel{E{C}_{U_j}}{\leftrightarrow }C{S}_k$
• $A_5$: $D_i|\equiv C{S}_k\stackrel{C{R}_{D_i}}{\leftrightarrow }{D}_i$
• $A_6$: $U_j|\equiv U_j\stackrel{TI{D}_{U_j}}{\leftrightarrow }{D}_i$
• $A_7$: $U_j|\equiv D_i\Rightarrow (U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i)$
• $A_8$: $D_i|\equiv U_j\Rightarrow (U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i)$

6.2.3. Idealized Forms

To perform the BAN logic analysis, we convert the transmitted messages of the proposed protocol into idealized forms. The idealized forms of the proposed scheme are as follows:

• $M_1$: $U_j\to C{S}_k:[{\{PI{D}_{D_i},TI{D}_{U_j}\}}_{E{C}_{U_j}},T{S}_1,V_1]$
• $M_2$: $C{S}_k\to D_i:[{\{TI{D}_{U_j}\}}_{C{R}_{D_i}},T{S}_2,V_2]$
• $M_3$: $D_i\to U_j:[{\{TI{D}_{D_i}\}}_{TI{D}_{U_j}},T{S}_3,V_3]$

6.2.4. BAN Logic Implementation

The BAN logic implementation of our scheme can be performed as follows:

• S1: $C{S}_k$ receives $M_1$.

  $$C{S}_k⊲[{\{PI{D}_{D_i},TI{D}_{U_j}\}}_{E{C}_{U_j}},T{S}_1,V_1]$$
• S2: The message is encrypted with $E{C}_{U_j}$ and $V_1=h(PI{D}_{U_j}\Vert PI{D}_{D_i}\Vert E{C}_{U_j}\Vert T{S}_1)$. $C{S}_k$ considers the message is from $U_j$ by $A_4$.

  $$S_2:C{S}_k|\equiv U_j|\sim [PI{D}_{D_i},TI{D}_{U_j},T{S}_1,V_1]$$
• S3: $C{S}_k$ assumes that the message is fresh by $A_1$.

  $$S_3:C{S}_k|\equiv \#[PI{D}_{D_i},TI{D}_{U_j},T{S}_1,V_1]$$
• S4: $C{S}_k$ assumes that $U_j$ believes the message by $S_2$ and $S_3$.

  $$S_4:C{S}_k|\equiv U_j|\equiv [PI{D}_{D_i},TI{D}_{U_j},T{S}_1,V_1]$$
• S5: $D_i$ receives $M_2$.

  $$S_5:D_i⊲[{\{TI{D}_{U_j}\}}_{C{R}_{D_i}},T{S}_2,V_2]$$
• S6: The message is encrypted with $C{R}_{D_i}$ and $V_2=h(C{R}_{D_i}\Vert PI{D}_{D_i}\Vert TI{D}_{U_j}\Vert T{S}_1)$. $D_i$ considers the message is from $C{S}_k$ by $A_5$.

  $$S_6:D_i|\equiv C{S}_k|\sim [TI{D}_{U_j},T{S}_2,V_2]$$
• S7: $D_i$ assumes that the message is fresh by $A_2$.

  $$S_7:D_i\equiv \#[TI{D}_{U_j},T{S}_2,V_2]$$
• S8: $D_i$ assumes that $C{S}_k$ believes the message by $S_6$ and $S_7$.

  $$S_8:D_i|\equiv C{S}_k|\equiv \#[TI{D}_{U_j},T{S}_2,V_2]$$
• S9: Since $D_i$ considers that $C{S}_k$ is a trusted entity, $D_i$ can assume that the message is from $U_i$.

  $$S_9:D_i|\equiv U_j|\equiv \left[TI{D}_{U_j}\right]$$
• S10: $U_j$ receives $M_3$.

  $$S_{10}:U_j⊲[{\{TI{D}_{D_i}\}}_{TI{D}_{U_j}},T{S}_3,V_3]$$
• S11: The message is encrypted with $TI{D}_{U_j}$ and $V_3=h(TI{D}_{U_j}\Vert TI{D}_{D_i}\Vert S{K}_{D_i-U_j}\Vert PI{D}_{D_i}\Vert T{S}_3)$. $U_j$ considers the message is from $D_i$ by $A_6$.

  $$S_{11}:U_j\equiv D_i|\sim [TI{D}_{D_i},T{S}_3,V_3]$$
• S12: $U_j$ assumes that the message is fresh by $A_3$.

  $$S_{12}:U_j\equiv \#[TI{D}_{D_i},T{S}_3,V_3]$$
• S13: $U_j$ assumes that $D_i$ believes the message by $S_{11}$ and $S_{12}$.

  $$S_{13}:U_j|\equiv D_i|\equiv \#[TI{D}_{D_i},T{S}_3,V_3]$$
• S14 and S15: Since $S{K}_{D_i-U_j}=h(TI{D}_{U_j}\Vert TI{D}_{D_j}\Vert T{S}_3)$, $U_j$ can believe that the session key is in agreement with $D_i$.

  $$S_{14}:U_j|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i\left(\mathbf{Goal}\mathbf{1}\right)$$

  $$S_{15}:U_j|\equiv D_i|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i\left(\mathbf{Goal}\mathbf{2}\right)$$
• S16 and S17: In a similar way, $D_i$ can believe that the session key is in agreement with $U_j$

  $$S_{16}:D_i|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i\left(\mathbf{Goal}\mathbf{3}\right)$$

  $$S_{17}:D_i|\equiv U_j|\equiv U_j\stackrel{S{K}_{D_i-U_j}}{\leftrightarrow }{D}_i\left(\mathbf{Goal}\mathbf{4}\right)$$

Finally, we prove that the session key is correctly agreed on between $U_j$ and $D_i$ in the proposed protocol.

6.3. Formal Security Analysis Using RoR Model

We prove the semantic security of the proposed protocol using the RoR model [39]. An adversary A tries various queries (i.e., attacks) under the RoR model and we calculate the advantage probability of A after A performs each query. Before demonstrating queries used in the RoR model, we describe notations used in the RoR model. We assume $p^t$ is the t-th instance of a network participant. For instance, $p_{U_j}^1$, $p_{C{S}_k}^2$, and $p_{D_i}^3$ are instances of $U_j$, $C{S}_k$, and $D_i$, respectively.

Table 4. Queries and description.

Query	Description
$Execute(p_{U_j}^1$, $p_{C{S}_k}^2,p_{D_i}^3)$	This query represents an eavesdropping attack. A can obtain transmitted messages of the proposed protocol.
$Corrupt\left(p_{U_j}^1\right)$	This query represents the smart card stolen attack. A corrupts a smart card of $U_j$ and can extract the stored values using the power analysis attack.
$Send(p^t,M)$	Using this query, A can generate a message and sends it to a network participant that can receive the response message.
$Hash\left(p^t\right)$	This query represents a one-way hash operation. A can execute the hash operation used on the network.
$Test\left(p^t\right)$	This query is executed after executing the above attack queries. When this query is executed, an unbiased coin c is flipped. Then, if the coin lands on head, it represents “1” and the session key is provided to A. If the coin lands on tail, it represents “0” and the random number is provided to A. After that, A should distinguish that the result of the coin toss is “1” or “0”. If A successfully distinguishes the results, A passes the test.

presents queries executed by A.

Theorem 1.

Let $Ad{v}_A$ be the advantage function of A to pass the test. Then, the following inequality holds:

$$Ad{v}_A\le {\displaystyle \frac{q_{Hash}^2}{\left|Hash\right|}}+{\displaystyle \frac{q_{send}}{\left|D_{ID}\right|\left|D_{PW}\right|}}.$$

(16)

$\left|Hash\right|$, $q_{Hash}$, and $q_{send}$ denote the range space of the $Hash$ output, the number of performed $Hash$ queries, and the number of performed $Send$ queries, respectively.

Proof. 

A performs the following games: $G_i$$(i=1,2,3)$. When each game ends, we calculate $Ad{v}_A$ to prove the semantic security of our scheme.

$G_0:$ In $G_0$, we assume that A has no information and obtains no messages or values. Then, the probability that A passes the test is exactly $1/2$. Accordingly, we can obtain the following Equation:

$$Ad{v}_A=|2Ad{v}_A^{G_0}-1|.$$

(17)

$G_1$: A can conduct $Execute$ query in this game. A can obtain transmitted over public channels including $\{M_1,M_2,M_3,V_1,T{S}_1\}$, $\{M_4,V_2,T{S}_2\}$, and $\{M_6,V_3,T{S}_3\}$. A cannot obtain any meaningful value about $S{K}_{D_i-U_j}$. Therefore, the advantage function of A after $G_1$ is not changed.

$$Ad{v}_A^{G_1}=Ad{v}_A^{G_0}.$$

(18)

$G_2$: A can perform $Hash$ queries and obtain the output. A has no information about $S{K}_{D_i-U_j}$, and A must find it has collision to compromise the session key. Therefore, The advantage function of A at the ends of $G_2$ can be induced through the birthday paradox [40].

$$|Ad{v}_A^{G_2}-Ad{v}_A^{G_1}|\le {\displaystyle \frac{q_{Hash}^2}{2\left|Hash\right|}}$$

(19)

$G_3$: A performs $Corrupt$ and $Send$ queries in this game. A disguises as $U_j$ and generates a message to receive a response message. A should generate a legitimate $\{M_1,M_2,M_3,V_1,T{S}_1\}$ and send it to $C{S}_k$. However, A cannot generate a legitimate $M_2$ and $M_3$ because these values are masked with $E{U}_{U_j}$, which is a secret value of $U_j$. To obtain these values, A must succeed to log in by correctly guessing $I{D}_{U_j}$ and $P{W}_{U_j}$ simultaneously. The advantage functions of A when $G_3$ ends are as follows:

$$|Ad{v}_A^{G_3}-Ad{v}_A^{G_2}|\le {\displaystyle \frac{q_{send}}{|D_{ID}||D_{PW}|}}.$$

(20)

$D_{ID}$ and $D_{PW}$ denote an identity dictionary and a password dictionary, respectively. After all the games end, A cannot obtain meaningful values to pass the test, and the following Equation (21) holds:

$$Ad{v}_A^{G_3}={\displaystyle \frac{1}{2}}$$

(21)

Using these Equations (17), (18) and (21), we can obtain Equation (22):

$$\begin{array}{cc}\hfill {\displaystyle \frac{1}{2}}Ad{v}_A& =|Ad{v}_A^{G_0}-{\displaystyle \frac{1}{2}}|\hfill \\ \hfill & =|Ad{v}_A^{G_1}-Ad{v}_A^{G_3}|.\hfill \end{array}$$

(22)

The triangular inequality can be applied to Equation (22).

$$\begin{array}{cc}\hfill Ad{v}_A& =2|Ad{v}_A^{G_1}-Ad{v}_A^{G_3}|\hfill \\ \hfill & \le 2|Ad{v}_A^{G_1}-Ad{v}_A^{G_2}|+2|Ad{v}_A^{G_2}-Ad{v}_A^{G_3}|\hfill \\ \hfill & \le {\displaystyle \frac{q_H^2}{|Hash|}}+{\displaystyle \frac{2q_{send}}{|D_{ID}||D_{PW}|}}.\hfill \end{array}$$

(23)

Consequently, the advantage function of A is negligibly small and we can say that the proposed scheme guarantees the semantic security. □

6.4. Informal Analysis

6.4.1. Privileged Insider Attack

Assume there is an adversary A who has intercepted the registration message $I{D}_{U_j}$ of user $U_j$. Subsequently, A is able to extract stored data from $U_j$’s IoT device. With this information, A might attempt to compute session keys used in other communications or impersonate $U_j$. However, since A does not know the exact password of $U_j$, it cannot compute $E{C}_{U_j}^{*}$. Consequently, A is unable to generate messages $\{M_1,M_2,M_3,V_1\}$ to convincingly impersonate the legitimate $U_j$. Moreover, A cannot compute $TI{D}_{Ua}$ and $TI{D}_{Da}$ from the available data and intercepted messages to generate the session key of another user $U_a$.

6.4.2. Stolen Device Attack

Adversary A extracts values stored in the memory of the stolen IoT device belonging to user $U_j$. With access to $RP{W}_{U_j}$, $PI{D}_{U_j}$, $Cer{t}_{U_j}$, $I{D}_{C{S}_k}$, and $r_3$, A may attempt various attacks. However, to execute a valid attack, A needs the login credentials, specifically $P{W}_{U_j}$ and $I{D}_{U_j}$. The real $I{D}_{U_j}$ is concealed by the pseudonym $PI{D}_{U_j}$, and the password $P{W}_{U_j}$ is also unknown to A. Consequently, A is unable to perform legitimate login attempts or compute the necessary parameters for a successful attack using the extracted device data.

6.4.3. Drone Capture Attack

Adversary A extracts values stored in the memory of a hijacked drone through a power analysis attack. Using the values obtained from a legitimately registered drone $D_i$, including $\{I{D}_{D{R}_i},Cer{t}_{D{R}_i},C{C}_{D{R}_i}\}$, A may attempt an attack. However, A cannot replicate the exact PUF applied to the drone. Therefore, even with $C{C}_{D{R}_i}$, A cannot generate the same response $C{R}_{D{R}_i}$ required for a valid attack. As a result, A is unable to impersonate $D_i$ or compute the session key used in communication for a successful attack.

6.4.4. Impersonation Attack

Adversary A may attempt to impersonate a legitimately registered user $U_j$ or drone $D_i$. To successfully do so, A must create valid verification messages $V_1$ and $V_2$ to convince each party of their legitimacy. However, A is unable to generate the essential $E{C}_{U_j}$ and $TI{D}_{D{R}_i}$ required for these messages. As a result, A fails to produce valid $V_1$ and $V_2$, leading to detection as an unauthorized entity during the verification process. Consequently, both the user and drone are safeguarded against impersonation attacks.

6.4.5. Man-in-the-Middle Attack

Adversary A may attempt a man-in-the-middle attack by intercepting, modifying, and then forwarding messages in the communication channel. However, for the receiving entity to accept these altered messages as valid, A must know the unique parameters embedded within each message. For instance, if A tries to redirect user $U_j$’s message $\{M_1,M_2,M_3,V_1,T{S}_1\}$ to a different drone with $PI{D}_a$ instead of the intended $D{R}_i$ with $PI{D}_{D{R}_i}$, A would need to know $E{C}_{U_j}$ in $M_2$, which is not possible. Since A cannot compute critical parameters like $E{C}_{U_j}$ or $C{R}_{D{R}_i}$, the proposed protocol remains secure against man-in-the-middle attacks.

6.4.6. Replay Attack

A replay attack involves intercepting message data and retransmitting them to delay communications or fraudulently repeat actions. However, our proposed protocol incorporates a timestamp in every message sent over the communication channel. These timestamps $T{S}_1,T{S}_2,T{S}_3$ are promptly verified upon receipt. Any message with an invalid timestamp is immediately rejected, and no further action is taken. Consequently, the proposed scheme is robust against replay attacks.

6.4.7. DoS Attack

Adversary A may attempt a DDoS attack by generating arbitrary messages to overwhelm the communication of the connected server $C{S}_k$. However, $C{S}_k$ utilizes the verification message $V_1$ included in the communication to determine the legitimacy of the request. If the message is found to be invalid, $C{S}_k$ does not perform any further unnecessary computations, thereby defending against the DDoS attack.

6.4.8. Anonymity

In all communications, the IDs of the user and drone are replaced with pseudonym IDs $PI{D}_{U_j}$ and $PI{D}_{D{R}_i}$. For adversary A to calculate the real ID from the $PID$, they would need additional information such as the user and drone’s registration timestamp and, for the user, the value $x_C{S}_k$. However, A has no way of obtaining these values, making it impossible to compute the ID from the $PID$ or vice versa. Therefore, the proposed scheme provides anonymity for both the user and the drone.

6.4.9. Untraceability

To ensure untraceability, adversary A must be unable to distinguish messages sent by $U_i$, even if Ui communicates multiple times. $U_i$ generates $M_1$ to send its $PI{D}_{Ui}$ to $C{S}_k$. Although $M_1$ contains $PI{D}_{Ui}$, the message changes each time due to the timestamp. As a result, even if $Ui$ initiates multiple communications, the value of $M_1$ that could identify $U_i$ varies with each attempt. Therefore, the proposed protocol effectively provides untraceability.

7. Performance Analysis

7.1. Security Features Comparison

We compared the schemes and security elements of similar studies in IoD environments [16,17,18,23,41], including that of Wang et al. [12], and summarized the results in

Table 5. Security and functionality features (SFFs) comparison.

Features	Our	Wang et al. [12]	Zhang et al. [16]	Hussain et al. [18]	Tanveer et al. [23]	Yu et al. [41]	Hussain et al. [17]
Privileged insider attack	✓	✓	×	×	✓	✓	✓
Man-in-the-middle attack	✓	✓	✓	✓	✓	✓	✓
Drone capture attack	✓	×	✓	×	×	✓	✓
Stolen device attack	✓	✓	✓	✓	✓	✓	✓
User impersonation attack	✓	✓	✓	✓	✓	✓	✓
Drone impersonation attack	✓	✓	×	×	×	✓	✓
Server impersonation attack	✓	✓	✓	✓	✓	✓	✓
Replay	✓	✓	×	✓	✓	✓	✓
DDoS attack	✓	✓	×	✓	✓	✓	✓
Secure session key	✓	×	✓	✓	✓	✓	✓
Mutual key agreement	✓	×	✓	✓	✓	✓	✓
Anonymity	✓	✓	✓	✓	×	✓	✓
Untraceability	✓	✓	✓	✓	✓	×	✓

. We evaluated a total of 13 security features, comparing whether each scheme provided these features or exhibited any known vulnerabilities. Only our proposed scheme and the scheme proposed by Hussain et al. in 2023 were found to provide all 13 security features.

7.2. Communication Costs Comparison

The comparison results of the communication costs during the authentication and login phases of related studies, including Wang et al.’s protocol, are shown in

Table 6. Communication costs comparison.

Schemes	Number of Rounds	Total Costs (bits)
Zhang et al.  [16]	3	2560
Hussain et al. [18]	3	2624
Tanveer et al. [23]	3	1952
Yu et al. [41]	4	2400
Hussain et al. [17]	3	2679
Wang et al. [12]	3	2208
Ours	3	2048

and Figure 6. For the comparison, we set the bit sizes of the hash function, timestamp, string, random nonce, and elliptic curve point to 256 bits, 32 bits, 160 bits, 160 bits, and 160 bits, respectively.

The proposed protocol proceeds through a total of three rounds, and in each round, the following messages are transmitted: $\{M_1,M_2,M_3,V_1,T{S}_1\},\{M_4,V_2,T{S}_2\},\{M_6,V_3,T{S}_3\}$. The total communication cost of the messages is calculated as (256 ∗ 7 + 160 + 32 ∗ 3) = 2048 bits. It can be observed that the proposed protocol saves more on communication costs compared to Wang et al.’s protocol. Additionally, the protocol proposed by Hussain et al. [17] required the highest communication cost at 2679 bits, while the protocol by Tanveer et al. required the lowest communication cost at 1952 bits. However, as seen in the security feature comparison, Tanveer et al.’s protocol has several issues, including vulnerabilities to drone capture attacks and drone impersonation attacks, as well as the failure to provide anonymity.

7.3. Computation Costs Comparison

We conducted experiments to determine the optimal computation cost in the IoD environment. Using two distinct computational setups, we measured the time required for communication with MIRACL, a cryptographic software library written in C and C++. MIRACL is designed for devices with limited computational power, such as embedded systems, eSIMs, and IoT devices, providing robust security through code simplification and optimization at the processor and memory levels. Our experiments included simulating a server environment and an IoT/drone environment. Additionally, detailed operation symbols and the max/average times (ms) for these operations in the specified environments are shown in

Table 7. Computation operations and times.

Operation	Server Setting		Raspvberry PI Setting
	Max Time (ms)	Average Time (ms)	Max Time (ms)	Average Time (ms)
$T_{bp}$	2.446	2.321	14.258	13.937
$T_{ecpm}$	0.528	0.411	3.072	2.353
$T_{ecpa}$	0.009	0.003	0.033	0.029
$T_{fe}$	0.528	0.411	3.072	2.353
$T_h$	0.005	0.001	0.013	0.009
$T_{sed}$	0.002	0.001	0.011	0.004

.

(1)

Server: Desktop, Intel Core i5-11400 @2.60 GHz(Hexa-core), Ubuntu 20.04 LTS 64 bit with 24.0 GB Ram memory;

(2)

User: Raspvberry PI, ARM Cortex-A72 @1.5 GHz(Quad-core) GUI installed Ubuntu 20.04 LTS 64 bit with 8.0 Ram memory.

Table 8. Computation costs comparison.

Scheme	User	Drone	User + Drone Total (ms)	Server	Server Total (ms)
Zhang et al. [16]	$10T_h$	$7T_h$	≈0.153	$7T_h$	≈0.007
Hussain et al. [18]	$8T_h+2T_{ecpm}+T_{fe}$	$6T_h$	≈7.185	$6T_h+T_{ecpm}$	≈0.417
Tanveer et al. [23]	$7T_h+3T_{ecpm}+T_{fe}$	$3T_h+2T_{ecpm}+2T_{sed}$	≈14.216	$2T_h+T_{ecpm}+T_{sed}$	≈0.413
Yu et al. [41]	$12T_h+T_{fe}$	$8T_h+T_{fe}$	≈4.886	$9T_h$	≈0.009
Hussain et al. [17]	$8T_h$	$3T_h$	≈0.099	$8T_h+T_{sed}$	≈0.065
Wang et al. [12]	$6T_h$	$6T_h$	≈0.108	$7T_h$	≈0.007
Ours	$9T_h$	$6T_h$	≈0.135	$8T_h$	≈0.008

compares the computational costs of several cryptographic schemes in IoD environments, detailing the efficiency for users, drones, and servers.

Wang et al.’s scheme is efficient, requiring $6T_h$ for both users and drones, totaling approximately 0.108 ms, with the server requiring $7T_h$ at approximately 0.007 ms. The scheme proposed by Tanveer et al. recorded the highest computation cost, requiring $7T_h+3T_{ecpm}+T_{fe}$ for the user and $3T_h+2T_{ecpm}+2T_{sed}$ for the drone, with an estimated delay of approximately 14.216 ms. This delay is inefficient for IoT-Drone environments that require real-time communication. Next, Hussain et al. [18]’s scheme is estimated to have a delay of approximately 7.185 ms. Among lightweight protocols, such as the one we proposed, Yu et al.’s scheme had the highest delay at 4.886 ms. Our scheme demonstrates a balanced approach, with user and drone computation totaling approximately 0.135 ms and server computation at 0.008 ms, suggesting a trade-off between efficiency and security. To sum up, the differences in costs—less than 0.04 ms on the user–drone side and less than 0.001 ms on the server side, are minimal and unlikely to result in any significant communication overhead.

8. Conclusions

This study addresses critical security challenges in UAV communication systems within IoT environments. IoD has introduced new complexities in securing communication channels, data integrity, and user privacy. Existing authentication protocols, such as the one recently proposed by Wang et al., have demonstrated limitations in effectively mitigating emerging threats, particularly in scenarios involving resource-constrained IoT devices and real-time UAV operations. This research identified several critical vulnerabilities in Wang et al.’s protocol through comprehensive cryptanalysis, including susceptibility to drone impersonation attacks, session key leakage, and failures in mutual key agreement.

To address these security issues, we proposed a lightweight authentication scheme designed specifically for blockchain-assisted multi-server IoD environments. Our protocol leverages the decentralized and tamper-resistant features of blockchain technology, combined with advanced cryptographic techniques such as PUFs and hash operations. This approach ensures robust mutual authentication and mitigates the risks of common attacks, including replay attacks, man-in-the-middle (MitM) attacks, and session key compromise. The proposed scheme achieves a delicate balance between security and efficiency, making it particularly suitable for real-time applications in resource-constrained IoD networks.

The security of our protocol was rigorously validated using both formal and informal methods. Formal analysis through the RoR model and BAN logic has demonstrated the robustness of the scheme against a wide range of adversarial scenarios, including drone capture attacks and session key disclosure. The informal analysis further corroborated the protocol’s resilience, highlighting its ability to withstand physical tampering and various impersonation attacks. In addition to its strong security properties, the proposed scheme was evaluated in terms of computational and communication costs. Comparative performance analysis with existing protocols has shown that our scheme achieves reductions in terms of communication cost, thereby enhancing its practicality for large-scale IoD deployments. While there is a slight increase in computation cost due to the heightened security features, the delay introduced is minimal and well within acceptable limits for real-time IoD applications. The results of this research contribute to advancing the field of secure IoD communications and lay the groundwork for future developments in this rapidly evolving area. In future research, we plan to use NS-3 to simulate a realistic network environment, incorporating moving users and drones with designated altitudes, as well as fixed servers. This will allow us to further investigate issues such as latency and other related challenges.