Efficient and Scalable Authentication Framework for Internet of Drones (IoD) Networks

Abstract

The accelerated uptake of unmanned aerial vehicles (UAVs) has significantly altered communication and data exchange landscapes but has also introduced substantial security challenges, especially in open-access UAV communication environments. To address these, Elliptic curve cryptography (ECC) offers robust security with computational efficiency, ideal for resource-constrained Internet of Drones (IoD) systems. This study proposes a Secure and Efficient Three-Way Key Exchange (SETKE) protocol using ECC, specifically tailored for IoD. The SETKE protocol’s security was rigorously analyzed within an extended Bellare–Pointcheval–Rogaway (BPR) model under the random oracle assumption, demonstrating its resilience. Formal verification using the AVISPA tool confirmed the protocol’s safety against man-in-the-middle (MITM) attacks, and formal proofs establish its Authenticated Key Exchange (AKE) security. In terms of performance, SETKE is highly efficient, requiring only 3 ECC scalar multiplications for the Service Requester drone, 4 for the Service Provider drone, and 3 for the Control Server, which is demonstrably lower than several existing schemes. My approach achieves this robust protection with minimal communication overhead (e.g., a maximum payload of 844 bits per session), ensuring its practicality for resource-limited IoD environments. The significance of this work for the IoD field lies in providing a provably secure, lightweight, and computationally efficient key exchange mechanism vital for addressing critical security challenges in IoD systems.

1. Introduction

The Internet of Drones (IoD) is an innovative paradigm with applications in various fields, offering benefits such as mobility, ease of deployment, and data collection [1,2]. However, IoD systems rely on wireless communication, making them susceptible to security threats like man-in-the-middle and impersonation attacks, which can lead to significant losses and compromise sensitive information. Therefore, robust cryptographic protocols are essential to address these vulnerabilities [3,4]. Traditional cryptographic schemes are often inadequate for IoD environments due to limitations in computing power and storage space on resource-constrained devices [5]. This necessitates novel approaches for secure and efficient authentication.

Key exchange protocols are vital for establishing a secret key between two parties communicating over an open channel without prior shared secret information. The classic Diffie–Hellman (DH) protocol is a well-known example [6], but it lacks authentication, leaving it vulnerable to active attacks like man-in-the-middle attacks. ECC was introduced to mitigate the weaknesses of traditional key exchange protocols. Significant research has since focused on authenticated key exchange (AKE) protocols that ensure both shared key computation and party authenticity. However, many existing AKA protocols for IoD environments, while attempting to be lightweight, have exhibited vulnerabilities. For instance, early schemes focusing on simple cryptographic operations often compromised security, leading to issues such as a lack of user anonymity, susceptibility to node impersonation, and man-in-the-middle attacks, as highlighted by Farash et al. [7]. Even some ECC-based proposals, such as the one by Tanveer et al. [8], were criticized for lacking drone anonymity and incurring computational overhead, while others like Chaudhry et al.’s ECC-based certificate scheme [9] were later found to be vulnerable by Das et al. [10]. These challenges underscore a persistent research gap in developing a three-party AKE protocol for IoD that is not only provably secure against a comprehensive range of attacks but is also genuinely lightweight, computationally efficient for resource-constrained drones, and ensures fairness in key agreement where clients contribute to the key establishment.

To address these limitations, this study proposes the Secure and Efficient Three-Way Key Exchange (SETKE) protocol. SETKE is specifically designed for IoD environments and leverages ECC to provide a balance between robust security and operational efficiency. Unlike many prior schemes that struggle with either security vulnerabilities or excessive computational demands, SETKE offers provable security, demonstrated through formal analysis in an extended BPR model and verification with AVISPA. It is optimized for resource-constrained devices and ensures key agreement fairness, offering a more holistic solution to the security needs of IoD networks. Key agreement protocols, where both parties contribute to key establishment, are generally considered more secure and equitable than key transport protocols. Three-party schemes exist where a server transfers a session key to clients, but this can allow a potentially untrusted server to eavesdrop. Key agreement schemes resolve this by having the two clients decide the session key, unknown to anyone else. Previous three-party protocols often require password tables and incur heavy communication and computation costs [11,12,13].

1.1. Problem Statement

Existing key exchange protocols for IoD networks struggle to balance robust security guarantees against various attacks with the computational and communication constraints of resource-limited drone devices. There is a research gap in developing a three-party authenticated key exchange protocol for IoD that is provably secure, lightweight, and protects against prevalent threats while ensuring fairness in key agreement.

1.2. Novelty and Contributions

The proposed SETKE protocol offers several novel aspects and contributions:

• It is a Secure and Efficient Three-Way Key Exchange scheme specifically designed for IoD environments.
• It provides rigorous mathematical security proofs against a variety of attacks, ensuring provable security.
• It is optimized for resource-constrained devices, enabling lightweight implementation suitable for drones.
• It offers comprehensive security guarantees against man-in-the-middle attacks, perfect forward secrecy, session state disclosure, privacy violations, stolen verifier attacks, unknown key sharing, and excessive computational overhead.
• It prioritizes security and privacy, contributing to the reliable operation of IoD systems.
• It is a key agreement protocol where the session key is decided by the two clients, making it fairer.

This paper is organized as follows: Section 2 reviews existing literature. Section 3 describes the system model and security assumptions for SETKE. Section 4 presents the formal model for security analysis. Section 5 proposes the efficient three-party key exchange protocol, and Section 6 analyzes its security. Section 7 evaluates its performance. Section 8 provides a discussion of the results and their implications. Finally, Section 9 concludes the paper.

2. Related Work

Authentication by Key Agreement (AKA) protocols are crucial for establishing secure communication channels and enabling mutual authentication and shared secret key establishment over insecure networks. Early AKA protocols, such as those by Turkanovic et al. [14], focused on lightweight solutions using simple cryptographic operations but often compromised security, exhibiting vulnerabilities like issues with user anonymity, node impersonation, and man-in-the-middle attacks, as highlighted by Farash et al. [7]. Subsequent research, including Amin et al.’s work [15] incorporating smart card-based authentication, aimed to address these vulnerabilities but was still susceptible to attacks like off-line password guessing and smart card theft.

With the rise of the Internet of Drones (IoD), adapting and extending AKA protocols for the unique challenges of this environment has become increasingly important [16]. Yaacoub et al. [17] provided an overview of drone architecture, communication types, and security vulnerabilities, highlighting limitations of existing approaches. The concept of using temporal credentials was introduced by Srinivas et al. [18]. However, Chaudhry et al. [19] criticized this approach for lacking mutual authentication and being vulnerable to user traceability attacks. Many researchers have explored using ECC to enhance IoD authentication security [20,21,22]. Tanveer et al. [8] proposed an ECC-based scheme, but it was criticized for lacking drone anonymity and having computational overhead. Chaudhry et al. [9] introduced ECC-based certificates but were shown to be vulnerable by Das et al. [10]. Other ECC-based schemes by Zhang et al. [23] and Nikooghadam et al. [24] have also been found susceptible to various attacks.

This highlights the ongoing challenges in designing secure and efficient AKA protocols for IoD, where existing solutions often involve trade-offs between security and performance. The proposed SETKE protocol aims to provide a balance between security and efficiency for IoD environments by addressing the identified vulnerabilities in previous approaches.

3. System Model and Security Assumptions

The network model for the SETKE protocol in an IoD environment consists of three entities as follows (Figure 1): a Service Requester (SR) drone, a Service Provider (SP) drone, and a trusted Control Server (S).

1.

Drone (Service Requester—SR): In the registration phase, the SR sends and receives secret credentials from S. Subsequently, the SR requests mutual authentication with the SP and establishes a common session key for secure future communications with the SP.

2.

Drone (Service Provider—SP): The SP receives secret credentials from S during registration before deployment. The SP then receives access requests from the SR for mutual authentication and establishes a common session key with the SR with the help of S. The SP is remotely controlled by S.

3.

Trusted Control Server (S): S is a trusted entity, representing the ground station server. Authorized external mobile users can monitor and access drones in specific zones via S. S is responsible for various tasks, including monitoring, facilitating communication among drones, and ensuring only legitimate drones access the network. S generates credentials for each entity and registers SR and SP. S acts as a bridge for mutual authentication between SR and SP over a public channel. S’s database is considered secure and immune to compromise by SR or SP.

Adversary Model

The security analysis utilizes the well-known Dolev–Yao (DY) threat model [25] and the Canetti–Krawczyk (CK) adversary model [26]. In the DY model, a malicious attacker has full control over the public channel, able to intercept, modify, delete, tamper, read, and insert messages. The CK model extends the DY model by allowing the attacker to obtain and expose secret credentials, session states, and session keys during a session. Therefore, the proposed scheme ensures that the valid credentials of communicating entities are not affected by the leakage of temporary session secrets and keys. The protocol assumes that the registration and authentication server (S) is trusted, while the drones (SR and SP) are considered untrusted participants.

4. A Variation of the BR1995 Model and BPR2000 Model for the SETKE Protocol

