An Efficient Authentication Scheme Using Blockchain as a Certificate Authority for the Internet of Drones

Abstract

The Internet of Drones (IoD) has recently gained popularity in several military, commercial, and civilian applications due to its unique characteristics, such as high mobility, three-dimensional (3D) movement, and ease of deployment. Drones, on the other hand, communicate over an unencrypted wireless link and have little computational capability in a typical IoD environment, making them exposed to a wide range of cyber-attacks. Security vulnerabilities in IoD systems include man-in-the-middle attacks, impersonation, credential leaking, GPS spoofing, and drone hijacking. To avoid the occurrence of such attacks in IoD networks, we need an extremely powerful security protocol. To address these concerns, we propose a blockchain-based authentication scheme employing Hyperelliptic Curve Cryptography (HECC). The concepts of a blockchain as a Certificate Authority (CA) and a transaction as a certificate discussed in this article are meant to facilitate the use of a blockchain without CAs or a Trusted Third Party (TTP). We offer a security analysis of the proposed scheme, which demonstrates its resistance to known and unknown attacks. The proposed scheme resists replay, man-in-the-middle, device impersonation, malicious device deployment, Denial-of-Service (DoS), and De-synchronization attacks, among others. The security and performance of the proposed scheme are compared to relevant existing schemes, and their performance is shown to be better in terms of security attributes as well as computation and communication costs than existing competitive schemes. The total computation cost of the proposed scheme is 40.479 ms, which is 37.49% and 49.79% of the two comparable schemes. This shows that the proposed scheme is better suited to the IoD environment than existing competitive schemes.

1. Introduction

The Internet of Drones (IoD) is a decentralized networking architecture that uses the internet to unite drones for coordinated entry into controlled airspace [1]. In recent years, IoD networks have gained popularity due to their huge array of commercial and military applications. In times of crisis, such as the Coronavirus Disease 2019 (COVID-19) outbreak, research, academia, and business are becoming increasingly interested in remote access through drones without human interaction [2]. The IoD possesses all the technological resources necessary to accomplish their mission, including a communication module for transmitting data to Ground Stations (GSs), sensors for data collection, a memory unit for storing sensor data, and power sources [3,4,5,6,7]. If legal provisions allow drones to fly autonomously, the sky will be filled with IoD networks completing activities such as mail and package delivery, traffic monitoring, event videography, surveillance, search and rescue, and many more [8]. Figure 1 depicts a general network topology for IoD networks.

Despite the fact that IoD networks provide a number of benefits, there are still barriers to overcome before they can be successfully deployed [9]. In IoD networks, for example, drones are connected over an open wireless channel; hence, a strong and secure network design is the most critical necessity [10,11]. In addition, drones have constrained CPUs, sensors, storage, and battery lives. This is because the primary function of the drone is to collect real-time sensor data and transmit it to GSs [12]. Complex computations are extremely difficult for a drone to perform. These restrictions could negatively impact the IoD networks’ security and privacy, resulting in devastating disruption to the network’s information-exchange activities. Intruders can listen in on drones and alter their GPS positions. In addition to the possibility of the most sensitive information being stolen and transmitted between the multiple nodes of the IoD, the drone can also be captured and rendered inaccessible [13]. Once an adversary obtains the keys and breaks transmission, the information is vulnerable to compromise. Therefore, the information could be altered by the intruder, resulting in the receiver obtaining erroneous information, which can be devastating in many cases. As the IoD access point is essential to the system as a whole, authorization- and authentication-related security concerns must be effectively managed by securing the communication channel.

The aim of this article is summarized here. First, drones, configured as smart devices with limited processing power, provide lower computational and communication facility. Secondly, drones capture real-time data and relay it to their GSs over unsecure channels (public channel). Consequently, there is the potential for security threats. In recent years, several cryptographic protocols, such as authentication [14,15,16,17,18], have been proposed to address these security concerns. We are aware of the fact that a typical UAV has a limited amount of onboard computing power [19]. These methods entail substantial computation and communication costs due to the complexity of their cryptographic operations, such as RSA, bilinear pairing, and ECC. Moreover, some authentication schemes have been proposed in a certificate-based setting, which poses certificate-distribution and storage challenges. Furthermore, maintaining the certificate chain and assuming a TTP could raise the overall computational overhead; hence, the usage of a blockchain as a CA can overcome this problem [20].

Keeping the above considerations in mind, this paper proposes a blockchain-based authentication scheme employing Hyperelliptic Curve Cryptography (HECC). The notions of a blockchain as a Certificate Authority (CA) and a transaction as a certificate as defined in this article are intended to enable the usage of a blockchain without CAs or a Trusted Third Party (TTP). The following highlights the key contributions of the proposed scheme.

• We propose an authentication scheme that employs blockchain as a Certificate Authority (CA) and a transaction as a certificate to reduce high maintenance costs.
• The proposed scheme is based on the concept of Hyperelliptic Curve Cryptography (HECC), an improved form of Elliptic Curve Cryptography (ECC), which offers the same level of security as ECC, RSA, and BP with a smaller key size.
• Security analysis studies, such as formal security analysis, demonstrate that the proposed scheme is resistant to a variety of active and passive attacks by indicating that the scheme can withstand these types of attacks.
• The proposed scheme is then compared with the similar existing schemes and results show that the proposed scheme is efficient in terms of computation and communication costs.

The remaining sections of this article are arranged as follows. In Section 2, the literature review is discussed. Section 3 describes the network model and the construction of the proposed scheme. The provable security analysis is covered in Section 4. Section 5 examines performance analysis. Section 6 discusses the proposed work’s conclusions.

2. Literature Review

