# A Resource-Friendly Authentication Protocol for UAV-Based Massive Crowd Management Systems

Authors: Bander A. Alzahrani; Ahmed Barnawi; Shehzad Ashraf Chaudhry
Journal: Security and Communication Networks
 (2021)

---

## Abstract

As a part of the smart city revolution, crowd management is an emerging trend and it can enhance the quality of life. Unmanned ariel vehicles (UAVs) can help in making the crowd management process more efficient and more accurate. UAVs can monitor and collect environmental-related surveillance data and share real-time information with each other and with the decision makers. However, the battery-operated UAVs communicate over the open public channel making the privacy and security of the UAVs a crucial element in mission-critical applications. The weaknesses of the existing scheme pave the way to design a new lightweight authentication scheme for UAV environments. In this article, we present a symmetric key primitive-based scheme and provide authentication among a user and a UAV through an intermediate control center. Due to usage of symmetric key and elliptic curve cryptography, the proposed scheme fulfils the performance requirements of the UAVs. The security of the proposed scheme is substantiated through BAN logic, along with a discussion on security features extended by the proposed scheme. The performance and security comparisons show that the proposed scheme provides adequate security and efficiency and can be practically deployed in real UAV environments.


---

## Body

## 1. Introduction

With the advancements in software and hardware infrastructure for information and communication technologies, the UAV communication has become a reality, which is making daily life more easy and automated. The UAVs, also called drones, can be deployed in a variety of applications including smart cargo and surveillance. The UAVs can enhance quality of life and can be deployed at remote and inaccessible locations like depths and mountain peaks. In contrast to traditional roadways, the UAV/drone can reach inaccessible locations in a very speedy manner [1–3]. Moreover, in many emergency-like situations, the traditional transportation and surveillance could not respond in a rapid way and the slow response can cause irreparable losses like lives. Initially, developed for military operations, the UAVs can be very beneficial in many applications including smart agriculture, surveillance, goods delivery operations, and so on [4]. UAVs have many properties similar to IoT devices and have sensors, transmitters, and receivers for communication with the other entities including humans [5]. The UAVs collect specific environment data for initiating the decision-making process [6]. Reddy et al. [4] provided a good survey of the usage of UAVs in agriculture and related fields for interested readers. Among many other applications, UAVs can be adopted for crowdsourcing systems [7]. However, very similar to generic IoT devices, the UAVs are battery powered and can be used by dishonest attackers for deceitful intentions, and such unintended usage can be harmful for decision making. The attacker can trace user locations and can effect the quality of services as well as forge the collected data and deviate the UAVs from their designated task [8]. Therefore, the communication among several UAVs and users need to be secured from unintended receivers. The following subsections briefly explain the adopted system architecture and adversarial model for the UAV-based crowdsourcing systems.


### 1.1. System Architecture

A typical UAV-based crowd monitoring system is shown in Figure1. The UAVs are deployed at several geographical monitoring locations, where each geographical location can be monitored by one or more UAVs which are connected to a ground station (GS). All GSs are linked with the UAV (trusted) control center TC. The proposed architecture also contains the cloud edge and a monitoring system to facilitate monitoring-based decision making through human interaction. The UAVs monitor the crowd and send the sensed information to the respective GS. The GS sends these data to the control center and finally this information is sent to the crowd monitoring system. The GS acts as an intermediate entity that accumulates and sends the UAV sensed data, whereas UAV, TC, and the user at monitoring system are responsible for the confidentiality of the sensed data during transmission and authenticity of the communicating entities, i.e., user, TC, and UAV.Figure 1
UAV-based crowd management system.


### 1.2. Adversarial Model

The communication among UAVs and other devices including user andTC is carried out on the insecure public channel. Therefore, UAV communication has an attractive infrastructure for the attackers for initiation of forgery. As per the widely accepted adversarial model, DY model (Dolev–Yao model) [9], the attacker can listen, modify, replay, and stop a message exchanged among two entities of a UAV network [10–14]. The attacker can try to forge any message sent from any of the entities including user, TC, and UAV. In addition to the DY model, the strong de facto CK adversarial model [15] has got more attention from the researchers. In this paper, we consider the CK model with an adversary having all capabilities of the adversary considered in DY model; in addition, the adversary can compromise any one of the long-term secrets, ephemeral secrets, and session keys. Therefore, in the CK model, the session keys should be formed using long and short-term keys. Moreover, the session keys should be statistically independent of each other, and the compromise of a session key may not affect any other. Moreover, as per [16, 17], if an attacker captures a drone or user mobile device, they can extract parameters stored in the captured/stolen device. In this paper, we consider an extended CK (eCK) adversarial model [18], where an attacker can also launch a key compromise impersonation (KCI) attack.


## 1.1. System Architecture

A typical UAV-based crowd monitoring system is shown in Figure1. The UAVs are deployed at several geographical monitoring locations, where each geographical location can be monitored by one or more UAVs which are connected to a ground station (GS). All GSs are linked with the UAV (trusted) control center TC. The proposed architecture also contains the cloud edge and a monitoring system to facilitate monitoring-based decision making through human interaction. The UAVs monitor the crowd and send the sensed information to the respective GS. The GS sends these data to the control center and finally this information is sent to the crowd monitoring system. The GS acts as an intermediate entity that accumulates and sends the UAV sensed data, whereas UAV, TC, and the user at monitoring system are responsible for the confidentiality of the sensed data during transmission and authenticity of the communicating entities, i.e., user, TC, and UAV.Figure 1
UAV-based crowd management system.


## 1.2. Adversarial Model

The communication among UAVs and other devices including user andTC is carried out on the insecure public channel. Therefore, UAV communication has an attractive infrastructure for the attackers for initiation of forgery. As per the widely accepted adversarial model, DY model (Dolev–Yao model) [9], the attacker can listen, modify, replay, and stop a message exchanged among two entities of a UAV network [10–14]. The attacker can try to forge any message sent from any of the entities including user, TC, and UAV. In addition to the DY model, the strong de facto CK adversarial model [15] has got more attention from the researchers. In this paper, we consider the CK model with an adversary having all capabilities of the adversary considered in DY model; in addition, the adversary can compromise any one of the long-term secrets, ephemeral secrets, and session keys. Therefore, in the CK model, the session keys should be formed using long and short-term keys. Moreover, the session keys should be statistically independent of each other, and the compromise of a session key may not affect any other. Moreover, as per [16, 17], if an attacker captures a drone or user mobile device, they can extract parameters stored in the captured/stolen device. In this paper, we consider an extended CK (eCK) adversarial model [18], where an attacker can also launch a key compromise impersonation (KCI) attack.


## 2. Related Work

To secure communication among the users and UAVs/relevant devices, some access control/authentication protocols are proposed. For securing user-UAV communication, a temporal credential-based framework is proposed using symmetric primitives [19]. The scheme of Srinivas et al. [19] lacks resistance to impersonation based on stolen verifier; also, their scheme lacks anonymity as proved in [20]. The scheme proposed by Ali et al. could not resist ephemeral secret leakage attacks. The scheme proposed by Zhou et al. [21] in a distributed IoT environment using pairing was proved as insecure to IoT device forgery attacks [22]. In 2019, Wazid et al. [23] also proposed a new protocol for securing user-UAV communication through symmetric key primitives. As debated by Hussain et al. [3], Wazid et al.’s scheme is weak against stolen verifier-based forgery of users, UAVs, and trusted control centers. The scheme of Wazid et al. also lacks untraceability. Another scheme was proposed by Zhang et al. in 2020 by using symmetric primitives [24], which also lacks forward secrecy and is weak against insiders and stolen verifier attacks. Zhang et al. managed anonymity using a parameter PIDs, which is generic for all users and any dishonest user can break the anonymity and untraceability of the user requesting for login. Moreover, in Zhang et al.’s scheme, the user credentials are not verified appropriately. Therefore, the login request can be sent to the TC even when wrong credentials are entered. In 2020, Bera et al. proposed a scheme for UAV network using blockchains and certificates constructed upon elliptic curve-based cryptography (ECC) [25]. However, their scheme was debated for having critical weaknesses against man-in-the-middle, replay, and impersonation attacks and lack of anonymity by Chaudhry et al. [2]. In the same year, i.e., 2020, Bera et al. proposed another scheme [26] using blockchains and certificates using ECC. Unfortunately, Bera et al.’s scheme does not extend anonymity owing to the use of static identity RIDDRj of the UAV/user. Likewise, as proved by Irshad et al. [27], there is no verification of the signatures generated by the ground station from the UAV in Bera et al.’s second scheme [26]. It was also debated in [27] that owing to the similar identity RIDDNi for all sessions, the scheme of Bera et al. [26] does not extend UAV anonymity. Another scheme using symmetric key and elliptic curve cryptography was proposed recently by Nikooghadam et al. [28]. The related works are summarized in Table 1, which gives the properties of existing methods along with their weaknesses and cryptographic method used.Table 1
Summary of related methods.
ProtocolYearCMAProperties/limitationsTurjman et al. [29]2017ECC and PRLacks resistance against replay attack.Srinivas et al. [19]2019SKPLacks anonymity and resistance to impersonation based on stolen verifier.Zhou et al. [21]2019ECC and PRInsecure against IoT device forgery attack.Wazid et al. [23]2019SKPWeak against stolen verifier-based forgery of users, UAVs, and trusted control centers and lacks untraceability.Zhang et al. [24]2020SKPLacks forward secrecy and is weak against insiders and stolen verifier attacks.Bera et al.-I [25]2020ECC and BCWeak against man-in-the-middle, replay, and impersonation attacks and lacks anonymity.Bera et al.-II [26]2020ECC and BCLacks anonymity and the UAV does not verify signature authenticity of the ground station.Kirsal [30]2020ECC and PRLacks perfect forward secrecy and is weak against known session key and insider attack.Nikooghadam et al. [28]2021ECCLacks anonymity and is weak against stolen verifier attack and secret parameter exposure.Proposed—ECCProvides resistance to known attacks with comparable computation and communication costs.Note. CMA: cryptographic method adopted; ECC: elliptic curve cryptography; PR: bilinear pairing; SKP: symmetric key primitives; BC: blockchain.


### 2.1. Motivation and Contributions