Wen et al.’s protocol [27] comes along with a claimed proof of its security in a formal model of communication and adversarial capabilities. The model that they used can be best described as a combined variant of the Bellare–Rogaway 1995 model [28] (in short, the BR95 model) and the Bellare–Pointcheval–Rogaway 2000 model [29] (in short, the BPR2000 model). Bellare and Rogaway [30,31] initially proposed a provably secure two-party authentication and key distribution protocol in a complexity-theoretic framework of modern cryptography. They introduced a formal model (BR1993 model) to prove the security of their protocol. The BR1993, BR1995, and BPR2000 models are under the random oracle assumption, and all communications among interacting parties are under the adversary’s control. The adversary has the capability to read, delay, replay, modify, delete, and fabricate messages between communicants. For modeling kinds of attacks, the adversary can start up new instances of any of the communicants and interact with the communicants using a set of oracles at any time in any order. Each participant will be modeled by an infinite collection of oracles that the adversary may run formally. These instances only interact with the adversary; they never directly interact with one another. Many cryptographic protocols, e.g., [28,29,30], have been formally analyzed by employing the BR1993 model, the BR1995 model, the BPR2000 model, or their variations. Here, I provide a variation of the BR1995 model and the BPR2000 model as a preliminary step towards analyzing the claimed proof of security.

4.1. Participants

Each participant U in a three-party key exchange is either a client C or the trusted server S. Each U may run the protocol multiple times, denoted by instance ${\Pi }_U^i$. An instance ${\Pi }_U^i$ accepts when it computes a valid session key $S{K}_U^i$. $PI{D}_U^i$ denotes the set of participants for instance ${\Pi }_U^i$. $COMP\left({\Pi }_U^i\right)$ is true when ${\Pi }_U^i$ has enough information to compute $S{K}_U^i$. $FIN\left({\Pi }_U^i\right)$ is true when ${\Pi }_U^i$ sends/receives the last message or an unexpected message.

4.2. Adversary

The adversary controls all communications and can query oracles:

• $Send({\Pi }_U^i,m)$: Sends message m to instance ${\Pi }_U^i$ and returns the response.
• $Execute({\Pi }_{C1}^i,{\Pi }_{C2}^j,{\Pi }_S^k)$: Prompts an honest execution between instances and returns the transcript. Represents passive eavesdropping.
• $Reveal\left({\Pi }_U^i\right)$: Returns the session key $S{K}_U^i$. Exposure of some keys should not affect others.
• $Corrupt\left(U\right)$: Returns the long-term secret key of U. Damage should be limited to future sessions.
• $Hash\left(m\right)$: Returns the hash of m in the random oracle model.
• $Test\left({\Pi }_U^i\right)$: Returns the real session key or a random key based on a hidden bit b. Can only be queried once to a fresh instance.

4.3. Security Definition

The security of SETKE is defined by the following:

1.

Partnership: Two instances are partners if they participate together and share a session key, and no other instance holds that key.

2.

Freshness: An instance ${\Pi }_U^i$ is fresh if $COMP\left({\Pi }_U^i\right)$ is true, no one in $PI{D}_U^i$ was corrupted before $COMP\left({\Pi }_U^i\right)$ was true, and neither ${\Pi }_U^i$ nor its partner was queried with Reveal.

3.

AKE security: The adversary wins if they issue a Test query to a fresh instance and correctly guess the hidden bit b. The AKE advantage $Ad{v}_{SETKE}^{AKE}$ is defined as $2·Pr[b^{\prime }=b]-1$. SETKE is AKE-secure if $Ad{v}_{SETKE}^{AKE}$ is negligible.

5. Proposed SETKE Protocol

In this section, I propose a three-party key exchange protocol for constructing a secure IoD environment using the elliptic curve cryptosystem.

5.1. Preliminaries

Elliptic curve cryptography (ECC) is a powerful public-key cryptographic technique suitable for resource-constrained environments like IoD due to its comparable security to RSA with smaller key sizes and faster computations [32,33]. The security of ECC relies on the difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP). Key definitions and operations in ECC include the following:

1.

Elliptic Curve over a Finite Field: An elliptic curve E over a finite field $F_p$ is defined by $y^2\equiv x^3+ax+b(modp)$, where $4a^3+27b^2\not\equiv 0(modp)$. Points on the curve and the point at infinity (O) form an additive abelian group.

2.

Base Point (Generator): A publicly known point P on E generating a cyclic subgroup of prime order n.

3.

Scalar Multiplication: Computing $Q=kP$ (public key) from an integer k (private key) and point P. Easy to compute Q from k and P, but infeasible to compute k from Q and P (ECDLP).

4.

Elliptic Curve Diffie–Hellman (ECDH): Allows two parties with ECC key pairs ($(d_A,Q_A=d_{A}P)$ and $(d_B,Q_B=d_{B}P)$) to establish a shared secret $S=d_A{Q}_B=d_B{Q}_A=d_A{d}_{B}P$.

5.

Cryptographic Hash Function: A function $h(·)$ mapping arbitrary-size input to fixed-size output, possessing collision resistance and preimage resistance [34,35].

These ECC primitives are leveraged in the SETKE protocol.

5.2. The Proposed Protocol