A secured communication link is critical in an IoD environment, because communication typically takes place over an open wireless channel. The present security procedures for IoD networks are primarily concerned with authenticity, data integrity, and secrecy. A good defense against intrusions is to implement an effective authentication method. An IoD incorporated with the BCT is expected to help innovate many different sectors of society. However, data privacy and security still remain critical issues in its development. In the literature, there are several security schemes available on the same subjects; only a few of the most relevant are listed in Table 1.

Liang et al. [21] designed a framework that combined public BC and traditional cloud storage to guarantee the integrity of data collected using drones. Instead of registering the drone itself to the BC, the data collected was stored in the cloud server for further processing. The design was scalable for large numbers of drones with acceptable overheads. Since each record is saved instantaneously in the cloud, the data’s integrity can be validated at any moment. However, the proposed scheme can be improved by lowering the overhead even further. Lin et al. [22] introduced a lightweight identity-based encryption scheme for IoD systems that protects data sent over IoD networks, despite the technique’s high computational and communication costs. Similarly, Wazid et al. [23] designed a lightweight, remote user Authentication and Key Agreement (AKA) scheme for the IoD. The proposed scheme only uses efficient one-way cryptographic hash functions and bitwise XOR operations. Wazid et al.’s scheme resists a variety of attacks but is vulnerable to user impersonation and privileged insider attacks.

Aggarwal et al. [24] introduced the use of an Ethereum-based blockchain to secure drone data-collection and transportation communications. This technique provided private and secure communication between drones and users. To reduce the burden on the drones, the data collected were stored in the BC. However, the proposed scheme did not address the drone’s latency during authorization. García-Magariño et al. [25] utilized the BC technique using a secure asymmetric encryption with a pre-shared list of official UAVs. The proposed scheme detected the wrong information when an official UAV was physically hijacked. The study only focused on the detection of the hijacked UAV. Likewise, Tian et al. [26] presented a certificate-based authentication mechanism for the IoD environment. The proposed scheme is two-tiered. In the first tier, drones can transmit or receive messages, and, in the second tier, they send real-time data. The proposed scheme is computationally demanding and lacks protection against “Ephemeral Secret Leakage (ESL)” attacks under “Canetti and Krawczyk’s model (CK-adversary model)”.

In addition to the aforementioned works, Ali et al. [27] created an AKA protocol to provide uninterrupted communication between the user and the drone. The scheme employs SHA-160 and the XOR function. According to [27], however, the scheme is vulnerable to user impersonation and privileged insider, forgery, and denial-of-service (DoS) attacks. Khalid et al. [28] proposed a decentralized mechanism for authentication utilizing fog computing technology and the concept of the public BC. In the proposed scheme, the main issue is the communication overhead. A significantly high number of messages is needed for the completion of the authentication process. Nikooghadam et al. [29] devised a secure authentication scheme based on an elliptic curve for drones to secure smart city surveillance. The proposed scheme is provably secure in the random oracle model, meeting the security requirements while keeping low computation and communication costs. Rupa Ch et al. [30] presented their solution for the security of UAV and drone applications by implementing ECC and SHA, ensuring privacy in data storage. The study proposed the use of a digital signature to help protect data from plain-text as well as cipher-text attacks. Although the proposed scheme achieved the desired security, the system can be further improved by analyzing its performance for more than one device at a time.

Bera et al. [31] presented an IoT-enabled IoD deployment with blockchain-based access control. The authors provided all types of security analysis, such as formal security under the random oracle model, informal security, and simulation-based formal security verification, to ensure that the proposed scheme can withstand a variety of potential attacks with a high probability, as required in an IoD environment. However, Bera et al.’s scheme does not support anonymity and is vulnerable to many threats, such as drone impersonation, man-in-the-middle, and replay attacks [32]. Chaudhry et al. [32] developed a generic certificate-based access-control scheme to provide inter-drone authentication and access control in the IoD domain. The authors asserted that their scheme provides anonymity and is provably resistant to known attacks. However, Chaudhry et al.’s [32] scheme is vulnerable to ESL attacks under the CK-adversary model, lacks anonymity, and is subject to drone- and GSS-impersonation attacks.

Bera et al. [33] presented another scheme, which is a blockchain-based authentication scheme for drones in an IoT-enabled agricultural setting. Tan et al. [34] designed a BC-based distributed and lightweight authentication mechanism for industrial UAVs. The BCT allows for the distributed and immutable storage of authentication information for industrial UAVs, and smart contracts make it easy for drones to obtain or update that data. However, the proposed scheme will not work in cases where UAVs must complete authentication on their own. Although BC is built to eliminate the requirement for a central authentication authority, BC’s peer nodes are still required to host the authentication service. Communication stability is also one of the key factors that will hamper the performance of the proposed scheme.

Table 1. A comparative study of the most relevant existing schemes by year, applied techniques, environment, and limitations.

Schemes	Year	Environment	Techniques	Limitations
Wazid et al. [23]	2019	IoD	∗ Exclusive-OR ∗ Hash function	∗ Vulnerable to user impersonation and privileged insider attacks.
Tian et al. [26]	2019	IoD	∗ RSA-based digital signature ∗ Modular exponentiation ∗ Hash function	∗ Vulnerable to ESL attacks under CK-adversary model.
Ali et al. [27]	2020	IoD	∗ Exclusive-OR ∗ AES ∗ Hash function	∗ Vulnerable to IND-CPA security model. ∗ No support for user anonymity and untraceability features.
Bera et al. [31]	2020	IoT/IoD	∗ ECC ∗ Hash function	∗ Does not support anonymity and is vulnerable to many threats, such as drone impersonation, man-in-the-middle, and replay attacks.
Chaudhry et al. [32]	2021	IoD	∗ ECC ∗ Hash function	∗ Vulnerable to ESL attacks under CK-adversary model. ∗ Does not support anonymity feature. ∗ Vulnerable to drone as well as GSS impersonation attacks.
Bera et al. [33]	2022	IoT/IoD	∗ ECC ∗ Hash function	∗ Certificate management issue when users exceed the maximum permitted. ∗ High computation and communication costs.