In the recent past, many authentication schemes were designed for securing the communication among UAV, user, andTC. However, some of these schemes do not offer performance efficiency and some other schemes suffer from one or many insecurities. In this connection, very recently in 2021, Nikooghadam et al. proposed a symmetric key-based lightweight authentication scheme to secure the communication among users, UAV, and TC [28]. However, it is proved in the coming sections/subsections of this paper that Nikooghadam et al.’s scheme has many insecurities and cannot be deployed in real-world scenarios. The multi-fold contributions of this study include the following:(i)
Initially, we highlight the importance of secure communication among entities of UAV environments.(ii)
We revisited the authentication scheme proposed by Nikooghadam et al. and proved that Nikooghadam et al.’s scheme has vulnerabilities against stolen verifier attacks and lacks user anonymity and untraceability. It is also proved that Nikooghadam et al.’s scheme is not practical due to the exposure of secret parameters of the UAVs and the users.(iii)
A security-enhanced authentication scheme is proposed in this paper using only the lightweight symmetric key elliptic curve-based cryptography.(iv)
We used BAN logic and informal discussion on security properties for proving the security of the proposed scheme.(v)
By using MIRACL library, we set up a real-time environment, where we used a smartphone Xiaomi-Redmi Note-8 for replicating the user mobile device, Raspberry Pi3B + Cortex (A53-ARMv8) to replicate a UAV, and HP-EliteBook 8460-P to serve as the control centerTC. We implemented the proposed scheme’s primitives on these three devices for computation of the execution time of an authentication round.(vi)
Finally, a comparative study among proposed and related schemes based on performance and security features is conducted.


## 2.1. Motivation and Contributions

In the recent past, many authentication schemes were designed for securing the communication among UAV, user, andTC. However, some of these schemes do not offer performance efficiency and some other schemes suffer from one or many insecurities. In this connection, very recently in 2021, Nikooghadam et al. proposed a symmetric key-based lightweight authentication scheme to secure the communication among users, UAV, and TC [28]. However, it is proved in the coming sections/subsections of this paper that Nikooghadam et al.’s scheme has many insecurities and cannot be deployed in real-world scenarios. The multi-fold contributions of this study include the following:(i)
Initially, we highlight the importance of secure communication among entities of UAV environments.(ii)
We revisited the authentication scheme proposed by Nikooghadam et al. and proved that Nikooghadam et al.’s scheme has vulnerabilities against stolen verifier attacks and lacks user anonymity and untraceability. It is also proved that Nikooghadam et al.’s scheme is not practical due to the exposure of secret parameters of the UAVs and the users.(iii)
A security-enhanced authentication scheme is proposed in this paper using only the lightweight symmetric key elliptic curve-based cryptography.(iv)
We used BAN logic and informal discussion on security properties for proving the security of the proposed scheme.(v)
By using MIRACL library, we set up a real-time environment, where we used a smartphone Xiaomi-Redmi Note-8 for replicating the user mobile device, Raspberry Pi3B + Cortex (A53-ARMv8) to replicate a UAV, and HP-EliteBook 8460-P to serve as the control centerTC. We implemented the proposed scheme’s primitives on these three devices for computation of the execution time of an authentication round.(vi)
Finally, a comparative study among proposed and related schemes based on performance and security features is conducted.


## 3. Revisiting the Scheme of Nikooghadam et al

The following subsections provide details on different phases of Nikooghadam et al.’s scheme for extending the authentication and session key among a user and a UAV through the control center. The notations used for the technical details of this paper are defined as per Table2.Table 2
Notations.
SymbolsExplanationsTCTrusted control centerUi,DrjUser, UAVIDi,DIDiReal and pseudo-identities of userPrtc,PubtcPublic private key pair ofTCPri,PrjSecret keys ofVhi and DrjPIDjPseudo-identity ofDrj‖,⊕H⋅Concatenation, XOR, hashEs⋅,Ds⋅Enc-decryption usings as key


### 3.1. Initialization

The initialization is performed by the control centerTC by selecting an elliptic curve Ep:y2=x3+αx+βmodp∈Fp, where p≥160bits, α,β∈Fp, and 4α3+25β2modp≠0. Now, TC selects a base point P∈Ep and a private key Prtc. TC also selects a hash function H⋅:0,1∗⟶0,1l, where l≥160bits. Finally, TC secretly stores Prtc and publishes Ep,G,P,H⋅.


### 3.2. User Registration

For completion of the registration,Ui selects an identity and passwords IDi,PWi and a random number di∈Zp. Ui now computes PDWi=HHIDi‖di⊕HPWi‖di and sends IDi,PDWi to TC. On reception of IDi,PDWi, the TC checks the availability of IDi and availability of IDi, and the TC randomly selects fi,qi and computes DIDi=HIDi‖fi, Ki=HDIDi‖Prtc‖qi, Ai=HDIDi‖PDWi‖fi‖Ki, and Bi=HAi‖DIDi and transmits fi,Ki,Bi,H⋅ to Ui securely, in addition to storing the tuple IDi,DIDi,Ki in its verifier table. On receiving fi,Ki,Bi,H⋅, Ui stores these parameters in the memory of mobile device.


### 3.3. UAV Registration

For completion of the registration,Drj selects and transmits an identity IDj to TC. On reception of IDj, the TC checks the availability of IDj. On availability of IDi, the TC randomly selects aj and computes PIDj=Haj‖IDj and Keyj=HIDj‖Prtc‖aj and transmits IDj,PIDj,Keyj,H⋅ to Ui securely, in addition to storing the pair IDj,PIDj,Keyj in its verifier table. On receiving IDj,PIDj,Keyj,H., Drj stores the pair in its memory.


### 3.4. Login and Authentication

For login and authentication, the userUi inputs the tuple IDi,PWi, and the mobile device computes PDWi∗=HHIDi‖di⊕HPWi‖di, DIDi∗=HIDi‖fi, and Ai∗=HDIDi‖PDWi‖fi‖Ki and checks Bi=?HAi∗‖DIDi. On success, the following steps as depicted in Figure 2 are performed between Ui, TC, and Drj.ZDA 1:Ui⟶TC:M1=DIDi,A1i,Zi,PIDj,Ti.Ui generates Ti,zi and computes A1i=HTi‖DIDi‖Ki, Zi=ziP, and sends M1=DIDi,A1i,Zi,PIDj,Ti to TC.ZDA 2:TC⟶Drj:M2=DIDi,PIDj,Kij,Zi,A3i,Ttc.TC on receiving M1=Ci,Ri,ρi,Ti checks the freshness of M1 by checking Tc−Ti≤ΔT. On proven freshness, the TC extracts the related tuple IDi,DIDi,Ki and checks A1i=?HTi‖DIDi‖Ki. On success, TC generates Ttc and computes Kij=Ki⊕Keyj and A3i=HPIDj‖Keyj‖IDj‖Ki. The TC transmits M2=DIDi,PIDj,Kij,Zi,A3i,Ttc to Drj.ZDA 3:Drj⟶Ui:M3=Zj,Autj,Tj.Drj on receiving M2=DIDi,PIDj,Kij,Zi,A3i,Ttc checks the freshness of M3 by checking Tc−Ttc≤ΔT. On proven freshness, Drj computes Ki=Kij⊕Keyj and checks A3i=?HPIDj‖Keyj‖IDj‖Ki. On proven validity, TC generates gj,Tj and computes Zij=gjZi=gjziP, SKij=HIDj‖Zij‖Ki‖DIDi, Zj=gjP, and Autj=HSKij‖DIDi‖Tj‖Ki. Lastly, TC sends M3=Zj,Autj,Tj to Ui.ZDA 4:Ui on receiving M3=Zj,Autj,Tj checks the freshness of M3 by checking Tc−Tj≤ΔT. On proven freshness, Ui computes Zij=ziZj=zigjP and the session key SKij=HIDj‖Zij‖Ki‖DIDi and checks the validity of session key by verifying Autj=?HSKij‖DIDi‖Tj‖Ki. On success, Ui keeps the SKij as session key authenticated with Drj.Figure 2
Nikooghadam et al.’s scheme.


## 3.1. Initialization

The initialization is performed by the control centerTC by selecting an elliptic curve Ep:y2=x3+αx+βmodp∈Fp, where p≥160bits, α,β∈Fp, and 4α3+25β2modp≠0. Now, TC selects a base point P∈Ep and a private key Prtc. TC also selects a hash function H⋅:0,1∗⟶0,1l, where l≥160bits. Finally, TC secretly stores Prtc and publishes Ep,G,P,H⋅.


## 3.2. User Registration

For completion of the registration,Ui selects an identity and passwords IDi,PWi and a random number di∈Zp. Ui now computes PDWi=HHIDi‖di⊕HPWi‖di and sends IDi,PDWi to TC. On reception of IDi,PDWi, the TC checks the availability of IDi and availability of IDi, and the TC randomly selects fi,qi and computes DIDi=HIDi‖fi, Ki=HDIDi‖Prtc‖qi, Ai=HDIDi‖PDWi‖fi‖Ki, and Bi=HAi‖DIDi and transmits fi,Ki,Bi,H⋅ to Ui securely, in addition to storing the tuple IDi,DIDi,Ki in its verifier table. On receiving fi,Ki,Bi,H⋅, Ui stores these parameters in the memory of mobile device.


## 3.3. UAV Registration

For completion of the registration,Drj selects and transmits an identity IDj to TC. On reception of IDj, the TC checks the availability of IDj. On availability of IDi, the TC randomly selects aj and computes PIDj=Haj‖IDj and Keyj=HIDj‖Prtc‖aj and transmits IDj,PIDj,Keyj,H⋅ to Ui securely, in addition to storing the pair IDj,PIDj,Keyj in its verifier table. On receiving IDj,PIDj,Keyj,H., Drj stores the pair in its memory.


## 3.4. Login and Authentication