The SETKE protocol is a three-party authenticated key exchange scheme for IoD involving SR, SP, and a trusted S. It establishes a mutually authenticated shared session key between SR and SP with S’s assistance as follows (

Table 1. SETKE notation.

Notation	Description
P	Base point on the elliptic curve
$h(·)$	Cryptographic hash function
$e_X$	Ephemeral private key for entity X (where X can be SR, SP, or S)
$E_X=e_{X}P$	Ephemeral public key for entity X
$d_X$	Long-term private key for entity X
$Q_X=d_{X}P$	Long-term public key for entity X
$M_{S\to U}$	Message from Server (S) to entity U (where U is SR or SP)
$(E_S,I{D}_{peer},Aut{h}_{S\to U})$	Structure of message $M_{S\to U}$, including server’s ephemeral key, peer’s ID, and an authenticator

, Figure 2). Let P be a base point, n its order, and $h(·)$ a hash function. S has master key $s_{priv}$ and public key $s_{pub}=s_{priv}P$. SR and SP have identities $(I{D}_{SR},I{D}_{SP})$ and long-term keys $(d_{SR},Q_{SR}=d_{SR}P)$ and $(d_{SP},Q_{SP}=d_{SP}P)$.

• Phase 1: Registration (Pre-Protocol)

SR and SP register securely with S, which knows their identities and long-term public keys and may issue certificates.

• Phase 2: Key Exchange and Authentication

Goal: Establish shared session key $S{K}_{SR-SP}$.

1.

Access Request $(SR\to SP$ then $SP\to S)$:

• SR generates nonce $N_{SR}$ and ephemeral key pair ($e_{SR},E_{SR}=e_{SR}P$).
• SR sends to SP: $I{D}_{SR},E_{SR},N_{SR}$.
• SP receives the request, generates nonce $N_{SP}$ and ephemeral key pair ($e_{SP},E_{SP}=e_{SP}P$).
• SP forwards to S: $I{D}_{SP},E_{SP},N_{SP},I{D}_{SR},E_{SR},N_{SR}$. (Optionally protected with $s_{pub}$ or pre-shared key).

2.

Server Authentication and Key Material Generation $(S\to SP,S\to SR$ indirectly via SP):

• S verifies $I{D}_{SR},I{D}_{SP}$.
• S generates ephemeral key pair ($e_S,E_S=e_{S}P$).
• S computes partial shared secrets: $K_{S-SR}=e_S{Q}_{SR}$ and $K_{S-SP}=e_S{Q}_{SP}$.
• S prepares messages: $M_{S\to SR}=(E_S,I{D}_{SP},Aut{h}_{S\to SR})$, with $Aut{h}_{S\to SR}=h(I{D}_S,I{D}_{SR},I{D}_{SP},E_S,E_{SR},E_{SP},N_{SR},K_{S-SR})$. $M_{S\to SP}=(E_S,I{D}_{SR},Aut{h}_{S\to SP})$, with $Aut{h}_{S\to SP}=h(I{D}_S,I{D}_{SP},I{D}_{SR},E_S,E_{SP},E_{SR},N_{SP},K_{S-SP})$.
• S sends $M_{S\to SR}$ and $M_{S\to SP}$ to SP. (Optionally protected).

3.

Relay and Session Key Computation $(SP\to SR$, and finalization):

• SP receives messages from S. Verifies $Aut{h}_{S\to SP}$ using $K_{S-SP}^{\prime }=d_{SP}{E}_S$. If valid, trusts $E_S$.
• SP computes $S{K}_{SP-SR}^{\prime }=e_{SP}{E}_{SR}$ and $K_{SP-S\_eph}=e_{SP}{E}_S$.
• SP forwards $M_{S\to SR}$ to SR.
• SR receives $M_{S\to SR}$. Verifies $Aut{h}_{S\to SR}$ using $K_{S-SR}^{\prime }=d_{SR}{E}_S$. If valid, trusts $E_S$.
• SR computes $S{K}_{SR-SP}^{\prime }=e_{SR}{E}_{SP}$.

4.

Session Key Derivation and Confirmation:

• SR derives $S{K}_{SR-SP}=h(I{D}_{SR},I{D}_{SP},E_{SR},E_{SP},E_S,S{K}_{SR-SP}^{\prime },N_{SR},N_{SP})$.
• SP derives $S{K}_{SP-SR}=h(I{D}_{SR},I{D}_{SP},E_{SR},E_{SP},E_S,S{K}_{SP-SR}^{\prime },N_{SR},N_{SP})$. SR and SP share $S{K}_{SR-SP}$ (which equals $S{K}_{SP-SR}$).
• (Optional Confirmation) SR sends $Confir{m}_{SR}=h(S{K}_{SR-SP},N_{SR},N_{SP})$ to SP. SP verifies $Confir{m}_{SR}$. If correct, SP may send $Confir{m}_{SP}=h(S{K}_{SR-SP},N_{SP},N_{SR})$ to SR. SR verifies $Confir{m}_{SP}$.
• Elaboration on Optional Confirmation: This step is optional as its necessity depends on the IoD application’s reliability requirements. It is useful in scenarios demanding explicit confirmation of successful key establishment before sensitive data transmission, or for diagnosing key derivation issues. Performance impacts include two additional small messages, two extra hash computations per party involved in full confirmation, and an added round-trip latency. For highly resource-constrained scenarios or where the underlying transport is reliable enough, it might be omitted.