Table 1. A comparative study of the most relevant existing schemes by year, applied techniques, environment, and limitations.

Schemes	Year	Environment	Techniques	Limitations
Wazid et al. [23]	2019	IoD	∗ Exclusive-OR ∗ Hash function	∗ Vulnerable to user impersonation and privileged insider attacks.
Tian et al. [26]	2019	IoD	∗ RSA-based digital signature ∗ Modular exponentiation ∗ Hash function	∗ Vulnerable to ESL attacks under CK-adversary model.
Ali et al. [27]	2020	IoD	∗ Exclusive-OR ∗ AES ∗ Hash function	∗ Vulnerable to IND-CPA security model. ∗ No support for user anonymity and untraceability features.
Bera et al. [31]	2020	IoT/IoD	∗ ECC ∗ Hash function	∗ Does not support anonymity and is vulnerable to many threats, such as drone impersonation, man-in-the-middle, and replay attacks.
Chaudhry et al. [32]	2021	IoD	∗ ECC ∗ Hash function	∗ Vulnerable to ESL attacks under CK-adversary model. ∗ Does not support anonymity feature. ∗ Vulnerable to drone as well as GSS impersonation attacks.
Bera et al. [33]	2022	IoT/IoD	∗ ECC ∗ Hash function	∗ Certificate management issue when users exceed the maximum permitted. ∗ High computation and communication costs.

3. Network Model and Construction of the Proposed Scheme

This section provides an in-depth explanation of the network model and construction of the proposed scheme.

3.1. Network Model

The network model that has been proposed for the IoD network can be split into two parts. The first part is comprised of drones, with each individual drone being a member of a certain cluster. Drones intended for communication with the Ground Station (GS) and other drones are outfitted with 5G and 802.11ac wireless modules. Each drone is outfitted with many useful components, including cameras, an Inertial Measurement Unit (IMU), sensors, and a Global Positioning System (GPS), all of which can be used in a variety of application scenarios. The mission area is divided into zones, where a multi-cluster ad hoc network is implemented. Multiple groups of heterogeneous drones are put in distinct zones, each of which is designated a cluster. As soon as the drones begin to fly, the network is formed, together with height sensors, IMU, GPS units, and other embedded devices such as the flight controller. We assume that, when multi-cluster network development begins, the drones are aware of the zone ID, position, altitude, and velocity of their neighbors. Each cluster of this work is subject to a fixed number of drones. The second part offers authentication services in addition to blockchain functionality. With the help of the BC, which acts as a CA, a consensus can be reached on the status of drones, such as their legality and authentication procedures. The network model of the proposed scheme is depicted in Figure 2.

3.2. Construction of the Proposed Scheme

The proposed scheme combines authentication with the blockchain as a CA using the HECC concept. Both the sending drone ($DR{N}_S$) and the receiving drone ($DR{N}_R$) have public blockchain accounts with recorded in-block transactions, making them external players in the proposed scheme. The central concept of the framework is the mechanism by which the private key is produced from the previously existing transactions on the blockchain that have been signed by $DR{N}_S$and $DR{N}_R$. In this context, a transaction is considered to be a certification from $DR{N}_S$ and $DR{N}_R$. The symbols used in the construction of the proposed scheme are listed in

Table 2. List of Symbols Used in the Proposed Scheme.

S.No	Symbol	Description
1	$DR{N}_S$	Used for sending drone
2	$DR{N}_R$	Used for receiving drone
3	${\partial }_S$	Used for public key of sending drone
4	${\Upsilon }_s$	Used for private key of sending drone
5	${\partial }_R$	Used for public key of receiving drone
6	${\Upsilon }_R$	Used for private key of receiving drone
7	$M_R$	Used for receiving drone’s transaction
8	$Dat{a}_R$	Represents transaction data
9	${\mathrm{H}}^{\mathrm{mul}}$	Used for hyper elliptic curve divisor multiplication operation
10	${\mathrm{H}}^{\mathrm{add}}$	Used for hyper elliptic curve divisor addition operation
11	${\mathrm{E}}^{\mathrm{mul}}$	Used for elliptic curve point multiplication operation
12	${\mathrm{E}}^{\mathrm{add}}$	Used for elliptic curve point addition operation
13	${\mathrm{H}}^{\mathrm{f}}$	Used for hash function operation
14	$H{Y}^{bits}$	Used for hyper elliptic curve parameter size
15	$E^{IDbits}$	Used for elliptic curve identity size
16	$E^{IDT}$	Used for elliptic curve time stamp size
17	$E^{bits}$	Used for elliptic curve parameter size
18	$H^{bits}$	Used for hash value size

. The algorithm of blockchain as a CA [20] for the proposed scheme consists of the phases depicted in Figure 3, Figure 4 and Figure 5 respectively. The following are the steps of the proposed algorithm.

Initialization: 

This phase uses the following parameters for subsequent steps.

• Select the hyper elliptic curve $\left(hype{r}_{HEC}\right)$ and the genus ($G_{HEC=2}$).
• The devisor $D_{HEC}$ of hyper elliptic curve with a maximum size of 80 bits.
• A finite field $F_n$ of hyper elliptic curve of order $n=2^{80}$.
• The two hash functions $H_A$ and $H_B$ that belongs to SHA family with sizes of 256 bits.
• The parameter $X=\left\{H_A,H_B, D_{HEC},F_n,=2^{80},hype{r}_{HEC},G_{HEC=2}\right\}$ that will be accessible publicly.

Note that we propose the HEC to Bitcoin and Ethereum, and we believe it will be a better substitute for the EC given that it requires roughly half the key size to provide the same security levels.

Key Generation:

This phase is subdivided into the steps listed below.