For login and authentication, the userUi inputs the tuple IDi,PWi, and the mobile device computes PDWi∗=HHIDi‖di⊕HPWi‖di, DIDi∗=HIDi‖fi, and Ai∗=HDIDi‖PDWi‖fi‖Ki and checks Bi=?HAi∗‖DIDi. On success, the following steps as depicted in Figure 2 are performed between Ui, TC, and Drj.ZDA 1:Ui⟶TC:M1=DIDi,A1i,Zi,PIDj,Ti.Ui generates Ti,zi and computes A1i=HTi‖DIDi‖Ki, Zi=ziP, and sends M1=DIDi,A1i,Zi,PIDj,Ti to TC.ZDA 2:TC⟶Drj:M2=DIDi,PIDj,Kij,Zi,A3i,Ttc.TC on receiving M1=Ci,Ri,ρi,Ti checks the freshness of M1 by checking Tc−Ti≤ΔT. On proven freshness, the TC extracts the related tuple IDi,DIDi,Ki and checks A1i=?HTi‖DIDi‖Ki. On success, TC generates Ttc and computes Kij=Ki⊕Keyj and A3i=HPIDj‖Keyj‖IDj‖Ki. The TC transmits M2=DIDi,PIDj,Kij,Zi,A3i,Ttc to Drj.ZDA 3:Drj⟶Ui:M3=Zj,Autj,Tj.Drj on receiving M2=DIDi,PIDj,Kij,Zi,A3i,Ttc checks the freshness of M3 by checking Tc−Ttc≤ΔT. On proven freshness, Drj computes Ki=Kij⊕Keyj and checks A3i=?HPIDj‖Keyj‖IDj‖Ki. On proven validity, TC generates gj,Tj and computes Zij=gjZi=gjziP, SKij=HIDj‖Zij‖Ki‖DIDi, Zj=gjP, and Autj=HSKij‖DIDi‖Tj‖Ki. Lastly, TC sends M3=Zj,Autj,Tj to Ui.ZDA 4:Ui on receiving M3=Zj,Autj,Tj checks the freshness of M3 by checking Tc−Tj≤ΔT. On proven freshness, Ui computes Zij=ziZj=zigjP and the session key SKij=HIDj‖Zij‖Ki‖DIDi and checks the validity of session key by verifying Autj=?HSKij‖DIDi‖Tj‖Ki. On success, Ui keeps the SKij as session key authenticated with Drj.Figure 2
Nikooghadam et al.’s scheme.


## 4. Weaknesses of Nikooghadam et al.’s Scheme

This section explains the weaknesses of the scheme of Nikooghadam et al. [28] against secret key exposure and stolen verifier attack. Both of these attacks are very critical and common and render the scheme of Nikooghadam et al. inapplicable and impractical.


### 4.1. Stolen Verifier Attack

In the scheme of Nikooghadam et al., the trusted control centerTC stores two separate verifier tables consisting of tuple IDi,DIDi,Ki, where i=1,2…n and IDj,PIDj,Keyj,H⋅, where j=1,2…m each for users (n numbers of users) and UAVs (m number of UAVs), respectively. As per the adopted CK adversarial model, the tables stored in the memory of TC can be exposed to the attacker. The whole authentication process can be compromised if these verifier tables are exposed to an attacker. An attacker with a verifier relating to users can impersonate on behalf of all users and an attacker with a verifier relating to the UAVs can impersonate on behalf of all UAVs. Therefore, the scheme of Nikooghadam et al. is not practical and is subject to stolen verifier attacks.


### 4.2. Lack of Anonymity and Untraceability

In the scheme of Nikooghadam et al.’s scheme, the user sends a pseudo-identityDIDi, which remains the same for all sessions. Therefore, Nikooghadam et al.’s scheme lacks anonymity and untraceability.


### 4.3. Secret Parameter Exposure

In the scheme of Nikooghadam et al., let userUi be a dishonest user. Ui can initiate the login/authentication request, and for this, Ui transmits M1=DIDi,A1i,Zi,PIDj,Ti to TC and TC transmits M2=DIDi,PIDj,Kij,Zi,A3i,Ttc to Drj. The dishonest user Ui while listening to the channel can receive M2=DIDi,PIDj,Kij,Zi,A3i,Ttc. Ui can compute the secret parameter of Drj as follows:(1)Keyj=Kij⊕Keyi.It is very clear that through equation (1), the dishonest user has computed the secret parameter Keyj of the UAV Drj.


#### 4.3.1. Related Attacks Based on Secret Parameter Exposure

Once the secret parameterKeyj of a UAV Drj is revealed to a dishonest user say Ui, the Ui now using Keyj can impersonate not only on behalf of Drj but Ui can also use Keyj to extract the secret parameter Ki of any user requesting a session with Drj. Therefore, based on the secret parameter exposure attack, the malicious user can impersonate on behalf of any user requesting login with the Drj. Similarly, the malicious user can extract secret parameters of several or even all of the UAVs’ Drj:j=1,2…m, and this can also lead to exposure of the secret parameters Ki:i=1,2…n of all the registered users and the malicious user can impersonate on behalf of all the UAVs as well as all the users. Therefore, the scheme of Nikooghadam et al. cannot be practically deployed in any environment due to its weaknesses against the secret parameter exposure.


## 4.1. Stolen Verifier Attack

In the scheme of Nikooghadam et al., the trusted control centerTC stores two separate verifier tables consisting of tuple IDi,DIDi,Ki, where i=1,2…n and IDj,PIDj,Keyj,H⋅, where j=1,2…m each for users (n numbers of users) and UAVs (m number of UAVs), respectively. As per the adopted CK adversarial model, the tables stored in the memory of TC can be exposed to the attacker. The whole authentication process can be compromised if these verifier tables are exposed to an attacker. An attacker with a verifier relating to users can impersonate on behalf of all users and an attacker with a verifier relating to the UAVs can impersonate on behalf of all UAVs. Therefore, the scheme of Nikooghadam et al. is not practical and is subject to stolen verifier attacks.


## 4.2. Lack of Anonymity and Untraceability

In the scheme of Nikooghadam et al.’s scheme, the user sends a pseudo-identityDIDi, which remains the same for all sessions. Therefore, Nikooghadam et al.’s scheme lacks anonymity and untraceability.


## 4.3. Secret Parameter Exposure

In the scheme of Nikooghadam et al., let userUi be a dishonest user. Ui can initiate the login/authentication request, and for this, Ui transmits M1=DIDi,A1i,Zi,PIDj,Ti to TC and TC transmits M2=DIDi,PIDj,Kij,Zi,A3i,Ttc to Drj. The dishonest user Ui while listening to the channel can receive M2=DIDi,PIDj,Kij,Zi,A3i,Ttc. Ui can compute the secret parameter of Drj as follows:(1)Keyj=Kij⊕Keyi.It is very clear that through equation (1), the dishonest user has computed the secret parameter Keyj of the UAV Drj.


### 4.3.1. Related Attacks Based on Secret Parameter Exposure

Once the secret parameterKeyj of a UAV Drj is revealed to a dishonest user say Ui, the Ui now using Keyj can impersonate not only on behalf of Drj but Ui can also use Keyj to extract the secret parameter Ki of any user requesting a session with Drj. Therefore, based on the secret parameter exposure attack, the malicious user can impersonate on behalf of any user requesting login with the Drj. Similarly, the malicious user can extract secret parameters of several or even all of the UAVs’ Drj:j=1,2…m, and this can also lead to exposure of the secret parameters Ki:i=1,2…n of all the registered users and the malicious user can impersonate on behalf of all the UAVs as well as all the users. Therefore, the scheme of Nikooghadam et al. cannot be practically deployed in any environment due to its weaknesses against the secret parameter exposure.


## 4.3.1. Related Attacks Based on Secret Parameter Exposure

Once the secret parameterKeyj of a UAV Drj is revealed to a dishonest user say Ui, the Ui now using Keyj can impersonate not only on behalf of Drj but Ui can also use Keyj to extract the secret parameter Ki of any user requesting a session with Drj. Therefore, based on the secret parameter exposure attack, the malicious user can impersonate on behalf of any user requesting login with the Drj. Similarly, the malicious user can extract secret parameters of several or even all of the UAVs’ Drj:j=1,2…m, and this can also lead to exposure of the secret parameters Ki:i=1,2…n of all the registered users and the malicious user can impersonate on behalf of all the UAVs as well as all the users. Therefore, the scheme of Nikooghadam et al. cannot be practically deployed in any environment due to its weaknesses against the secret parameter exposure.


## 5. Proposed Scheme

In this section, we propose our improved scheme.


### 5.1. Initialization

The initialization is performed by the control centerTC by selecting an elliptic curve Ep:y2=x3+αx+βmodp∈Fp, where p≥160bits, α,β∈Fp, and 4α3+25β2modp≠0. Now, TC selects a base point P∈Ep, a private key Prtc, and a public key Pubtc=PrtcP. TC also selects hash functions H.:0,1∗⟶0,1l, where l≥160bits, and a block cipher encryption/decryption algorithm Ek/Dk⋅. Finally, TC secretly stores Prtc and publishes Ep,Pubtc,P,H.,Ek/Dk..


### 5.2. User Registration

For crowd monitoring, a user has to register with the system. After registration, a user at monitoring system can authenticate a UAV through TC and can receive and interpret the crowd management-related data. For completion of the registration,Ui selects an identity and passwords IDi,PWi and computes PDWi=HHIDi‖PWi. Now, Ui sends IDi,PDWi to TC. On reception of IDi,PDWi, TC checks the availability of IDi and availability of IDi, and TC randomly selects ki and computes Pri=HIDi‖Prtc‖ki, Ai=Pri⊕PDWi, and Bi=HAi‖Pri‖PDWi‖IDi and transmits Ai,Bi,H. to Ui securely, in addition to storing the tuple IDi,Pri in its verifier table. On receiving Ai,Bi,H⋅, Ui stores these parameters in the memory of mobile device. The registration process of the user is furnished through secure/private channel.


### 5.3. UAV Registration

For completion of the registration,Drj (the UAV) selects identity DIDj and sends it to TC. On reception of DIDj, TC checks the availability of DIDj. On availability of DIDj, TC randomly selects kj and computes Prj=HDIDj‖Prtc‖kj and transmits Prj to Drj securely, in addition to storing the pair DIDj,kj in its verifier table. On receiving Prj, Drj stores Prj in its memory and publishes DIDj. Like user registration, the registration process of the UAV is furnished through secure/private channel.


### 5.4. Authentication