6. Security Analysis

I demonstrate that some well-known security threats cannot work on my proposed protocol informally or formally.

6.1. Security Comparisons

The proposed SETKE protocol offers several security advantages when compared with existing key exchange protocols for IoD environments, many of which are discussed in Section 2.

• Robustness Against Man-in-the-Middle (MITM) Attacks: SETKE incorporates mutual authentication mediated by the trusted server S. The exchange of ephemeral public keys and signed/hashed authenticators from S makes it difficult for an adversary to impersonate any legitimate party or manipulate the key exchange process without detection. The formal verification using AVISPA further supports its resilience against MITM attacks.
• Protection Against Impersonation Attacks: SETKE mitigates this by requiring entities to prove knowledge of their long-term private keys and by using fresh ephemeral keys for each session.
• User/Drone Anonymity: While not explicitly detailed, SETKE can be extended to support anonymity using temporary or encrypted identities.
• Forward Secrecy: The use of ephemeral ECC key pairs $(E_{SR},E_{SP},E_S)$ ensures that compromise of long-term private keys does not affect the confidentiality of past session keys.
• Resistance to Stolen Verifier/Smart Card Attacks: SETKE’s security is primarily based on the intractability of ECDLP and the security of the server S, not on vulnerable stored verifiers.
• Efficiency and Scalability: By leveraging ECC, SETKE aims for lightweight implementation. The three-party model with a central server S can facilitate scalability.
• Mutual Authentication: SETKE ensures mutual authentication between SR and SP, with S as the authenticator.
• Key Agreement vs. Key Transport: SETKE is a key agreement protocol, which is generally considered more secure than key transport.

Compared with other three-party schemes, SETKE is designed such that the final session key is derived by SR and SP based on their ephemeral secrets and material from S, making it difficult for S to reconstruct the exact session key without compromising the ephemeral private keys of SR or SP.

6.2. Formal Security Proof

The security of SETKE is defined as the notion of partnership, freshness, and AKE security, as follows. Partnership refers to two instances participating together in a protocol execution and sharing a session key. Freshness indicates that an instance has computed a session key, none of its participants have been corrupted before key computation, and neither the instance nor its partner has been subjected to a Reveal query. AKE security means an adversary cannot distinguish the real session key from a random key for a fresh instance. The protocol’s security is analyzed in an extended BPR model. The formal security proof demonstrates that the SETKE protocol is AKE-secure if the adversary’s advantage $Ad{v}_{SETKE}^{AKE}$ in guessing the correct bit b in a Test query is negligible. The analysis shows that an adversary M who has corrupted a client’s long-term key $k_c$ and attempts to impersonate another party will be detected by the legitimate instance ${\Pi }_B^j$ because the forged messages will not match the expected values. Upon receiving the forged message, ${\Pi }_B^j$ will detect the fraud, set $COMP\left({\Pi }_B^j\right)$ to false and $FIN\left({\Pi }_B^j\right)$ to true, and will not compute a session key. Since ${\Pi }_B^j$ is not fresh, the adversary cannot issue $Test\left({\Pi }_B^j\right)$ according to the definition of the $Test\left(\right)$ query. Clearly, M cannot get any good chance to win the game of breaking the AKE security of the SETKE protocol because he cannot measure the indistinguishability between the session key and a random string. Thus, the AKE advantage $Ad{v}_{SETKE}^{AKE}\left(M\right)$ is negligible ($\approx 2·{\displaystyle \frac{1}{2}}-1=0$), proving that SETKE is AKE-secure and can resist well-known attacks.

6.3. Formal Verification (AVISPA)