Public and Private Key Generation: The following procedures are used to generate both the public and private keys.

• $DR{N}_S$ chooses ${\Upsilon }_S\in F_n$ and computes ${\partial }_S={\Upsilon }_s.D_{HEC}$.
• $DR{N}_S$ sets ${\Upsilon }_S$ as its private key and calculates ${\partial }_S$ as its public key
• $DR{N}_R$ chooses ${\Upsilon }_R\in F_n$ and computes ${\partial }_R={\Upsilon }_R.D_{HEC}$.
• $DR{N}_R$ sets ${\Upsilon }_R$ as its private key and calculates ${\partial }_R$ as its public key.

The addresses of $DR{N}_S$ and $DR{N}_R$are defined by the private and public key pairs. Bitcoin$DR{N}_R$addresses are generated based on a mathematical formula, Base-58 (0x00||RIPEMD 160 (SHA 256 (${\partial }_R$))). Both RIPEMD 160 and SHA 256 are well-known cryptographic hash algorithms, where Base-58 encodes a big integer as alphanumeric characters.

Public Key Extraction: Due to the fact that Bitcoin and Ethereum blockchains employ a certificate chain, $DR{N}_S$ must extract $DR{N}_R$’s public key from $DR{N}_R$’s transaction $M_R=(Dat{a}_R,{\omega }_R$, ${\rho }_R)$, where $M_R$ is publicly verifiable and tamper-resistant after it has been added to the blockchain. When a $DR{N}_S$ holds both the $hype{r}_{HEC}$ signature ${\omega }_R$, ${\rho }_R,$and the transaction data, it is feasible to obtain the $DR{N}_R$’s public key using the following computations:

• Compute $𝒬=H_A(Dat{a}_{PBR})$ and set ${\omega }_R=D_{1HEC}={\Delta }_{R1}={\Delta }_{R2}$, where ${\Delta }_{R1}=\left(D_{1HEC},D_{2HEC}\right)$ and ${\Delta }_{R2}=\left(D_{1HEC},-D_{2HEC}\right)$.
• Compute ${\partial }_R=\raisebox{1ex}{$({\rho }_R.{\Delta }_{R1}-\mathcal{𝒬}.D_{HEC})$}\!\left/ \!\raisebox{-1ex}{${\omega }_R$}\right.$ and ${\partial }_R{}^{/}=\raisebox{1ex}{$({\rho }_R.{\Delta }_{R2}-\mathcal{𝒬}.D_{HEC})$}\!\left/ \!\raisebox{-1ex}{${\omega }_R$}\right.$.

Authentication and Key Agreement:

Suppose $DR{N}_S$ seeks authentication- and secret-key management with $DR{N}_R$, then it must perform the following mathematical operations:

• It picks $\gamma \in F_n$ and computes $\varphi =\gamma .D_{HEC}=\left(D_{1HEC},D_{2HEC}\right)$.
• It sets ${\omega }_S=D_{1HEC} mod n$ and computes $\mathsf{\beta }=\gamma .{\partial }_R$.
• Computes $\mathrm{K}=H_A(I{D}_{DR{N}_R},I{D}_{DR{N}_S},\beta )$ and encrypt the private part of a data as $\mathrm{C}=\mathrm{K}⨁(Dat{a}_{PRS}$)
• Computes $\mathcal{𝒬}=H_A(Dat{a}_{PRS},Dat{a}_{PBS}$), note we have divided the data into two parts, i.e., $Dat{a}_{PRS}$ represent the private part and $Dat{a}_{PBS}$ denotes that this data will be publicly available for the drones devices.
• Computes ${\rho }_S=\raisebox{1ex}{$\left(\mathcal{𝒬}+{\Upsilon }_s\times {\omega }_S\right)$}\!\left/ \!\raisebox{-1ex}{$\gamma $}\right.$ and return (${\rho }_S,{\omega }_S,Dat{a}_{PBS}$,$\mathrm{C}$).
• Finally, $DR{N}_S$ broadcasts (${\rho }_S,{\omega }_S,Dat{a}_{PBS}$,$\mathrm{C}$) in a blockchain.
• $DR{N}_R$ can obtain (${\rho }_S,{\omega }_S,Dat{a}_{PBS}$,$\mathrm{C}$) from blockchain and compute ${\beta }^{/}={\Delta }_{R1}.{\Upsilon }_R$
• Computes $K^{/}=H_A(I{D}_{DR{N}_R},I{D}_{DR{N}_S},\beta )$ and $(Dat{a}_{PRS})=K^{/}⨁\mathrm{C}$.
• Computes${\mathcal{𝒬}}^{/}=H_A(Dat{a}_{PRS},Dat{a}_{PBS})$ and checks if ${\partial }_S{}^{/}=\raisebox{1ex}{$({\rho }_S.{\Delta }_S- {\mathcal{𝒬}}^{/}.D_{HEC})$}\!\left/ \!\raisebox{-1ex}{${\omega }_S$}\right.$, then it will be a public key of $DR{N}_S$, and it will pass the authentication process and set ($K^{/}and K$) as a secret key.

Note that, if drones choose to interact with the GS, the GS will act as a receiving drone and generate its public and private keys using the same mechanism as the receiving drone.

New Drone Addition Phase:

When a new drone wishes to join the network, it will perform the steps listed below.

• $DR{N}_{new}$ chooses ${\Upsilon }_{new}\in F_n$ and computes ${\partial }_{new}={\Upsilon }_{new}.D_{HEC}$.
• $DR{N}_{new}$ sets ${\Upsilon }_{new}$ as his private key and calculates ${\partial }_{new}$ as his public key.