For login, the userUi inputs the tuple IDi,PWi, and the reader computes PDWi=HIDi‖PWi and Pri=Ai⊕PDWi and checks Bi=?HAi‖Pri‖PDWi‖IDi. On success, Ui continues for authentication phase as depicted in Figure 3 detailed as follows:IDA 1:Ui⟶TC:M1=Ci,Ri,ρi,Ti.Initially,Ui generates αi,Ti and computes ri=Hαi‖Pri‖Ti, Ri=riP, Si=riPubtc and using Six (x-coordinates of Si) encrypts IDi,DIDj,Ti, i.e., Ci=ESixIDi,DIDj,Ti. Now, Ui computes ρi=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti and sends M1=Ci,Ri,ρi,Ti to the trusted center TC.IDA 2:TC⟶Drj:M2=Ctc,Ri,δtc,Ttc.TC on receiving M1=Ci,Ri,ρi,Ti checks the freshness of M1 by checking Tc−Ti≤ΔT. On proven freshness, TC computes Si=PrtcRi=riPubtc and decrypts Ci and gets IDi,DIDj,Ti=DSixCi. TC now verifies the validity of Ti,IDi,DIDj, and on proven validity, TC computes Pri=HIDi‖Prtc‖ki and verifies the validity of ρi=?HDIDj‖IDi‖Ri‖Si‖Pri‖Ti. On success, TC computes Prj=HDIDj‖Prtc‖kj and generates Ttc. The TC now computes βij=HPri‖Si‖Ti, Ctc=EHPrj‖DIDj‖TtcIDi,DIDj,βij,Ttc, and δtc=HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc and transmits M2=Ctc,Ri,δtc,Ttc to Drj.IDA 3:Drj⟶TC:M3=Rj,Ψj,ωj,Tj.TC on receiving M2=Ci,Ri,ρi,Cj.δj,Tj checks the freshness of M3 by checking Tc−Ttc≤ΔT. On proven freshness, Drj decrypts Ctc and gets IDi,DIDj,βij,Ttc=DHPrj‖DIDj‖TtcCtc. Now, Drj verifies the validity of δj=?HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc. On proven validity of δj, Drj generates rj,Tj and computes Rj=rjP, Ψj=HPrj‖δj‖βij‖DIDj‖Rj‖Tj, γij=HPrj‖βij‖Tj and session key SKij=HrjRi‖Ri‖Rj‖βij‖γij. Drj further computes ωj=HSKij‖DIDj‖IDi‖γij and transmits M3=Rj,Ψj,ωj,Tj to the TC.IDA 4:TC⟶Ui:M4=Rj,ωtc,γtc,Ttc2.TC on receiving M3=Rj,Ψj,ωj,Tj checks the freshness of M3 by checking Tc−Tj≤ΔT. On proven freshness, Ui checks Ψj=HPrj‖δj‖βij‖DIDj‖Rj‖Tj, and on proven validity, TC computes γij=HPrj‖βij‖Tj. Now, TC generates Ttc2 and computes γtc=γij⊕Siy, ωtc=HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj. TC finally sends M4=Rj,ωtc,γtc,Ttc2 to Ui.IDA 5:Ui on receiving M4=Rj,ωtc,γtc,Ttc2 checks the freshness of M4 by checking Tc−Ttc2≤ΔT. On proven freshness, Ui computes γij=γtc⊕Siy, βij=HPri‖Si‖Ti and the session key SKij=HrjRi‖Ri‖Rj‖βij‖γij. Finally, Ui computes ωj=HSKij‖DIDj‖IDi‖γij and checks the validity of session key by verifying ωtc=?HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj. Ui keeps the SKij as session key authenticated with Drj.Figure 3
Proposed scheme.


## 5.1. Initialization

The initialization is performed by the control centerTC by selecting an elliptic curve Ep:y2=x3+αx+βmodp∈Fp, where p≥160bits, α,β∈Fp, and 4α3+25β2modp≠0. Now, TC selects a base point P∈Ep, a private key Prtc, and a public key Pubtc=PrtcP. TC also selects hash functions H.:0,1∗⟶0,1l, where l≥160bits, and a block cipher encryption/decryption algorithm Ek/Dk⋅. Finally, TC secretly stores Prtc and publishes Ep,Pubtc,P,H.,Ek/Dk..


## 5.2. User Registration

For crowd monitoring, a user has to register with the system. After registration, a user at monitoring system can authenticate a UAV through TC and can receive and interpret the crowd management-related data. For completion of the registration,Ui selects an identity and passwords IDi,PWi and computes PDWi=HHIDi‖PWi. Now, Ui sends IDi,PDWi to TC. On reception of IDi,PDWi, TC checks the availability of IDi and availability of IDi, and TC randomly selects ki and computes Pri=HIDi‖Prtc‖ki, Ai=Pri⊕PDWi, and Bi=HAi‖Pri‖PDWi‖IDi and transmits Ai,Bi,H. to Ui securely, in addition to storing the tuple IDi,Pri in its verifier table. On receiving Ai,Bi,H⋅, Ui stores these parameters in the memory of mobile device. The registration process of the user is furnished through secure/private channel.


## 5.3. UAV Registration

For completion of the registration,Drj (the UAV) selects identity DIDj and sends it to TC. On reception of DIDj, TC checks the availability of DIDj. On availability of DIDj, TC randomly selects kj and computes Prj=HDIDj‖Prtc‖kj and transmits Prj to Drj securely, in addition to storing the pair DIDj,kj in its verifier table. On receiving Prj, Drj stores Prj in its memory and publishes DIDj. Like user registration, the registration process of the UAV is furnished through secure/private channel.


## 5.4. Authentication

For login, the userUi inputs the tuple IDi,PWi, and the reader computes PDWi=HIDi‖PWi and Pri=Ai⊕PDWi and checks Bi=?HAi‖Pri‖PDWi‖IDi. On success, Ui continues for authentication phase as depicted in Figure 3 detailed as follows:IDA 1:Ui⟶TC:M1=Ci,Ri,ρi,Ti.Initially,Ui generates αi,Ti and computes ri=Hαi‖Pri‖Ti, Ri=riP, Si=riPubtc and using Six (x-coordinates of Si) encrypts IDi,DIDj,Ti, i.e., Ci=ESixIDi,DIDj,Ti. Now, Ui computes ρi=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti and sends M1=Ci,Ri,ρi,Ti to the trusted center TC.IDA 2:TC⟶Drj:M2=Ctc,Ri,δtc,Ttc.TC on receiving M1=Ci,Ri,ρi,Ti checks the freshness of M1 by checking Tc−Ti≤ΔT. On proven freshness, TC computes Si=PrtcRi=riPubtc and decrypts Ci and gets IDi,DIDj,Ti=DSixCi. TC now verifies the validity of Ti,IDi,DIDj, and on proven validity, TC computes Pri=HIDi‖Prtc‖ki and verifies the validity of ρi=?HDIDj‖IDi‖Ri‖Si‖Pri‖Ti. On success, TC computes Prj=HDIDj‖Prtc‖kj and generates Ttc. The TC now computes βij=HPri‖Si‖Ti, Ctc=EHPrj‖DIDj‖TtcIDi,DIDj,βij,Ttc, and δtc=HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc and transmits M2=Ctc,Ri,δtc,Ttc to Drj.IDA 3:Drj⟶TC:M3=Rj,Ψj,ωj,Tj.TC on receiving M2=Ci,Ri,ρi,Cj.δj,Tj checks the freshness of M3 by checking Tc−Ttc≤ΔT. On proven freshness, Drj decrypts Ctc and gets IDi,DIDj,βij,Ttc=DHPrj‖DIDj‖TtcCtc. Now, Drj verifies the validity of δj=?HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc. On proven validity of δj, Drj generates rj,Tj and computes Rj=rjP, Ψj=HPrj‖δj‖βij‖DIDj‖Rj‖Tj, γij=HPrj‖βij‖Tj and session key SKij=HrjRi‖Ri‖Rj‖βij‖γij. Drj further computes ωj=HSKij‖DIDj‖IDi‖γij and transmits M3=Rj,Ψj,ωj,Tj to the TC.IDA 4:TC⟶Ui:M4=Rj,ωtc,γtc,Ttc2.TC on receiving M3=Rj,Ψj,ωj,Tj checks the freshness of M3 by checking Tc−Tj≤ΔT. On proven freshness, Ui checks Ψj=HPrj‖δj‖βij‖DIDj‖Rj‖Tj, and on proven validity, TC computes γij=HPrj‖βij‖Tj. Now, TC generates Ttc2 and computes γtc=γij⊕Siy, ωtc=HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj. TC finally sends M4=Rj,ωtc,γtc,Ttc2 to Ui.IDA 5:Ui on receiving M4=Rj,ωtc,γtc,Ttc2 checks the freshness of M4 by checking Tc−Ttc2≤ΔT. On proven freshness, Ui computes γij=γtc⊕Siy, βij=HPri‖Si‖Ti and the session key SKij=HrjRi‖Ri‖Rj‖βij‖γij. Finally, Ui computes ωj=HSKij‖DIDj‖IDi‖γij and checks the validity of session key by verifying ωtc=?HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj. Ui keeps the SKij as session key authenticated with Drj.Figure 3
Proposed scheme.


## 6. Security Analysis and Discussion

In the following subsections, we prove the security of the proposed scheme formally as well as provide discussion on the attack resilience of the proposed scheme.


### 6.1. Formal Security Analysis through BAN