AVISPA [36], a formal security verification tool, is employed to assess the resilience of a security protocol to active attacks, such as man-in-the-middle (MITM) attacks. AVISPA leverages the High-Level Protocol Specification Language (HLPSL) to generate input formats for various back-end tools, including the on-the-fly model checker (OFMC) and constraint logic-based attack searcher (CL-AtSE). To validate SETKE’s security, a rule-based HLPSL specification is defined. This specification encompasses the individual roles of the control server (S), the access service requester drone (A), and the service provider drone (B), as well as the overarching security goals, environment, and session parameters. The security protocol animator (SPAN) is utilized to simulate SETKE’s behavior and identify potential MITM vulnerabilities. The simulation environment, running on a Windows 11 system with an Intel Core i5-6400 processor (Intel, Santa Clara, CA, USA) and 6144 MB RAM, models the registration, authentication, and main operational phases of the protocol. The simulation result for the malicious intruder using SPAN, specifically with the OFMC back-end, is shown in Figure 3. The ‘SUMMARY: SAFE’ declaration indicates that for the bounded number of sessions analyzed, the OFMC model checker did not find any execution trace that would lead to an attack an adversary could launch against the protocol’s security goals, specifically concerning MITM attacks as modeled. The ‘DETAILS’ section in Figure 3 confirms that the analysis was performed under ‘BOUNDED_NUMBER_OF_SESSIONS’. The statistics provided, ‘parseTime: 0.00 s, searchTime: 0.35 s, visitedNodes: 1056 nodes, depth: 10 plies’, offer insight into the verification process. ‘parseTime’ reflects the time taken to process the HLPSL specification. ‘searchTime’ is the duration the OFMC back-end spent exploring the protocol’s state space. ‘visitedNodes’ (1056) indicates the number of unique states explored during the model checking, and ‘depth’ (10 plies) refers to the maximum depth of the execution trace explored. These figures suggest a reasonably thorough search within the defined bounds for a protocol of this nature on the specified system. Consequently, this ‘SAFE’ result provides strong evidence that SETKE meets its design criteria for MITM resistance under the assumptions of the Dolev–Yao model, which AVISPA typically employs, where the adversary has full control over the network but cryptographic operations are considered perfect.

7. Performance Evaluation

The performance evaluation of the proposed SETKE protocol is conducted with a focus on computational cost, communication overhead, energy consumption, and scalability in the context of resource-constrained Internet of Drones (IoD) networks. The objective is to assess the protocol’s efficiency in real-world deployment scenarios while maintaining robust security assurances. The analysis also includes a comparative evaluation with existing protocols referenced in [18,37,38,39,40].

7.1. Computational Cost Analysis

The computational cost of the SETKE protocol is primarily determined by the number of elliptic curve scalar multiplications (ECCSM) and hash computations, both of which are computationally intensive but necessary for ensuring forward secrecy and mutual authentication. The distribution of computational operations is as follows:

• Service Requester (SR): 3 ECCSM, multiple hash operations.
• Service Provider (SP): 4 ECCSM, multiple hash operations.
• Control Server (S): 3 ECCSM, multiple hash operations.

Compared with RSA-based protocols, ECC operations are substantially more efficient, achieving comparable security levels with significantly reduced key sizes and computational complexity. The reduced number of ECC operations per entity aligns well with the lightweight nature of IoD devices, which typically have limited processing capabilities. In comparison, Srinivas et al. [18] and Banerjee et al. [37] rely on RSA-based cryptography, resulting in higher computational costs due to modular exponentiations. Kumar et al. [38] and Aghili et al. [39] employ hybrid schemes that combine symmetric and asymmetric cryptography, increasing computational overhead. Ever [40], while using ECC, involves more scalar multiplications per session than SETKE, resulting in higher computational costs.

7.2. Communication Overhead Analysis

The communication overhead is evaluated in terms of the number of message exchanges and the size of the exchanged data. The protocol requires the exchange of four messages in its minimal form, or up to six messages if the optional confirmation phase is included. The ECC-based design ensures minimal message sizes, as ECC keys are significantly smaller than RSA keys for equivalent security levels. Additionally, the incorporation of ECC point compression further reduces data transmission overhead, optimizing the protocol for constrained IoD environments. The maximum payload size for SETKE per session is approximately 844 bits.

Comparatively, Banerjee et al. [37] and Kumar et al. [38] involve multiple rounds of authentication messages, increasing the communication load. Aghili et al. [39] implement a three-factor authentication mechanism, adding further overhead due to additional message exchanges. Ever [40] requires a higher number of message exchanges (6 steps) and larger payload sizes (3840 bits), whereas SETKE maintains a lower maximum payload size.

7.3. Energy Consumption Analysis