The address of $DR{N}_{new}$ is defined by the private and public key pairs. Bitcoin $DR{N}_{new}$ addresses are generated based on a mathematical formula, Base-58 (0x00||RIPEMD 160 (SHA 256 (${\partial }_{\mathrm{new}}$))). Both RIPEMD 160 and SHA 256 are well-known cryptographic hash algorithms, where Base-58 encodes a big integer as alphanumeric characters. If a new drone device wants to communicate with some other receiver device such as $DR{N}_R$, then it must first extract $DR{N}_R$’s public key using the following computational steps:

• Compute $\mathcal{𝒬}=H_A(Dat{a}_{PBR})$ and set ${\omega }_R=D_{1HEC}={\Delta }_{R1}={\Delta }_{R2}$, where ${\Delta }_{R1}=\left(D_{1HEC},D_{2HEC}\right)$ and ${\Delta }_{R2}=\left(D_{1HEC},-D_{2HEC}\right)$.
• Compute ${\partial }_R=\raisebox{1ex}{$({\rho }_R.{\Delta }_{R1}-\mathcal{𝒬}.D_{HEC})$}\!\left/ \!\raisebox{-1ex}{${\omega }_R$}\right.$ and ${\partial }_R{}^{/}=\raisebox{1ex}{$({\rho }_R.{\Delta }_{R2}-\mathcal{𝒬}.D_{HEC})$}\!\left/ \!\raisebox{-1ex}{${\omega }_R$}\right.$.

4. Provable Security Analysis

We have discussed the following two theorems to confirm that the proposed scheme protects against secret-key stealing, cipher-text retrieval, and unforgeability attacks. In the subsequent theorems, we introduce two adversarial players ($A_{advr}$) and a challenger $C_{lngr}$, in which the task of ${\mathrm{C}}_{\mathrm{lngr}}$ is to solve a hyper elliptic curve Diffie-Hellman problem for ${\mathsf{A}}_{\mathrm{advr}}$. The role of ${\mathsf{A}}_{\mathrm{advr}}$ is to win in both theorems with a non-negligible advantage (${\mathsf{A}}_{\mathrm{avg}}$).

Theorem 1.

This theorem is performed to provide confidentiality, which implies that we demonstrate that the proposed scheme is secure according to the Random Oracle provable security model. The instances (${\Upsilon }_R.D_{HEC},\gamma .D_{HEC}$) are given to $C_{lngr}$, and its task to find the values that ${\Upsilon }_R$ and $\gamma$.

Proof of Theorem 1.

$C_{lngr}$ makes the following queries with $A_{avg}$ and defines some empty list that are $L_a$,$L_b$,$L_{KG}$, and $L_s$.

Initialization: 

In this phase, $C_{lngr}$ sends $X=\left\{H_A,H_B, D_{HEC},F_n,=2^{80},hype{r}_{HEC},G_{HEC=2}\right\}$to $A_{advr}$.

Phase 1:

The following queries are executed in this phase:

${\mathit{H}}_{\mathit{A}} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it searches the values ($(Dat{a}_{A_{advr}},Dat{a}_{A_{advr}},\mathcal{𝒬}$) in $L_a$, if they were available previously, then returns $\mathcal{𝒬}$, otherwise it picks $\mathcal{𝒬}\in F_n$ randomly and sends it to $A_{advr}$ and includes the value $(Dat{a}_{A_{advr}},Dat{a}_{A_{advr}},\mathcal{𝒬})$ to $L_a$.

${\mathit{H}}_{\mathit{B}}\mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it searches the values $(I{D}_{DR{N}_R},I{D}_{A_{advr}},\beta , K)$ in $L_b$, if they were available previously, then returns $K$, otherwise pick $K\in F_n$ randomly and sends it to $A_{advr}$ and includes the value $(I{D}_{DR{N}_R},I{D}_{A_{advr}},\beta , K)$ to $L_b$.

$\mathit{K}\mathit{e}\mathit{y} \mathit{G}\mathit{e}\mathit{n}\mathit{e}\mathit{r}\mathit{a}\mathit{t}\mathit{i}\mathit{o}\mathit{n} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it searches the values $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right)$ in $L_{KG}$, if they were available previously, then returns $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right),$ otherwise it picks ${\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\in F_n$ randomly and sends $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right)$ to $A_{advr}$ and includes the value $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right)$ to $L_{KG}$.

$\mathit{S}\mathit{e}\mathit{n}\mathit{d}\mathit{e}\mathit{r} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it will complete the following steps:

• It picks $\gamma \in F_n$ and computes $\varphi =\gamma .D_{HEC}=\left(D_{1HEC},D_{2HEC}\right)$.
• It sets ${\omega }_{A_{advr}}=D_{1HEC} mod n$ and computes $\mathsf{\beta }=\gamma .{\partial }_R$.
• It computes $\mathrm{K}=H_B(I{D}_{DR{N}_R},I{D}_{A_{advr}},\beta )$, where it is taken from$H_{B}Query$ and $\mathrm{C}=\mathrm{K}⨁(Dat{a}_{PRS{A}_{advr}}$).
• It computes $\mathcal{Q}=H_A(Dat{a}_{PRS{A}_{advr}},Dat{a}_{PBS{A}_{advr}}$), where it is taken from$H_{A }Query$.
• It computes ${\rho }_{A_{advr}}=\raisebox{1ex}{$\left(\mathcal{Q}+{\Upsilon }_{A_{advr}}·{\omega }_{A_{advr}}\right)$}\!\left/ \!\raisebox{-1ex}{$\gamma $}\right.$ and returns (${\rho }_{A_{advr}},{\omega }_{A_{advr}},Dat{a}_{PBS{A}_{advr}}$,$\mathrm{C}$).

$\mathit{R}\mathit{e}\mathit{c}\mathit{i}\mathit{e}\mathit{v}\mathit{e}\mathit{r} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it will complete the following steps:

• Compute ${\beta }^{/}={\Delta }_{R1}.{\Upsilon }_R$
• Compute $K^{/}=H_A(I{D}_{DR{N}_R},I{D}_{DR{N}_S},\beta )$ and $(Dat{a}_{PRS{A}_{advr}})=K^{/}⨁\mathrm{C}$
• Compute${\mathcal{𝒬}}^{/}=H_A(Dat{a}_{PRS{A}_{advr}},Dat{a}_{PBS{A}_{advr}})$ and check if ${\partial }_{A_{advr}}{}^{/}=\raisebox{1ex}{$\left(\rho .\mathsf{\Delta }- {\mathcal{𝒬}}^{/}.D_{HEC}\right)$}\!\left/ \!\raisebox{-1ex}{${\omega }_S$}\right.$, then return $Dat{a}_{PRS{A}_{advr}}$.

$Challenge:$

When all the queries of Phase 1 are finished, $A_{advr}$ choose two messages,$Dat{a}_1$ and $Dat{a}_2$, with a challenged private key${\Upsilon }_{A_{advr}}{}^{*}$. Note that the probability for the challenged private key ${\Upsilon }_{A_{advr}}$ is $\raisebox{1ex}{$1$}\!\left/ \!\raisebox{-1ex}{$ Q_{\mathrm{K}}$}\right.$. So, $C_{lngr}$ can choose bit $Ʀ \in \left\{ 0,1\right\}$ for $Dat{a}_1$ and $Dat{a}_2$ and execute a sender side algorithm to obtain the output, i.e., (${\rho }_{A_{advr}}{}^{*},{\omega }_{A_{advr}}{}^{*},Dat{a}_{PBS{A}_{advr}}{}^{*}$,${ \mathrm{C}}^{*}$) and send it to $A_{advr}$.

Queries (phase 2):

When (${\rho }_{A_{advr}}{}^{*},{\omega }_{A_{advr}}{}^{*},Dat{a}_{PBS{A}_{advr}}{}^{*}$, ${ \mathrm{C}}^{*}$) is received, $A_{advr}$ can execute a same natures queries as executed in Phase 1, neglecting the receiver side query for (${\rho }_{A_{advr}}{}^{*},{\omega }_{A_{advr}}{}^{*},Dat{a}_{PBS{A}_{advr}}{}^{*}$,${ \mathrm{C}}^{*}$).

Guess: 

After performing the above queries, $A_{advr}$ produces ${Ʀ}^{*}\in \left\{ 0,1\right\}$, if ${Ʀ}^{*}=Ʀ,$ if it is satisfied then $C_{lngr}$ will find the solution for ${\Upsilon }_R.D_{HEC},\gamma .D_{HEC}$ or obtain the original value of $H_B$. The probability of finding the correct value for$K$ is $\raisebox{1ex}{$1$}\!\left/ \!\raisebox{-1ex}{$ Q_{\mathrm{B}}$}\right.$. So, we can say that this is the value of $K$ because it is equals to compute hyper elliptic curve discrete logarithm problem. □

Theorem 2.

This theorem is executed for the purpose of Unforgeability, which implies that we demonstrate that the proposed scheme is unforgeable according to the Random Oracle provable security model. The instance ($\gamma .D_{HEC}$ ) is given to $C_{lngr}$, and its task is to find the values that $\gamma$.

Proof of Theorem 2.

$C_{lngr}$ make the following queries with $A_{avg}$ and define some empty list that are $L_a$,$L_b$,$L_{KG}$, and $L_s$.

Initialization: 

This phase $C_{lngr}$ sends $X=\left\{H_A,H_B, D_{HEC},F_n,=2^{80},hype{r}_{HEC},G_{HEC=2}\right\}$to $A_{advr}$.

Phase 1:

In this phase, the following queries are performed:

${\mathit{H}}_{\mathit{A}} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it searches the values $(Dat{a}_{A_{advr}},Dat{a}_{A_{advr}},\mathcal{𝒬}$) in $L_a$, if they were available previously, then returns $\mathcal{𝒬}$, otherwise picks $\mathcal{𝒬}\in F_n$ randomly and sends it to $A_{advr}$ and includes the value $(Dat{a}_{A_{advr}},Dat{a}_{A_{advr}},\mathcal{𝒬})$ to $L_a$.

${\mathit{H}}_{\mathit{B}}\mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it searches the values $(I{D}_{DR{N}_R},I{D}_{A_{advr}},\beta , K)$ in $L_b$, if they were available previously, then returns $K$, otherwise picks $K\in F_n$ randomly and sends it to $A_{advr}$ and includes the value $(I{D}_{DR{N}_R},I{D}_{A_{advr}},\beta , K)$ to $L_b$.

$\mathit{K}\mathit{e}\mathit{y} \mathit{G}\mathit{e}\mathit{n}\mathit{e}\mathit{r}\mathit{a}\mathit{t}\mathit{i}\mathit{o}\mathit{n} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it searches the values $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right)$ in $L_{KG}$, if they were available previously, then returns $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right),$ otherwise picks ${\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\in F_n$ randomly and sends $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right)$ to $A_{advr}$ and includes the value $\left(I{D}_{A_{advr}},{\Upsilon }_{A_{advr}}, {\partial }_{A_{advr}}\right)$ to $L_{KG}$.

$\mathit{S}\mathit{e}\mathit{n}\mathit{d}\mathit{e}\mathit{r} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it will complete the following steps.