We demonstrate the formal security analysis of the contributed work using Burrows–Abadi–Needham logic (BAN) logic [31]. In this model, we conduct the security analysis with the consideration of session key protection and distribution along with mutual authenticity between the legal participants. Some related notations in this analysis are explained below:(i)
S|≡:Z The principal S believes Z.(ii)
S⊲Z:S sees Z.(iii)
S|∼Z:S once said Z, and S believes it to be true.(iv)
S|⇒Z:S has jurisdiction over Z.(v)
#Z: Z is not replayed and is fresh.(vi)
Z,Z′: Z or Z′ are parts of a message.(vii)
Z,Z′k: using K, Z or Z′ are encrypted through symmetric encryption.(viii)
S⟷KS′: the communication among S and S′ is secured using K as the key.Some related rules employed in this analysis are given as follows:Rule 1: message meaning rule:(2)S|≡S⟶KS′,S⊲ZZ′S≡S′∼Z.Rule 2: nonce verification rule:(3)S|≡#Z,S≡S′∼ZS≡S′≡Z.Rule 3: jurisdiction rule:(4)S|≡S′⇒Z,S|≡S′|≡ZS|≡Z.Rule 4: freshness conjunction rule:(5)S|≡#ZS|≡#Z,Z′.Rule 5: belief rule:(6)S|≡Z,S|≡Z′S|≡Z,Z′.Rule 6: session key rule:(7)S|≡#Z,S|≡S′≡ZS|≡S⟷KS′.(i)
G-1:TC|≡TC⟷SiUi.(ii)
G-2:TC|≡Ui|≡TC⟷SiUi.(iii)
G-3:Ui||≡TC⟷SiUi.(iv)
G-4:Ui|≡TC|≡TC⟷SiUi.(v)
G-5:Drj|≡Drj⟷SkijUi.(vi)
G-6:Ui||≡Drj⟷SkijUi.The idealized form of exchanged messages is given as follows:(i)
M1: Ui⟶TC:Ci,Ri,ρi,Ti:IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(ii)
M2: TC⟶Drj:Ctc,Ri,δtc,Ttc:DIDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βij,Ttc(iii)
M3: Drj⟶TC:Rj,Ψj,ωj,Tj:rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,Tj(iv)
M4: TC⟶Ui:Rj,ωtc,γtc,Ttc2:Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2Next, the following premises have been constructed to prove the model.(1)
W1:Ui|≡#Ti(2)
W2: TC|≡#Ttc(3)
W3:Drj|≡#Tj(4)
W4:Ui|≡Ui⟷PriTC(5)
W5:Ui|≡Ui⟷SKijDrj(6)
W6: TC|≡TC⟷PriUi(7)
W7: TC|≡TC⟷PrjDrj(8)
W8:Drj|≡Drj⟷SKijUi(9)
W9:Drj|≡Drj⟷PrjTC(10)
W10:Ui|≡TC|⇒Ui⟷SiTC(11)
W11: TC|≡Ui|⇒Ui⟷SiTC(12)
W12:Drj||≡Ui|⇒Ui⟷RiDrj(13)
W13: TC|≡Drj|⇒Drj⟷βijTC(14)
W14:Drj|≡TC|⇒Ui⟷RiTC(15)
W15:Ui|≡Drj|⇒Ui⟷γijTCNow we utilize the above idealizations in the following formulations consideringM1 and M2 of the idealized formalization:(i)
M1: Ui⟶TC:Ci,Ri,ρi,Ti:IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(ii)
M2: TC⟶Drj:Ctc,Ri,δtc,Ttc:DIDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βij,TtcUsing seeing rule forM1 and M2, we get(1)
D1: TC⊲Ci,Ri,ρi,Ti:IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(2)
D2:Drj⊲Ctc,Ri,δtc,Ttc:IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,Ttc,Prj,βij,TtcAccording toD1,D2,W8,W9 and message meaning rule, we get(3)
D3: TC|≡Ui∼IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(4)
D4:Drj|≡TC∼Ttc,IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βijUsingD3, W1, freshness conjunction, and nonce verification rules, we get(5)
D5: TC|≡Ui≡IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,PriUsingD4, W2, freshness conjucatenation, and nonce verification rules, we get(6)
D6:Drj|≡TC≡Ttc,riP,IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,Ctc,IDi,DIDj,Ri,TtcPrj,βijUsingD5, W12 and jurisdiction rule, we get(7)
D7: TC|≡IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,PriUsingD6, W14 and jurisdiction rule, we get(8)
D8:Drj|≡IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βij,TtcUsingD5, D7 and session key rule, we get(9)
D9: TC|≡TC⟷SiUi (G-1)UsingD5, D7, W6, W8 and nonce verification rule, we get(10)
D10:Drj|≡Drj⟷SKijUi (G-5)ConsiderM3 of the idealized form:(11)
M3: Drj⟶TC:Rj,Ψj,ωj,Tj:rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,TjBy applying seeing rule forM3, we get(12)
D11: TC⊲Rj,Ψj,ωj,Tj:rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,TjUsingD11, W7 and message meaning rule, we get(13)
D12: TC|≡Drj∼rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,TjUsingD12, W3, W13, freshness conjucatenation, and nonce verification rules, we get(14)
D13: TC|≡Drj|≡rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,Tj(15)
Ui|≡TC⟷SiUi (G-3)(16)
Ui|≡TC|≡TC⟷SiUi (G-4)Next, consideringM4 idealized form, we get(17)
M4: TC⟶Ui:Rj,ωtc,γtc,Ttc2:Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2By applying seeing rule forM4, we get(18)
D14:Ui⊲Rj,ωtc,γtc,Ttc2:Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2UsingD14, W4, W5, W11 and message meaning rule, we get(19)
D15:Ui|≡TC∼Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2By usingD15, W2, W3, freshness conjucatenation, and nonce verification rules, we get(20)
D16:Ui|≡TC|≡Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2UsingD16, W4, W10, W15 and jurisdiction rule, we get(21)
D17:Ui|≡Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2According toD17, we apply the session key rule as(22)
D18: TC|≡Ui|≡TC⟷SiUi (G-2)UsingD18, W2, W14, we apply the session key rule as(23)
D19:Ui|≡Drj⟷SKijUi (G-6)This analysis sufficiently proves that the proposed model achieves the specified goals by attaining mutual authenticity among the involved participants.


### 6.2. Informal Security Analysis

An informal security discussion on the security features of the proposed scheme is provided in the following subsection.


#### 6.2.1. Mutual Authentication

In the proposed model,Ui and Drj entities mutually authenticate one another. This is because when Ui submits the authentication request message M1=Ci,Ri,ρi,Ti towards TC, the latter verifies the freshness of timestamp Ti, and on successful verification, it computes Si and Pri to further calculate HDIDj‖IDi‖Ri‖Si‖Pri‖Ti and match against ρi. If the equation holds valid, TC confirms the authenticity for Ui. Similarly, Drj after receiving the message checks the freshness of Ttc timestamp. Next, it computes HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc using shared secret Prj and compares it against δj to completely verify TC. Likewise, Drj communicates the parameter γij to Ui through TC. Then, Ui verifies the authenticity of Drj by computing βij=HPri‖Si‖Ti, SKij=HrjRi‖Ri‖Rj‖βij‖γij, and ωj=HSKij‖DIDj‖IDi‖γij. Then, it further computes HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj and verifies the equality check against ωtc. If this holds true, Ui validates the authenticity for Drj. Hence, in the proposed scheme, both entities Ui and Drj mutually authenticate each other with the help of a trusted intermediary, i.e., TC.


#### 6.2.2. User Anonymity

In the proposed scheme,Ui remains anonymous while submitting the authentication request to TC. Ui submits the message M1=Ci,Ri,ρi,Ti to TC without disclosing the identity as plaintext. Since Ui encrypts its identity IDi as Ci=ESixIDi;DIDj,Ti using Six, Ci can only be decrypted by a legitimate TC. Moreover, the scheme supports untraceability since the authentication messages in our scheme do not bear any message parameter that remains constant among various sessions that could help the adversary in identifying the location of the user. Hence, our scheme ensures anonymity as well as untraceability for the user.


#### 6.2.3.Ui Impersonation

The proposed scheme is immune toUi impersonation attack. In case an adversary attempts to construct a fake authentication request message M1=Ci,Ri,ρi,Ti with a fresh timestamp Ti, it would not be able to do this until it has access to secret key Pri which can only be computed by valid TC and can never be guessed or accessed by the adversary under ordinary circumstances. Hence, our scheme can resist Ui impersonation attack.


#### 6.2.4. Man-in-the-Middle Attack

In the proposed scheme, no malicious entity can engage in the ongoing communication session of the legal participants. This is because of the fact that both participants such asUi and Drj are deployed with secret keys, i.e., Pri, Prj, respectively, during the initialization phase by the trusted TC. Thus, all participants having possession to those secrets may engage in mutual authentication process and construct the mutually agreed session key SKij=HriRj‖Ri‖Rj‖βij‖γij on legal basis. Hence, the proposed scheme is very much immune to man-in-the-middle attack.


#### 6.2.5. Session Key Security

The contributed protocol supports session key security because it supports mutual authentication and can resist man-in-the-middle as well as impersonation attacks, and the resistance against man-in-the-middle and impersonation attacks provide sufficient grounds to maintain this fact that our scheme ensures session key security in the face of crafty and malicious adversaries.


#### 6.2.6. Denial of Service Attack

In DoS attack, an adversary may exploit vulnerability in the scheme if it is designed in such a way that the adversary may fabricate multiple authentication requests, while the server gets engaged to entertain each fake request and maintains that session for an indefinite time. In this manner, the attacker could initiate multiple fake requests towards the server and affect its capacity to serve the legal authentication request, which undermines its serving capacity. In our scheme,TC aborts the session immediately if either the timestamp Ti is not found to be fresh or the equality ρi?=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti does not hold true. In both cases, TC drops the session immediately which helps the protocol to avoid denial of service attack on the TC’s end.


#### 6.2.7. Replay Attack

Our scheme employs the feature of timestamp that allows the protocol participants to verify the freshness of the received message. To construct the authentication requestM1=Ci,Ri,ρi,Ti, the Ui engenders the latest timestamp Ti and embeds the same in the parameter ρi=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti for submission to TC. TC verifies the freshness of timestamp Ti and verifies the calculated HDIDj‖IDi‖Ri‖Si‖Pri‖Ti against ρi. If true, it confirms the validity of Ui. Likewise, Drj after receiving the message confirms the freshness of Ttc timestamp and proceeds further to compute the response message. Upon successful verification, Drj submits the parameter γij towards Ui via TC. Then, Ui verifies the authenticity of Drj by computing βij and verifying the corresponding timestamp Ttc2. In this manner, the replay attack can be successfully thwarted for the proposed scheme.


#### 6.2.8. Physical Capturing Attack

In our scheme, the control centerTC stores DIDj,Prj in the memory of a UAV (say Drj), where Prj=HDIDj‖Prtc‖kj. In addition, the TC stores DIDj,kj in its verifier memory. DIDj is a randomly selected identity of the Drj, and it is different for each of the drone. Likewise, kj is also uniquely selected for each of the drones. Henceforth, DIDj,Prj are computed uniquely for each of the UAV. In case a UAV Drj is physically captured by a malicious entity, it cannot extend any advantage to the malicious entity to successfully forge any response message M3¯=Rj¯,Ψj¯,ωj¯,Tj¯ on behalf of another UAV say Drj¯, due to the uniqueness of parameters stored in each of Drj and Drj¯. In this manner, physical capturing is thwarted for the proposed scheme.


#### 6.2.9. Perfect Forward Secrecy

In our scheme, the computation of the session keySKij=HrjRi‖Ri‖Rj‖βij‖γij requires both session specific secrets ri,rj as well as long-term secrets of both the entities βij,γij, where βij=HPri‖Si‖Ti and γij=HPrj‖βij‖Tj. It is clear that βij requires private key Pri of the user and γij requires private key Prj of the UAV. Every session consists of unique short-term ri,rj and long-term βij,γij parameters. The leakage of any of the session key or any of the long/short-term parameters may not extend any advantage to the attacker to gain abilities for compromising any future session.


## 6.1. Formal Security Analysis through BAN