Energy consumption is closely tied to the computational complexity and communication overhead. My current assertion that SETKE exhibits lower energy consumption is based on a qualitative analysis of its efficiency. Energy use in cryptographic protocols primarily stems from computational tasks (especially ECC scalar multiplications) and data communication (transmitting/receiving messages). Given the lightweight nature of ECC operations and the reduced number of message exchanges in SETKE (as detailed in Section 7.1 and Section 7.2), it is expected to exhibit lower energy consumption compared with RSA-based protocols and also compared with other ECC-based protocols that are less optimized. For instance, Srinivas et al. [18] and Banerjee et al. [37] incur higher energy costs due to multiple rounds of modular exponentiations with RSA. Kumar et al. [38] and Aghili et al. [39] integrate multifactor authentication, increasing the number of operations and subsequently, the energy consumption. Compared with Ever [40], which also uses ECC, SETKE is anticipated to consume less energy. This is because SETKE involves fewer ECC scalar multiplications per session and has a significantly smaller communication payload (844 bits vs. 3840 bits for Ever [40]) and potentially fewer message exchanges. Fewer computationally intensive operations and less data to transmit/receive inherently lead to lower energy expenditure. While specific hardware-based energy measurements are proposed as future work, existing literature supports that minimizing ECC operations and data transfer directly reduces energy use on resource-constrained IoT devices. Therefore, SETKE’s structural efficiencies in computation and communication strongly suggest a lower energy footprint.

7.4. Scalability Analysis

The centralized key management architecture of SETKE facilitates scalability in large IoD networks. The control server (S) acts as a mediator for key exchanges, enabling centralized monitoring and key distribution. This structure effectively reduces the computational burden on individual drones and simplifies key revocation and renewal processes. Compared with the decentralized structures in Banerjee et al. [37] and Kumar et al. [38], SETKE’s server-centric design allows for more efficient management of large-scale drone networks. Aghili et al. [39] and Ever [40], while incorporating authentication mechanisms, do not explicitly address scalability to the same extent, making them potentially less suitable for extensive IoD deployments.

Considerations for Large-Scale Deployments: While the centralized model is beneficial for scalability and management, it is important to address potential challenges such as bottlenecks or single points of failure (SPOF) concerning the Control Server (S). These can be mitigated using standard techniques:

• SPOF Mitigation: Server redundancy (e.g., primary–backup clusters) and data replication can ensure high availability.
• Bottleneck Avoidance: Load balancing across multiple server instances can distribute high request volumes. Efficient server-side implementation and scalable infrastructure are also crucial.
• Geographical Distribution: For very large or geographically widespread networks, distributing server instances can reduce latency and further distribute load, though this may require data synchronization strategies.

Incorporating these measures can significantly enhance the robustness and performance of SETKE’s centralized architecture in large-scale deployments.

7.5. Summary

The performance evaluation confirms that SETKE is computationally efficient, communication-efficient, and scalable, making it highly suitable for IoD environments characterized by resource-constrained devices. The protocol’s reliance on ECC operations, minimized message sizes, and centralized key management architecture collectively contribute to its lightweight design while maintaining robust security guarantees. The comparative analysis, including the features presented in

Table 2. Comparison of protocols from a security analysis.

Attacks	Srinivas et al.	Banerjee et al.	Kurmar et al.	Aghili et al.	Ever	Our
	[18]	[37]	[38]	[39]	[40]
MITM	S	S	S	S	S	S
Impersonation	S	U	S	U	S	S
Anonymity	S	U	S	S	S	S
Perfect forward	S	U	U	U	-	S
secrecy
Session state	U	U	S	U	-	S
reveal
Privacy	S	S	S	S	U	S
Stolen-verifier	U	U	S	U	-	S
Unknown-key	U	U	S	U	-	S
sharing

S: safe; U: unsafe.

,

Table 3. Comparative Analysis of Protocols.

Protocol	Comp. Cost	Comm. Overhead	Energy	Scalability
SETKE	Low	Low	Low	High
Srinivas et al. [18]	High	Moderate	High	Moderate
Banerjee et al. [37]	High	Moderate	High	Moderate
Kumar et al. [38]	Moderate	High	Moderate	Low
Aghili et al. [39]	Moderate	High	Moderate	Low
Ever [40]	Moderate	High	High	Moderate

and

Table 4. Comparative Overview of Key Exchange Protocol Features.

Feature	SETKE (This Work)	Srinivas et al. [18]	Ever [40]	Banerjee et al. [37]	Kumar et al. [38]
Protocol Type	Three-Party AKE	Two-Party AKE	Three-Party AKE	Three-Factor AKE	Three-Factor AKE
Primary Crypto. Primitives	ECC, Hash	RSA, Hash, Symmetric	ECC, Hash	RSA, Hash, Symmetric	ECC, Hash, Symmetric
Key Agreement Method	ECDH-based (mediated)	DH-like/Symmetric	ECDH-based	DH-like/Symmetric	ECDH-based
Authentication Basis	Long-term Keys, Server-mediated	Temporal Credentials	Long-term Keys	Long-term Keys, Bio.	Smart Card, Bio.
No. of Parties Involved	3 (SR, SP, S)	2 (User, Drone)	3 (User, Sink, S)	3 (User, GWN, SN)	3 (User, GWN, SN)
Key Confirmation	Optional Explicit	Implicit/Specific	Explicit	Explicit	Explicit
Forward Secrecy	Yes	Yes	Yes	No	Yes
Anonymity Support	Extensible	Yes (Temporal ID)	No explicit	Partial	Yes
Trust Model	Trusted Third Party (S)	Trusted Authority	Trusted Server	Trusted GWN	Trusted GWN
Suitability for Resource-Constrained	High (Low ECC ops)	Moderate-High (RSA)	Moderate (More ECC ops)	High (RSA)	Moderate