• It picks $\gamma \in F_n$ and compute $\varphi =\gamma .D_{HEC}=\left(D_{1HEC},D_{2HEC}\right)$.
• It sets ${\omega }_{A_{advr}}=D_{1HEC} mod n$ and compute $\mathsf{\beta }=\gamma .{\partial }_R$.
• Compute $\mathrm{K}=H_B(I{D}_{DR{N}_R},I{D}_{A_{advr}},\beta )$, where it is taken from$H_{B}Query$ and $\mathrm{C}=\mathrm{K}⨁(Dat{a}_{PRS{A}_{advr}}$).
• Compute $\mathcal{𝒬}=H_A(Dat{a}_{PRS{A}_{advr}},Dat{a}_{PBS{A}_{advr}}$), where it is taken from$H_{A }Query$.
• Compute ${\rho }_{A_{advr}}=\raisebox{1ex}{$\left(\mathcal{𝒬}+{\Upsilon }_{A_{advr}}\times {\omega }_{A_{advr}}\right)$}\!\left/ \!\raisebox{-1ex}{$\gamma $}\right.$ and return (${\rho }_{A_{advr}},{\omega }_{A_{advr}},Dat{a}_{PBS{A}_{advr}}$,$\mathrm{C}$).

$\mathit{R}\mathit{e}\mathit{c}\mathit{i}\mathit{e}\mathit{v}\mathit{e}\mathit{r} \mathit{Q}\mathit{u}\mathit{e}\mathit{r}\mathit{y}\mathit{:}$

When this query is received by $C_{lngr}$, it will complete the following steps:

• Compute ${\beta }^{/}={\Delta }_{R1}.{\Upsilon }_R$
• Compute $K^{/}=H_A(I{D}_{DR{N}_R},I{D}_{DR{N}_S},\beta )$ and $(Dat{a}_{PRS{A}_{advr}})=K^{/}⨁\mathrm{C}$
• Compute${\mathcal{𝒬}}^{/}=H_A(Dat{a}_{PRS{A}_{advr}},Dat{a}_{PBS{A}_{advr}})$ and check if ${\partial }_{A_{advr}}{}^{/}=\raisebox{1ex}{$\left(\rho .\mathsf{\Delta }- {\mathcal{𝒬}}^{/}.D_{HEC}\right)$}\!\left/ \!\raisebox{-1ex}{${\omega }_S$}\right.$, then return $Dat{a}_{PRS{A}_{advr}}$.

$\mathit{O}\mathit{u}\mathit{t}\mathit{p}\mathit{u}\mathit{t}\mathit{:}$

After performing the above queries, $A_{advr}$ produces (${\rho }_{A_{advr}}{}^{*},{\omega }_{A_{advr}}{}^{*},Dat{a}_{PBS{A}_{advr}}{}^{*}$,${ \mathrm{C}}^{*}$), with the probability advantage $A_{avg}$. If $({\Upsilon }_{A_{advr}}{}^{*},{\Upsilon }_{\mathrm{R}}{}^{*})\ne ({\Upsilon }_{A_{advr}},{\Upsilon }_{\mathrm{R}})$, $C_{lngr}$ will stop the execution. If $({\Upsilon }_{A_{advr}}{}^{*},{\Upsilon }_{\mathrm{R}}{}^{*})=({\Upsilon }_{A_{advr}},{\Upsilon }_{\mathrm{R}})$, with probability ($\raisebox{1ex}{$2$}\!\left/ \!\raisebox{-1ex}{$ Q_{\mathrm{K}}$}\right.\left(Q_{\mathrm{K}}-1\right)$), then $C_{lngr}$ will choose the correct value of $K$ from the $H_B$ query. $C_{lngr}$ will find the solution for $\gamma .D_{HEC}$ or obtain the original value of $H_B$. The probability of finding the correct value for$K$ being ($\raisebox{1ex}{$2$}\!\left/ \!\raisebox{-1ex}{$ Q_{\mathrm{K}}$}\right.\left(Q_{\mathrm{K}}-1\right)$). So, we can say that this is the value of $K$ because it is equal to compute the hyper elliptic curve discrete logarithm problem. □

5. Performance Analysis

In this section, the performance of the proposed scheme in terms of the computation cost and communication overheads is evaluated. To determine the effectiveness of the proposed scheme, it is compared with two relevant existing schemes.

5.1. Computation Cost

In this section, we compare the computation cost of the major operations such as hyper elliptic curve divisor multiplication, hyper elliptic curve divisor addition, elliptic curve point multiplication, elliptic curve point addition, and the hash function. The symbols${ \mathrm{H}}^{\mathrm{mul}}$, ${\mathrm{H}}^{\mathrm{add}}$,${ \mathrm{E}}^{\mathrm{mul}}$, ${\mathrm{E}}^{\mathrm{add}}$, and ${\mathrm{H}}^{\mathrm{f}}$ denote the hyper elliptic curve divisor multiplication, hyper elliptic curve divisor addition, elliptic curve point multiplication, elliptic curve point addition, and hash function, respectively. The durations in milliseconds for ${\mathrm{E}}^{\mathrm{mul}}$, ${\mathrm{E}}^{\mathrm{add}}$, and ${\mathrm{H}}^{\mathrm{f}}$ are derived from [33], which indicates that a single ${\mathrm{E}}^{\mathrm{mul}}$ consumed 13.405, ${\mathrm{E}}^{\mathrm{add}}$ consumed 0.081, and ${\mathrm{H}}^{\mathrm{f}}$ consumed 0.056. The experiment described in [35] is conducted for ${\mathrm{E}}^{\mathrm{mul}}$, ${\mathrm{E}}^{\mathrm{add}}$, and ${\mathrm{H}}^{\mathrm{f}}$ utilizing a Samsung Galaxy S5 mobile smartphone with a Quad-core 2.45 GHz processor, 2 GB of RAM, and the Google Android 4.4.2 operating system. Since a hyper elliptic curve is the compressed form of an elliptic curve, it must take half the time in milliseconds of ${\mathrm{E}}^{\mathrm{mul}}$ and ${\mathrm{E}}^{\mathrm{add}}$ during the execution of ${ \mathrm{H}}^{\mathrm{mul}}$ and ${\mathrm{H}}^{\mathrm{add}}$ that are 6.7025 and 0.0405, respectively. In