We demonstrate the formal security analysis of the contributed work using Burrows–Abadi–Needham logic (BAN) logic [31]. In this model, we conduct the security analysis with the consideration of session key protection and distribution along with mutual authenticity between the legal participants. Some related notations in this analysis are explained below:(i)
S|≡:Z The principal S believes Z.(ii)
S⊲Z:S sees Z.(iii)
S|∼Z:S once said Z, and S believes it to be true.(iv)
S|⇒Z:S has jurisdiction over Z.(v)
#Z: Z is not replayed and is fresh.(vi)
Z,Z′: Z or Z′ are parts of a message.(vii)
Z,Z′k: using K, Z or Z′ are encrypted through symmetric encryption.(viii)
S⟷KS′: the communication among S and S′ is secured using K as the key.Some related rules employed in this analysis are given as follows:Rule 1: message meaning rule:(2)S|≡S⟶KS′,S⊲ZZ′S≡S′∼Z.Rule 2: nonce verification rule:(3)S|≡#Z,S≡S′∼ZS≡S′≡Z.Rule 3: jurisdiction rule:(4)S|≡S′⇒Z,S|≡S′|≡ZS|≡Z.Rule 4: freshness conjunction rule:(5)S|≡#ZS|≡#Z,Z′.Rule 5: belief rule:(6)S|≡Z,S|≡Z′S|≡Z,Z′.Rule 6: session key rule:(7)S|≡#Z,S|≡S′≡ZS|≡S⟷KS′.(i)
G-1:TC|≡TC⟷SiUi.(ii)
G-2:TC|≡Ui|≡TC⟷SiUi.(iii)
G-3:Ui||≡TC⟷SiUi.(iv)
G-4:Ui|≡TC|≡TC⟷SiUi.(v)
G-5:Drj|≡Drj⟷SkijUi.(vi)
G-6:Ui||≡Drj⟷SkijUi.The idealized form of exchanged messages is given as follows:(i)
M1: Ui⟶TC:Ci,Ri,ρi,Ti:IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(ii)
M2: TC⟶Drj:Ctc,Ri,δtc,Ttc:DIDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βij,Ttc(iii)
M3: Drj⟶TC:Rj,Ψj,ωj,Tj:rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,Tj(iv)
M4: TC⟶Ui:Rj,ωtc,γtc,Ttc2:Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2Next, the following premises have been constructed to prove the model.(1)
W1:Ui|≡#Ti(2)
W2: TC|≡#Ttc(3)
W3:Drj|≡#Tj(4)
W4:Ui|≡Ui⟷PriTC(5)
W5:Ui|≡Ui⟷SKijDrj(6)
W6: TC|≡TC⟷PriUi(7)
W7: TC|≡TC⟷PrjDrj(8)
W8:Drj|≡Drj⟷SKijUi(9)
W9:Drj|≡Drj⟷PrjTC(10)
W10:Ui|≡TC|⇒Ui⟷SiTC(11)
W11: TC|≡Ui|⇒Ui⟷SiTC(12)
W12:Drj||≡Ui|⇒Ui⟷RiDrj(13)
W13: TC|≡Drj|⇒Drj⟷βijTC(14)
W14:Drj|≡TC|⇒Ui⟷RiTC(15)
W15:Ui|≡Drj|⇒Ui⟷γijTCNow we utilize the above idealizations in the following formulations consideringM1 and M2 of the idealized formalization:(i)
M1: Ui⟶TC:Ci,Ri,ρi,Ti:IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(ii)
M2: TC⟶Drj:Ctc,Ri,δtc,Ttc:DIDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βij,TtcUsing seeing rule forM1 and M2, we get(1)
D1: TC⊲Ci,Ri,ρi,Ti:IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(2)
D2:Drj⊲Ctc,Ri,δtc,Ttc:IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,Ttc,Prj,βij,TtcAccording toD1,D2,W8,W9 and message meaning rule, we get(3)
D3: TC|≡Ui∼IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,Pri(4)
D4:Drj|≡TC∼Ttc,IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βijUsingD3, W1, freshness conjunction, and nonce verification rules, we get(5)
D5: TC|≡Ui≡IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,PriUsingD4, W2, freshness conjucatenation, and nonce verification rules, we get(6)
D6:Drj|≡TC≡Ttc,riP,IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,Ctc,IDi,DIDj,Ri,TtcPrj,βijUsingD5, W12 and jurisdiction rule, we get(7)
D7: TC|≡IDi,DIDj,TiSi,riP,DIDj,IDi,Ri,TiSi,PriUsingD6, W14 and jurisdiction rule, we get(8)
D8:Drj|≡IDi,DIDj,βij,TtcHPrj,DIDj,Ttc,riP,Ctc,IDi,DIDj,Ri,TtcPrj,βij,TtcUsingD5, D7 and session key rule, we get(9)
D9: TC|≡TC⟷SiUi (G-1)UsingD5, D7, W6, W8 and nonce verification rule, we get(10)
D10:Drj|≡Drj⟷SKijUi (G-5)ConsiderM3 of the idealized form:(11)
M3: Drj⟶TC:Rj,Ψj,ωj,Tj:rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,TjBy applying seeing rule forM3, we get(12)
D11: TC⊲Rj,Ψj,ωj,Tj:rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,TjUsingD11, W7 and message meaning rule, we get(13)
D12: TC|≡Drj∼rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,TjUsingD12, W3, W13, freshness conjucatenation, and nonce verification rules, we get(14)
D13: TC|≡Drj|≡rjP,δj,DIDj,Rj,TjPrj,βij,DIDj,IDi,TjPrj,βijSKij,Tj(15)
Ui|≡TC⟷SiUi (G-3)(16)
Ui|≡TC|≡TC⟷SiUi (G-4)Next, consideringM4 idealized form, we get(17)
M4: TC⟶Ui:Rj,ωtc,γtc,Ttc2:Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2By applying seeing rule forM4, we get(18)
D14:Ui⊲Rj,ωtc,γtc,Ttc2:Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2UsingD14, W4, W5, W11 and message meaning rule, we get(19)
D15:Ui|≡TC∼Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2By usingD15, W2, W3, freshness conjucatenation, and nonce verification rules, we get(20)
D16:Ui|≡TC|≡Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2UsingD16, W4, W10, W15 and jurisdiction rule, we get(21)
D17:Ui|≡Rj,DIDj,IDi,Ri,RjSi,γijSiy,Ttc2According toD17, we apply the session key rule as(22)
D18: TC|≡Ui|≡TC⟷SiUi (G-2)UsingD18, W2, W14, we apply the session key rule as(23)
D19:Ui|≡Drj⟷SKijUi (G-6)This analysis sufficiently proves that the proposed model achieves the specified goals by attaining mutual authenticity among the involved participants.


## 6.2. Informal Security Analysis

An informal security discussion on the security features of the proposed scheme is provided in the following subsection.


### 6.2.1. Mutual Authentication

In the proposed model,Ui and Drj entities mutually authenticate one another. This is because when Ui submits the authentication request message M1=Ci,Ri,ρi,Ti towards TC, the latter verifies the freshness of timestamp Ti, and on successful verification, it computes Si and Pri to further calculate HDIDj‖IDi‖Ri‖Si‖Pri‖Ti and match against ρi. If the equation holds valid, TC confirms the authenticity for Ui. Similarly, Drj after receiving the message checks the freshness of Ttc timestamp. Next, it computes HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc using shared secret Prj and compares it against δj to completely verify TC. Likewise, Drj communicates the parameter γij to Ui through TC. Then, Ui verifies the authenticity of Drj by computing βij=HPri‖Si‖Ti, SKij=HrjRi‖Ri‖Rj‖βij‖γij, and ωj=HSKij‖DIDj‖IDi‖γij. Then, it further computes HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj and verifies the equality check against ωtc. If this holds true, Ui validates the authenticity for Drj. Hence, in the proposed scheme, both entities Ui and Drj mutually authenticate each other with the help of a trusted intermediary, i.e., TC.


### 6.2.2. User Anonymity

In the proposed scheme,Ui remains anonymous while submitting the authentication request to TC. Ui submits the message M1=Ci,Ri,ρi,Ti to TC without disclosing the identity as plaintext. Since Ui encrypts its identity IDi as Ci=ESixIDi;DIDj,Ti using Six, Ci can only be decrypted by a legitimate TC. Moreover, the scheme supports untraceability since the authentication messages in our scheme do not bear any message parameter that remains constant among various sessions that could help the adversary in identifying the location of the user. Hence, our scheme ensures anonymity as well as untraceability for the user.


### 6.2.3.Ui Impersonation

The proposed scheme is immune toUi impersonation attack. In case an adversary attempts to construct a fake authentication request message M1=Ci,Ri,ρi,Ti with a fresh timestamp Ti, it would not be able to do this until it has access to secret key Pri which can only be computed by valid TC and can never be guessed or accessed by the adversary under ordinary circumstances. Hence, our scheme can resist Ui impersonation attack.


### 6.2.4. Man-in-the-Middle Attack

In the proposed scheme, no malicious entity can engage in the ongoing communication session of the legal participants. This is because of the fact that both participants such asUi and Drj are deployed with secret keys, i.e., Pri, Prj, respectively, during the initialization phase by the trusted TC. Thus, all participants having possession to those secrets may engage in mutual authentication process and construct the mutually agreed session key SKij=HriRj‖Ri‖Rj‖βij‖γij on legal basis. Hence, the proposed scheme is very much immune to man-in-the-middle attack.


### 6.2.5. Session Key Security

The contributed protocol supports session key security because it supports mutual authentication and can resist man-in-the-middle as well as impersonation attacks, and the resistance against man-in-the-middle and impersonation attacks provide sufficient grounds to maintain this fact that our scheme ensures session key security in the face of crafty and malicious adversaries.


### 6.2.6. Denial of Service Attack

In DoS attack, an adversary may exploit vulnerability in the scheme if it is designed in such a way that the adversary may fabricate multiple authentication requests, while the server gets engaged to entertain each fake request and maintains that session for an indefinite time. In this manner, the attacker could initiate multiple fake requests towards the server and affect its capacity to serve the legal authentication request, which undermines its serving capacity. In our scheme,TC aborts the session immediately if either the timestamp Ti is not found to be fresh or the equality ρi?=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti does not hold true. In both cases, TC drops the session immediately which helps the protocol to avoid denial of service attack on the TC’s end.


### 6.2.7. Replay Attack

Our scheme employs the feature of timestamp that allows the protocol participants to verify the freshness of the received message. To construct the authentication requestM1=Ci,Ri,ρi,Ti, the Ui engenders the latest timestamp Ti and embeds the same in the parameter ρi=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti for submission to TC. TC verifies the freshness of timestamp Ti and verifies the calculated HDIDj‖IDi‖Ri‖Si‖Pri‖Ti against ρi. If true, it confirms the validity of Ui. Likewise, Drj after receiving the message confirms the freshness of Ttc timestamp and proceeds further to compute the response message. Upon successful verification, Drj submits the parameter γij towards Ui via TC. Then, Ui verifies the authenticity of Drj by computing βij and verifying the corresponding timestamp Ttc2. In this manner, the replay attack can be successfully thwarted for the proposed scheme.


### 6.2.8. Physical Capturing Attack