, further demonstrates SETKE’s competitive edge over referenced protocols.

8. Discussion

The proposed SETKE protocol offers a significant step towards secure and efficient communication in IoD networks by leveraging the strengths of ECC. The formal security analysis conducted using an extended BPR model and the random oracle assumption provides strong theoretical backing for its resilience against a variety of known attacks, including critical threats like man-in-the-middle and impersonation attacks. This is further substantiated by the AVISPA tool’s ‘SAFE’ result, which, within the bounds of the simulation, found no vulnerabilities to MITM attacks under the Dolev–Yao model assumptions. This multifaceted approach to security validation increases confidence in the protocol’s robustness.

One of the key design goals for SETKE was suitability for resource-constrained IoD devices. The performance evaluation (Section 7) indicates that this goal has been largely achieved. The computational cost, primarily driven by a small number of ECC scalar multiplications (3 for SR, 4 for SP, 3 for S) and hash operations, is considerably lower than RSA-based alternatives and competitive with, or even superior to, other ECC-based schemes like Ever [40] that involve more operations. This efficiency is crucial for drones, where battery life and processing power are at a premium. Similarly, the communication overhead is minimized through small ECC key sizes and a limited number of message exchanges (4–6 messages with a maximum payload of approximately 844 bits), which is vital for potentially low-bandwidth or congested wireless IoD environments, especially when compared with protocols with larger payloads like Ever [40].

Compared with other three-party key exchange protocols, SETKE ensures that the session key is a result of contributions from both client drones (SR and SP) with the assistance of the trusted server (S), but S itself cannot reconstruct the session key without compromising the ephemeral private keys of SR or SP. This enhances fairness and security against a potentially compromised (though trusted for its role) server in certain aspects. The features summarized in Table 4 provide a clear distinction between SETKE’s architectural and functional characteristics and those of other models. The centralized model with server S facilitates scalability and management in large IoD networks. However, as discussed in Section 7.4, this means S can be a single point of failure or a bottleneck if not adequately provisioned. Standard mitigation techniques such as server redundancy, load balancing, and efficient implementation are crucial for robust large-scale deployments, and their applicability to S has been noted.

While the protocol shows strong security properties, including forward secrecy due to the use of ephemeral keys, and resistance to stolen verifier attacks, the current version’s anonymity aspects are noted as extensible rather than inherently detailed. Depending on the specific IoD application’s privacy requirements, further enhancements for drone or user anonymity might be considered. The optional confirmation step provides flexibility, allowing applications to choose between higher assurance with slightly increased overhead or minimal overhead where explicit key confirmation is less critical.

The significance of SETKE lies in its pragmatic balance: it does not sacrifice core security guarantees for the sake of efficiency, nor does it impose prohibitive computational or communication burdens that would render it impractical for real-world IoD deployment. It directly addresses many of the vulnerabilities and inefficiencies found in previous IoD authentication schemes (as discussed in Section 2 and compared in Section 6 and Section 7), offering a provably secure and demonstrably lightweight alternative.

9. Conclusions

In this paper, I introduced the Secure and Efficient Three-way Key Exchange (SETKE) protocol, an ECC-based solution tailored for the demanding environment of Internet of Drones (IoD) networks. I have demonstrated through rigorous formal security proofs within an extended Bellare–Pointcheval–Rogaway model, and further validated through formal verification using the AVISPA tool (The AVISPA Tool, available at: http://www.avispa-project.org/, accessed on 2 June 2025), that SETKE provides robust security against a wide array of known attacks, including critical man-in-the-middle and impersonation threats. The performance analysis underscored SETKE’s efficiency, highlighting its low computational demands on resource-constrained drone hardware and minimal communication overhead, making it well-suited for practical deployment. Key contributions include achieving a strong security posture with a minimal number of ECC operations and message exchanges, ensuring mutual authentication, fair key agreement, and protection against prevalent threats without imposing excessive burdens on the drones themselves. The SETKE protocol thus offers a significant contribution to enabling secure and reliable operations within IoD systems by addressing critical security challenges in a lightweight and efficient manner. Potential directions for future research include investigating decentralized trust models, conducting extensive quantitative performance comparisons, including hardware-based energy measurements with other state-of-the-art protocols, exploring enhanced anonymity features, and performing a detailed scalability analysis with implemented mitigation strategies for large-scale IoD deployments.