Table 3. Comparison of Computation Costs Based on Major Operations.

Schemes	Sending Drone	Receiving Drone	Total Cost
Bera et al. [31]	$4{ \mathrm{E}}^{\mathrm{mul}}+1{\mathrm{E}}^{\mathrm{add}}+5{\mathrm{H}}^{\mathrm{f}}$	$4{ \mathrm{E}}^{\mathrm{mul}}+1{\mathrm{E}}^{\mathrm{add}}+5{\mathrm{H}}^{\mathrm{f}}$	$8{ \mathrm{E}}^{\mathrm{mul}}+2{\mathrm{E}}^{\mathrm{add}}+10{\mathrm{H}}^{\mathrm{f}}$
Bera et al. [33]	$2{ \mathrm{E}}^{\mathrm{mul}}+6{\mathrm{H}}^{\mathrm{f}}$	$4{ \mathrm{E}}^{\mathrm{mul}}+1{\mathrm{E}}^{\mathrm{add}}+8{\mathrm{H}}^{\mathrm{f}}$	$6{ \mathrm{E}}^{\mathrm{mul}}+1{\mathrm{E}}^{\mathrm{add}}+14{\mathrm{H}}^{\mathrm{f}}$
Proposed Scheme	$3{ \mathrm{H}}^{\mathrm{mul}}+2{\mathrm{H}}^{\mathrm{f}}+1{\mathrm{H}}^{\mathrm{add}}$	$3{ \mathrm{H}}^{\mathrm{mul}}+2{\mathrm{H}}^{\mathrm{f}}$	$6{ \mathrm{H}}^{\mathrm{mul}}+4{\mathrm{H}}^{\mathrm{f}}+1{\mathrm{H}}^{\mathrm{add}}$

and

Table 4. Comparison of Computation Costs (in ms).

Schemes	Sending Drone	Receiving Drone	Total Cost (ms)
Bera et al. [31]	$4 \left(13.405\right)+1\left(0.081\right)+5\left(0.056\right)$ = 53.981	$4 \left(13.045\right)+1\left(0.081\right)+5\left(0.056\right)$ = 53.981	$8 \left(13.405\right)+2\left(0.081\right)+10\left(0.056\right)$ = 107.962
Bera et al. [33]	$2 \left(13.045\right)+6\left(0.056\right)$ =27.146	$4 \left(13.405\right)+1\left(0.081\right)+8 \left(0.056\right)$ = 54.149	$6 \left(13.405\right)+1\left(0.081\right)+14\left(0.056\right)$ = 81.295
Proposed Scheme	$3 \left(6.7025\right)+2\left(0.056\right)+1\left(0.0405\right)$ = 20.26	$3 \left(6.7025\right)+2\left(0.056\right)$ = 20.2195	$6 \left(6.7025\right)+4\left(0.056\right)+1\left(0.0405\right)$ = 40.4795

, we compare the computation cost on the sender’s and receiver’s sides for the proposed scheme to the schemes of Bera et al. [31] and Bera et al. [33] in terms of major operations and milliseconds, respectively. In addition, Figure 6 depicts a comparison of the computation cost.

5.2. Communication Overhead

In this subsection, we compare the proposed scheme’s communication overheads against those of Bera et al.’s [31] and Bera et al.’s [33] schemes.

Table 5. Comparison of Communication Overheads (in bits).

Schemes	Communication Overhead	Communication Overhead in Bits
Bera et al. [31]	$2|E^{IDbits}$$|+3|E^{IDT}$$|+4|E^{bits}\left|+2|H^{bits}\right|$	$2 \ast |160$$|+3 \ast |160$$|+4 \ast \left|160\right|+2\ast \left|256\right|=$ 1952
Bera et al. [33]	$4|E^{IDbits}$$|+4|E^{IDT}$$|+11|E^{bits}|$	$4 \ast |160$$|+4 \ast |160$$|+11\ast \left|160\right|=$ 3040
Proposed Scheme	$4\left|H{Y}^{bits}\right|$	$4 \ast \left|80\right|=$ 320

summarizes the major operations used by the proposed scheme and the other two relevant schemes, as well as the communication overhead in bits. $H{Y}^{bits}$, $E^{IDbits}$, $E^{IDT}$, $E^{bits}$, and $H^{bits}$ denote hyper elliptic curve parameter size, elliptic curve identity size, elliptic curve time stamp size, hash value size, and elliptic curve parameter size, in which $H^{bits}=80 \mathrm{bits}$, $E^{IDbits}=160 \mathrm{bits}, E^{IDT}=160 \mathrm{bits}$, $E^{bits}=160 \mathrm{bits}$, and $H^{bits}=256 \mathrm{bits}$. Figure 7 illustrates the comparison of the communication overheads.

6. Conclusions

This article presents a blockchain-based authentication scheme employing Hyperelliptic Curve Cryptography (HECC). The notions of a blockchain as a Certificate Authority (CA) and a transaction as a certificate outlined in this article are intended to enable the implementation of a blockchain without CAs or a Trusted Third Party (TTP). We provide a security analysis of the proposed scheme, which proves its resilience to both active and passive threats. Comparing the security and performance of the proposed scheme to comparable existing schemes, the findings indicate that the proposed scheme performs better in terms of the computation cost and communication overheads. The computation cost of the proposed scheme is 40.479 milliseconds, which is significantly less than Bera et al.’s [31] and Bera et al.’s [33] schemes, which required 107.962 and 81.295 milliseconds, respectively. Similarly, the proposed scheme outperforms its counterpart in terms of communication overheads, with 320 bits vs. 1952 and 3040 bits for Bera et al.’s [31] and Bera et al.’s [33] schemes, respectively. All of these outcomes indicate the practicality of the proposed scheme in light of the resource-constrained nature of IoD networks.