In our scheme, the control centerTC stores DIDj,Prj in the memory of a UAV (say Drj), where Prj=HDIDj‖Prtc‖kj. In addition, the TC stores DIDj,kj in its verifier memory. DIDj is a randomly selected identity of the Drj, and it is different for each of the drone. Likewise, kj is also uniquely selected for each of the drones. Henceforth, DIDj,Prj are computed uniquely for each of the UAV. In case a UAV Drj is physically captured by a malicious entity, it cannot extend any advantage to the malicious entity to successfully forge any response message M3¯=Rj¯,Ψj¯,ωj¯,Tj¯ on behalf of another UAV say Drj¯, due to the uniqueness of parameters stored in each of Drj and Drj¯. In this manner, physical capturing is thwarted for the proposed scheme.


### 6.2.9. Perfect Forward Secrecy

In our scheme, the computation of the session keySKij=HrjRi‖Ri‖Rj‖βij‖γij requires both session specific secrets ri,rj as well as long-term secrets of both the entities βij,γij, where βij=HPri‖Si‖Ti and γij=HPrj‖βij‖Tj. It is clear that βij requires private key Pri of the user and γij requires private key Prj of the UAV. Every session consists of unique short-term ri,rj and long-term βij,γij parameters. The leakage of any of the session key or any of the long/short-term parameters may not extend any advantage to the attacker to gain abilities for compromising any future session.


## 6.2.1. Mutual Authentication

In the proposed model,Ui and Drj entities mutually authenticate one another. This is because when Ui submits the authentication request message M1=Ci,Ri,ρi,Ti towards TC, the latter verifies the freshness of timestamp Ti, and on successful verification, it computes Si and Pri to further calculate HDIDj‖IDi‖Ri‖Si‖Pri‖Ti and match against ρi. If the equation holds valid, TC confirms the authenticity for Ui. Similarly, Drj after receiving the message checks the freshness of Ttc timestamp. Next, it computes HCtc‖IDi‖DIDj‖Ri‖Prj‖βij‖Ttc using shared secret Prj and compares it against δj to completely verify TC. Likewise, Drj communicates the parameter γij to Ui through TC. Then, Ui verifies the authenticity of Drj by computing βij=HPri‖Si‖Ti, SKij=HrjRi‖Ri‖Rj‖βij‖γij, and ωj=HSKij‖DIDj‖IDi‖γij. Then, it further computes HDIDj‖IDi‖Ri‖Rj‖Si‖Ttc2‖ωj and verifies the equality check against ωtc. If this holds true, Ui validates the authenticity for Drj. Hence, in the proposed scheme, both entities Ui and Drj mutually authenticate each other with the help of a trusted intermediary, i.e., TC.


## 6.2.2. User Anonymity

In the proposed scheme,Ui remains anonymous while submitting the authentication request to TC. Ui submits the message M1=Ci,Ri,ρi,Ti to TC without disclosing the identity as plaintext. Since Ui encrypts its identity IDi as Ci=ESixIDi;DIDj,Ti using Six, Ci can only be decrypted by a legitimate TC. Moreover, the scheme supports untraceability since the authentication messages in our scheme do not bear any message parameter that remains constant among various sessions that could help the adversary in identifying the location of the user. Hence, our scheme ensures anonymity as well as untraceability for the user.


## 6.2.3.Ui Impersonation

The proposed scheme is immune toUi impersonation attack. In case an adversary attempts to construct a fake authentication request message M1=Ci,Ri,ρi,Ti with a fresh timestamp Ti, it would not be able to do this until it has access to secret key Pri which can only be computed by valid TC and can never be guessed or accessed by the adversary under ordinary circumstances. Hence, our scheme can resist Ui impersonation attack.


## 6.2.4. Man-in-the-Middle Attack

In the proposed scheme, no malicious entity can engage in the ongoing communication session of the legal participants. This is because of the fact that both participants such asUi and Drj are deployed with secret keys, i.e., Pri, Prj, respectively, during the initialization phase by the trusted TC. Thus, all participants having possession to those secrets may engage in mutual authentication process and construct the mutually agreed session key SKij=HriRj‖Ri‖Rj‖βij‖γij on legal basis. Hence, the proposed scheme is very much immune to man-in-the-middle attack.


## 6.2.5. Session Key Security

The contributed protocol supports session key security because it supports mutual authentication and can resist man-in-the-middle as well as impersonation attacks, and the resistance against man-in-the-middle and impersonation attacks provide sufficient grounds to maintain this fact that our scheme ensures session key security in the face of crafty and malicious adversaries.


## 6.2.6. Denial of Service Attack

In DoS attack, an adversary may exploit vulnerability in the scheme if it is designed in such a way that the adversary may fabricate multiple authentication requests, while the server gets engaged to entertain each fake request and maintains that session for an indefinite time. In this manner, the attacker could initiate multiple fake requests towards the server and affect its capacity to serve the legal authentication request, which undermines its serving capacity. In our scheme,TC aborts the session immediately if either the timestamp Ti is not found to be fresh or the equality ρi?=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti does not hold true. In both cases, TC drops the session immediately which helps the protocol to avoid denial of service attack on the TC’s end.


## 6.2.7. Replay Attack

Our scheme employs the feature of timestamp that allows the protocol participants to verify the freshness of the received message. To construct the authentication requestM1=Ci,Ri,ρi,Ti, the Ui engenders the latest timestamp Ti and embeds the same in the parameter ρi=HDIDj‖IDi‖Ri‖Si‖Pri‖Ti for submission to TC. TC verifies the freshness of timestamp Ti and verifies the calculated HDIDj‖IDi‖Ri‖Si‖Pri‖Ti against ρi. If true, it confirms the validity of Ui. Likewise, Drj after receiving the message confirms the freshness of Ttc timestamp and proceeds further to compute the response message. Upon successful verification, Drj submits the parameter γij towards Ui via TC. Then, Ui verifies the authenticity of Drj by computing βij and verifying the corresponding timestamp Ttc2. In this manner, the replay attack can be successfully thwarted for the proposed scheme.


## 6.2.8. Physical Capturing Attack

In our scheme, the control centerTC stores DIDj,Prj in the memory of a UAV (say Drj), where Prj=HDIDj‖Prtc‖kj. In addition, the TC stores DIDj,kj in its verifier memory. DIDj is a randomly selected identity of the Drj, and it is different for each of the drone. Likewise, kj is also uniquely selected for each of the drones. Henceforth, DIDj,Prj are computed uniquely for each of the UAV. In case a UAV Drj is physically captured by a malicious entity, it cannot extend any advantage to the malicious entity to successfully forge any response message M3¯=Rj¯,Ψj¯,ωj¯,Tj¯ on behalf of another UAV say Drj¯, due to the uniqueness of parameters stored in each of Drj and Drj¯. In this manner, physical capturing is thwarted for the proposed scheme.


## 6.2.9. Perfect Forward Secrecy

In our scheme, the computation of the session keySKij=HrjRi‖Ri‖Rj‖βij‖γij requires both session specific secrets ri,rj as well as long-term secrets of both the entities βij,γij, where βij=HPri‖Si‖Ti and γij=HPrj‖βij‖Tj. It is clear that βij requires private key Pri of the user and γij requires private key Prj of the UAV. Every session consists of unique short-term ri,rj and long-term βij,γij parameters. The leakage of any of the session key or any of the long/short-term parameters may not extend any advantage to the attacker to gain abilities for compromising any future session.


## 7. Security and Performance Comparisons

In this section, the comparisons of the proposed scheme and related schemes presented in [19, 23, 24, 28–30] are conducted.


### 7.1. Security Features

Security feature comparisons of the proposed and relevant schemes proposed in [19, 23, 24, 28–30] are depicted in Table 3. All the relevant and compared schemes [19, 23, 24, 28–30] lack one or more security features: as proved in Section 4, the scheme of Nikooghadam et al. [28] has weaknesses against several attacks including stolen verifier, lack of untraceability, user and UAV impersonation based on secret parameter exposure of the UAVs, privileged insider and related attacks. The scheme of Wazid et al. has weaknesses against anonymity and untraceability, privileged insider and stolen verifier attacks, the scheme of Ever [30] lacks forward secrecy and prone to known session key and is privileged insider attacks. Similarly, the scheme of Zhang et al. [24] lacks mutual authentication, anonymity and untraceability, and forward secrecy, and the scheme of Turjman et al. [29] is also insecure against stolen verifier attack. The scheme of Srinivas et al. [19] lacks anonymity and untraceability and is also vulnerable to stolen verifier attacks. Only the proposed scheme provides all security features and resists known attacks.Table 3
Security features.
SchemesOurs[28][23][30][24][29][19]PMA✓✓✓✓✕✓✓PAU✓✕✕✓✕✓✕RSV✓✕✕✓✓✕✕RUI✓✓✓✓✓✓✓RRA✓✓✓✓✓✓✓RPC✓✓✓✓✓✓✓PSK✓✓✓✓✓✓✓PFS✓✓✓✕✕✓✓RKS✓✓✓✕✓✓✓RIA✓✕✕✕✓✓✓RMM✓✕✓✓✓✓✓Note. PMA: provides mutual authentication; PAU: provides anonymity and untraceability; RSV: resists stolen verifier; RUI: resists impersonation of the user, TC, and UAV; RRA: resists replay attack; RPC: resists physical capture; PSK: provides session key; PFS: provides forward secrecy; RKS: known session key attack; RIA: resists insider attack; RMM: resists man-in-the-middle attack; ✓: provision of the security feature; ✕: non-provision of the security feature.


### 7.2. Computation Cost

This subsection provides the comparison of the proposed scheme with related schemes [19, 23, 24, 28–30] as per real-time experiment conducted over MIRACL library, where we used Xiaomi-Redmi Note-8 smart phone with RAM size of 4 GB and 2.01 GHz Octa core Max processor. The underlying operating system in smart phone is Android V-9 and MIUI V-11.0.7. For replicating the trusted control center TC in the experiment, HP-EliteBook 8460-P with 2.7 GHz Intel® Core-TM and 4 GB RAM along with Ubuntu LTS 16 OS was used. Likewise, to replicate a UAV, Pi3B + Cortex (A53-ARMv8) with 64 bit-SoC, 1.4 GHz processor, and 1 GB LPDDR2-SDRAM was used in the experiment. The running times and notations used for each cryptographic operation for each of the user/mobile, TC, and UAV are depicted in Table 4.Table 4
Operation running time.
OperationsNotationsUser/mobileUAVServerPairing-bilinearTpb17.3612.524.038Point multiplication over ECCTme5.1164.1070.926Point addition over ECCTae0.0130.0180.006Secure hashThs0.0090.0060.004Symmetric operationsTed0.0170.0130.008The authentication process in the proposed scheme is furnished betweenUi, TC, and Drj, where, Ui executes 6Ths+6Ted+3Tme operations. The TC executes 9Ths+7Ted+1Tme operations; in addition, Drj executes 5Ths+3Ted+2Tme operations. Therefore, in proposed scheme, the running time to complete authentication among Ui, TC, and Drj is ≈25.877ms. The running time to complete authentication in Nikooghadam et al.’s scheme [28] is ≈18.544ms. As per the experimental results given in Table 5, the running times of the schemes presented in [19, 23, 24, 29, 30] are ≈5.334ms, ≈84.366ms, ≈0.16ms, ≈49.392ms, and ≈49.392ms, respectively.Table 5
Comparison of computation and communication costs.
ProtocolUiTCDrjRTBESrinivas et al. [19]14Ths+1Tf9Ths30Ths+1Tf≈10.574ms192Turjman et al. [29]10Ths+1Tpb14Ths+1Tpb+3Tme5Ths+2Tpb≈49.392ms300Zhang et al. [24]10Ths7Ths7Ths≈0.16ms184Kirsal [30]5Ths+2Tpb3Ths+2Tpb9Ths+2Tpb+4Tme≈84.366ms240Wazid et al. [23]16Ths+1Tf8Ths7Ths≈5.334ms212Nikooghadam et al. [28]8Ths+2Tme2Ths3Ths+2Tme≈18.544ms356Proposed6Ths+3Ted+3Tme9Ths+7Ted+1Tme5Ths+3Ted+2Tme≈25.877ms408Note. RT: running time in milliseconds; BE: bytes exchange.


### 7.3. Communication Cost

The communication cost comparison of the proposed and related schemes [19, 23, 24, 28–30] is shown in this subsection. In proposed scheme, we utilized SHA−1 with 160 bit size. We used AES as the symmetric cryptographic algorithm with 128 bit cipher size and 192 bit key. The output sizes of asymmetric cryptographic techniques are taken as per NIST recommended sizes which are 1024 bits and 320 bits each for RSA and ECC. The size of random numbers are also taken as 160 for simplicity and the size of a timestamp is fixed at 32 bits. Moreover, all the identities are taken as 128 bits long. Ui sends M1=Ci,Ri,ρi,Ti to TC, where, Ci=ESixIDi,DIDj,Ti, the size of each of the identity is 128 bits, and size of Ti=32bits, so total size of Ci=128+128+32=288, which requires three symmetric encryption operation each of size 128bits. Therefore, to encrypt Ci, we require 48 bytes. The total size of M1 is 384+320+160+32=896 bits. Similarly, M2=Ctc,Ri,δtc,Ttc requires to send 512+320+160+32=1024-bits from TC to Drj. Drj sends M3=Rj,Ψj,ωj,Tj, which requires transmission of 320+160+160+32=672-bits. Finally, TC sends M4=Rj,ωtc,γtc,Ttc2 to Ui, which also requires transmission of 320+160+160+32=672 bits. Therefore, total communication cost of the proposed scheme is 896+1024+672+672=3264 bits, which is 408 bytes. The communication cost of the Nikooghadam et al.’s scheme [28] is 356 bytes. The communication cost of the schemes presented in [19, 23, 24, 29, 30] is 212, 240, 184, 300, and 192 bytes, respectively.


## 7.1. Security Features

Security feature comparisons of the proposed and relevant schemes proposed in [19, 23, 24, 28–30] are depicted in Table 3. All the relevant and compared schemes [19, 23, 24, 28–30] lack one or more security features: as proved in Section 4, the scheme of Nikooghadam et al. [28] has weaknesses against several attacks including stolen verifier, lack of untraceability, user and UAV impersonation based on secret parameter exposure of the UAVs, privileged insider and related attacks. The scheme of Wazid et al. has weaknesses against anonymity and untraceability, privileged insider and stolen verifier attacks, the scheme of Ever [30] lacks forward secrecy and prone to known session key and is privileged insider attacks. Similarly, the scheme of Zhang et al. [24] lacks mutual authentication, anonymity and untraceability, and forward secrecy, and the scheme of Turjman et al. [29] is also insecure against stolen verifier attack. The scheme of Srinivas et al. [19] lacks anonymity and untraceability and is also vulnerable to stolen verifier attacks. Only the proposed scheme provides all security features and resists known attacks.Table 3
Security features.
SchemesOurs[28][23][30][24][29][19]PMA✓✓✓✓✕✓✓PAU✓✕✕✓✕✓✕RSV✓✕✕✓✓✕✕RUI✓✓✓✓✓✓✓RRA✓✓✓✓✓✓✓RPC✓✓✓✓✓✓✓PSK✓✓✓✓✓✓✓PFS✓✓✓✕✕✓✓RKS✓✓✓✕✓✓✓RIA✓✕✕✕✓✓✓RMM✓✕✓✓✓✓✓Note. PMA: provides mutual authentication; PAU: provides anonymity and untraceability; RSV: resists stolen verifier; RUI: resists impersonation of the user, TC, and UAV; RRA: resists replay attack; RPC: resists physical capture; PSK: provides session key; PFS: provides forward secrecy; RKS: known session key attack; RIA: resists insider attack; RMM: resists man-in-the-middle attack; ✓: provision of the security feature; ✕: non-provision of the security feature.


## 7.2. Computation Cost

This subsection provides the comparison of the proposed scheme with related schemes [19, 23, 24, 28–30] as per real-time experiment conducted over MIRACL library, where we used Xiaomi-Redmi Note-8 smart phone with RAM size of 4 GB and 2.01 GHz Octa core Max processor. The underlying operating system in smart phone is Android V-9 and MIUI V-11.0.7. For replicating the trusted control center TC in the experiment, HP-EliteBook 8460-P with 2.7 GHz Intel® Core-TM and 4 GB RAM along with Ubuntu LTS 16 OS was used. Likewise, to replicate a UAV, Pi3B + Cortex (A53-ARMv8) with 64 bit-SoC, 1.4 GHz processor, and 1 GB LPDDR2-SDRAM was used in the experiment. The running times and notations used for each cryptographic operation for each of the user/mobile, TC, and UAV are depicted in Table 4.Table 4
Operation running time.
OperationsNotationsUser/mobileUAVServerPairing-bilinearTpb17.3612.524.038Point multiplication over ECCTme5.1164.1070.926Point addition over ECCTae0.0130.0180.006Secure hashThs0.0090.0060.004Symmetric operationsTed0.0170.0130.008The authentication process in the proposed scheme is furnished betweenUi, TC, and Drj, where, Ui executes 6Ths+6Ted+3Tme operations. The TC executes 9Ths+7Ted+1Tme operations; in addition, Drj executes 5Ths+3Ted+2Tme operations. Therefore, in proposed scheme, the running time to complete authentication among Ui, TC, and Drj is ≈25.877ms. The running time to complete authentication in Nikooghadam et al.’s scheme [28] is ≈18.544ms. As per the experimental results given in Table 5, the running times of the schemes presented in [19, 23, 24, 29, 30] are ≈5.334ms, ≈84.366ms, ≈0.16ms, ≈49.392ms, and ≈49.392ms, respectively.Table 5
Comparison of computation and communication costs.
ProtocolUiTCDrjRTBESrinivas et al. [19]14Ths+1Tf9Ths30Ths+1Tf≈10.574ms192Turjman et al. [29]10Ths+1Tpb14Ths+1Tpb+3Tme5Ths+2Tpb≈49.392ms300Zhang et al. [24]10Ths7Ths7Ths≈0.16ms184Kirsal [30]5Ths+2Tpb3Ths+2Tpb9Ths+2Tpb+4Tme≈84.366ms240Wazid et al. [23]16Ths+1Tf8Ths7Ths≈5.334ms212Nikooghadam et al. [28]8Ths+2Tme2Ths3Ths+2Tme≈18.544ms356Proposed6Ths+3Ted+3Tme9Ths+7Ted+1Tme5Ths+3Ted+2Tme≈25.877ms408Note. RT: running time in milliseconds; BE: bytes exchange.


## 7.3. Communication Cost

The communication cost comparison of the proposed and related schemes [19, 23, 24, 28–30] is shown in this subsection. In proposed scheme, we utilized SHA−1 with 160 bit size. We used AES as the symmetric cryptographic algorithm with 128 bit cipher size and 192 bit key. The output sizes of asymmetric cryptographic techniques are taken as per NIST recommended sizes which are 1024 bits and 320 bits each for RSA and ECC. The size of random numbers are also taken as 160 for simplicity and the size of a timestamp is fixed at 32 bits. Moreover, all the identities are taken as 128 bits long. Ui sends M1=Ci,Ri,ρi,Ti to TC, where, Ci=ESixIDi,DIDj,Ti, the size of each of the identity is 128 bits, and size of Ti=32bits, so total size of Ci=128+128+32=288, which requires three symmetric encryption operation each of size 128bits. Therefore, to encrypt Ci, we require 48 bytes. The total size of M1 is 384+320+160+32=896 bits. Similarly, M2=Ctc,Ri,δtc,Ttc requires to send 512+320+160+32=1024-bits from TC to Drj. Drj sends M3=Rj,Ψj,ωj,Tj, which requires transmission of 320+160+160+32=672-bits. Finally, TC sends M4=Rj,ωtc,γtc,Ttc2 to Ui, which also requires transmission of 320+160+160+32=672 bits. Therefore, total communication cost of the proposed scheme is 896+1024+672+672=3264 bits, which is 408 bytes. The communication cost of the Nikooghadam et al.’s scheme [28] is 356 bytes. The communication cost of the schemes presented in [19, 23, 24, 29, 30] is 212, 240, 184, 300, and 192 bytes, respectively.


## 8. Conclusion

We initiated this article by highlighting the importance of secure communication among entities of a UAV network for crowd management. We revisited and proved that Nikooghadam et al.’s scheme has vulnerabilities against stolen verifier attacks and lacks user anonymity and untraceability. It is also proved that Nikooghadam et al.’s scheme is not practical due to the exposure of secret parameters of the UAVs and the users, which can ultimately lead to the total failure scenario. Therefore, a security-enhanced authentication scheme is proposed in this article using only the lightweight symmetric key primitives and ECC. We implemented the proposed scheme in a real-time environment to extract the running time of each of the entities involved in the authentication process. The BAN logic-based security analysis and a discussion on the security features affirm that the proposed scheme can resist known attacks while raising some computation. In future, we intend to implement the proposed protocol in real world for securing crowdsourcing systems.



---

*Source: 3437373-2021-11-05.xml*