A Symmetric Key and Elliptic Curve Cryptography-Based Protocol for Message Encryption in Unmanned Aerial Vehicles

Abstract

Unmanned aerial vehicles have found applications in fields such as environmental monitoring and the military. Although the collected data in some of these application domains are sensitive, public channels are deployed during the communication process. Therefore, many protocols have been presented to preserve the confidentiality and integrity of the exchanged messages. However, numerous security and performance challenges have been noted in the majority of these protocols. In this paper, an elliptic curve cryptography (ECC) and symmetric key-based protocol is presented. The choice of ECC was informed by its relatively shorter key sizes compared to other asymmetric encryption algorithms such as the Rivest–Shamir–Adleman (RSA) algorithm. Security analysis showed that this protocol provides mutual authentication, session key agreement, untraceability, anonymity, forward key secrecy, backward key secrecy, and biometric privacy. In addition, it is robust against smart card loss, password guessing, known secret session temporary information (KSSTI), privileged insider, side-channeling, impersonation, denial-of-service (DoS), and man-in-the-middle (MitM) attacks. The comparative performance evaluation showed that it has relatively low computation, storage, and communication complexities.

1. Introduction

Unmanned aerial vehicles (UAVs), popularly known as drones, are smart machines with Internet of Things (IoT) connections that fly over certain regions to provide numerous real-time services [1]. For instance, they have been extensively deployed in areas such as intelligent transportation systems (ITSs), the detection and collection of environmental data, emergency rescue, autonomous driving, the creation of high-definition maps in real-time, and military applications [2,3]. In UAV-enabled ITSs, car sharing, real-time map creation, and autonomous driving can be facilitated [4]. In the military, surveillance, reconnaissance, intelligence collection, ground strikes, and fire guidance are enabled. As explained in [5,6], UAVs can also be applied in civil aviation, industrial setups, and areas that are dangerous or difficult for humans to reach, such as during earthquake searches and gas leak detection. In some cases, these drones can serve as relay nodes in mobile and wireless sensor network (WSN) communications. The authors of [7] pointed out that UAVs can be considered as extensions of Internet of Vehicle (IoV) communication that can offer aerial interfaces for vehicles. All these applications stem from the various salient UAV features, such as low cost and flexible operation [8].

In some of the above UAV application domains, sensitive data are collected and exchanged with cellular networks as well as other ubiquitous devices [9]. Unfortunately, message exchange across UAV networks is accomplished over public channels [10,11,12]. This renders these networks susceptible to attacks such as impersonation, session key disclosure, message replays, man-in-the-middle (MitM) attacks, tracking, and eavesdropping [4,13,14,15,16,17]. The deployment of drones in dangerous, remote, and unmonitored regions exposes them to physical capture attacks [3,18]. Upon capture attacks, the security parameters stored in the UAV memory can be retrieved, and hence confidential information can be leaked. This leads to privacy and security violations [19]. It is also possible for these data to be compromised and the drone to be deployed as a weapon by the attacker [20]. In addition, message replays can cause inaccurate information to be transmitted to UAVs, which can cause their collision. Moreover, data breaches and theft are on the rise in UAV and Internet of Drones (IoD) networks [21]. Most of the UAV-assisted IoV protocols depend on local edge infrastructure and are unable to independently execute secure data transmissions [22,23,24,25]. Therefore, strong data encryption and mutual authentication should be implemented. However, UAVs are resource-limited in terms of energy, storage, communication, and computing capabilities [9]. As such, they are not able to the handle extensive cryptographic operations required in most of conventional encryption schemes [3].

1.1. Problem Statement and Motivation

UAVs have been deployed in highly sensitive domains such as military surveillance. As such, strong security protection should be accorded to the exchanged messages. Therefore, numerous cryptographic key encryption schemes have been deployed for confidentiality preservation in UAVs. However, the conventional key distribution techniques used in these schemes present some difficulties in dynamic environments where UAVs randomly join and leave the network [26]. Worse still, many UAVs do not have inbuilt authentication mechanisms [27]. There is therefore a need for innovative approaches to securing the UAV communication environment. This may include access control, key management, intrusion detection, user authentication, intrusion prevention, and location and identity privacy [28].

1.2. Contributions

The main contributions of this paper include the following:

• An authentication protocol that leverages symmetric key and elliptic curve cryptography was developed to protect UAV message exchanges.
• A masking technique was deployed to preserve both operator biometric privacy and anonymity.
• Extensive security analysis was carried out to show that our protocol upholds mutual authentication, session key agreement, untraceability, anonymity, forward key secrecy, backward key secrecy, and biometric privacy. In addition, this protocol was demonstrated to be resilient against smart card loss, password guessing, KSSTI, privileged insider, side-channeling, impersonation, DoS, and MitM attacks.
• A performance evaluation was executed to show that the proposed protocol attained a 87.5% improvement in privacy and security provision at relatively low computation, storage, and communication complexities.

The rest of this paper is structured as follows: Section 2 discusses the related work, while Section 3 presents the proposed protocol. Section 4 details the security evaluation of our protocol. This is followed by the performance evaluation in Section 5. Finally, Section 6 concludes the paper and presents future research directions.

2. Related Work

UAV security and privacy has attracted a lot of attention from industry and academia, and hence many schemes have been developed in the recent past. For instance, blockchain-based authentication schemes were presented in [4,29], while a blockchain-based risk management system for drones was introduced in [30]. However, the deployment of blockchain technology incurs high storage, communication, and computation overheads during consensus building [31]. To address this challenge, lightweight authentication schemes were introduced in [3,32,33,34,35]. However, the protocol in [33] failed to offer session key agreement and was not robust against de-synchronization attacks. Although the Physically Unclonable Functions (PUFs) used in [3,32] prevent physical capture attacks, PUFs have stability issues [36], while the scheme in [34] was susceptible to drone capture attack [9]. The protocol in [35] was vulnerable to side-channel attacks, which could be employed to retrieve the credentials stored in memory [9]. This problem could be alleviated by the elliptic curve cryptography (ECC) and symmetric key-based protocol developed in [37]. However, this approach incurred high communication and processing overheads [9].

To enhance privacy, authentication schemes were introduced in [38,39,40,41]. Unfortunately, the authentication of all drones was centralized in [38], which could present a single point of failure. The scheme in [39] was vulnerable to privileged insider attacks, while the protocol in [40] had high computation costs. Similarly, the certificate-based technique in [41] lacked mutual authentication, and hence the integrity of the communication process was not upheld [42]. Based on symmetric key functions, an authentication scheme was introduced in [43]. However, the usage of the management server’s static identity during authentication implied that anonymity was not preserved. In addition, the deployed timestamps were publicly shared, and this could lead to de-synchronization attacks. Although the ECC and blockchain-based protocol in [44] could solve this challenge, the blockchain technology and multiplication operations utilized here resulted in extensive computation costs [45]. Similarly, the robust authentication scheme presented in [46] had high computation costs associated with ECC multiplication operations. In addition, this protocol failed to preserve reliability and anonymity [9].

To provide authentication between UAVs and the vehicles in a UAV-enabled ITS environment, an ECC-based protocol was developed in [47]. Similarly, an ECC-based scheme was introduced in [48]. However, the deployed public key cryptosystem in [47] resulted in high computation overheads [49]. In addition, this scheme failed to authenticate the drone to the roadside unit (RSU). The protocol developed in [48] did not solve privacy leakages [9]. The scheme in [50] was lightweight and could address the performance challenges in [47]. Similarly, the protocol in [51] was anonymous and hence could solve the privacy leak issues in [48]. However, the technique in [50] was not scalable, could only be used within one flying zone, and could not preserve untraceability [3]. In addition, it was susceptible to stolen verifier attacks, which could further facilitate user or drone spoofing [9]. The protocol developed in [52] could potentially solve this problem. However, this scheme did not support re-authentication and was vulnerable to node capture and tampering attacks. In addition, it incurred heavy computation costs [9]. Similarly, the protocol presented in [53] had high computation costs owing to its extensive ECC multiplication operations.

To offer dynamic membership authentication, a trusted authority (TA)-based protocol was introduced in [54]. However, the usage of public-key cryptosystem during mutual authentications resulted in high computation overheads [55]. Similarly, the protocol presented in [56] incurred huge communication and computation costs. In addition, it could not provide traceability or confidentiality and was vulnerable to ephemeral secret leakage attacks [29]. The quadratic residue-based technique presented in [57] could address this issue, although it failed to provide session key agreement and resilience against privileged insider attacks.

It is evident that most of the current techniques for UAVs still have some performance, security, and privacy issues that need to be solved. In addition, the majority of the current techniques deal with user and UAV authentication, ignoring the security issues in mobile sink nodes [58]. The proposed scheme is shown to address some of these security and privacy issues at relatively low complexities.

3. The Proposed Protocol

The network model in our protocol includes a registration authority (RA), UAVs, and their operators, as shown in Figure 1. During the registration process, secure communication channels are deployed. However, public wireless channels are utilized during the subsequent authentication, key agreement, and data exchanges.

In terms of execution phases, the proposed protocol consists of five major phases. These include system initialization, registration, mutual authentication, the session parameter update phase, and the revocation phase.

Table 1. Symbols.

Symbol	Description
EX (Z)	Cipher text of message Z with key X
${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$	Session key shared between RA and operator
CAG	Cyclic additive group of the order r
ℙ	The generator of CAG
SKRA	RA secret key
PKRA	RA private key
PUKRA	RA public key
h(.)	Hashing operation
IDRA	RA unique identity
IDUAV	UAV identity
${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{U}\mathrm{A}\mathrm{V}}}$	Session key shared between RA and the UAV
Ri	Random numbers
IDOP	UAV operator unique identity
PIDOP	UAV operator pseudonym
IDSC	Smart card unique serial number
${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{O}\mathrm{P}}}$	Session key shared between the operator and the UAV
PWOP	UAV operator password
β	Operator biometrics
βk	Biometrics key
VF	Fuzzy verifier
||	Concatenation operation
⊕	XOR operation

presents the symbols used throughout this paper.

3.1. System Initialization Phase

During this phase, the registration authority generates and distributes the security tokens that are deployed in the later stages, including mutual authentication and key agreement. This process is depicted in Figure 2 below.

• Step 1: To commence this process, the RA generates its unique identity ID_RA; channel parameter C_P; and cyclic additive group C_AG, whose order is r. This is followed by the selection of SK_RA as the secret key, h(.) as the one-way hashing function, ℙ as the generator of C_AG, and PK_RA as the private key.
• Step 2: Next, the RA computes PUK_RA = ℙ.PK_RA, followed by the publication of parameter {ℙ, PK_RA, h(.)}. Here, ℙ, SK_RA, PK_RA$\subseteq Z_r^{*},$ h: [0, 1]* → [0, 1]ⁿ; C_P is an integer gauging the fuzzy verifier’s robustness against online guessing attacks; and n is h(.)’s output length.

3.2. Registration Phase

Before the UAVs and operators can start the communication process, they have to be registered at the RA. In this phase, the registration authority generates and forwards a secret key for each UAV. On the other hand, the RA stores the operator secret keys in the smart card (SC) before issuing this card to the UAV operator.

• Step 1: During UAV registration, the UAV chooses its identity ID_UAV, which is then sent to the RA through certain secure channels, as shown in Figure 2.
• Step 2: Upon receiving identity ID_UAV, the RA generates random number R₁, which it utilizes to derive A₁ = h(ID_UAV||SK_RA||R₁). It then stores parameter set {ID_UAV, R₁} in its database. Finally, it securely transmits {A₁} to the UAV, which in turn stores it securely in its memory.
• Step 3: During UAV operator registration, each operator generates a unique identity ID_OP and sends it to the RA through certain secure channels.
• Step 4: On receiving ID_OP from the operator, the RA generates random number R₂ before deriving A₂ = h(ID_OP||SK_RA||R₂) and A₃ = h(ID_SC||SK_RA). Next, it stores parameter set {ID_OP, ID_SC, R₂, PID_OP} in its database. Finally, the RA inserts parameters {A₂, A₃, ℙ, PUK_RA, C_P, h(.),Gen(.), Fe(.)} into the smart card before securely delivering this card to the operator.
• Step 5: Upon receiving the smart card, the operator inputs parameter set {ID_OP, PW_OP, β} to the smart card reader, at which point the biometric key and template algorithms are invoked, deriving (β_k, β_T) = Gen(β), A₄ = A₂$\oplus$h(ID_OP||PW_OP||β_k), A₅ = A₃$\oplus$h(ID_OP$\oplus$PW_OP$\oplus$β_k) and fuzzy verifier V_F = h(h(ID_OP||PW_OP||β_k) mod C_P). Lastly, the user stores {A₄, A₅, V_F, β_T,ℙ, PUK_RA, C_P, h(.),Gen(.), Fe(.)} in the smart card.

3.3. Mutual Authentication and Key Negotiation Phase

During this phase, the operator identity is validated so as to establish several secure channels between the RA, UAV, and operator. This is a seven-step process, as described below and depicted in Figure 3.

• Step 1: To access the UAV network, the operator inserts the smart card into the reader, at which point the security parameters {ID_OP*, PW_OP*, β*} are input. Thereafter, the SC derives β_k* = Gen (β_T, β*), V_F* = h(h(ID_OP*||PW_OP*||β_k*) mod C_P). It then checks if V_F* ≟ V_F such that the session is terminated when these two values are not equivalent. Otherwise, it computes parameters A₂ = A₂$\oplus$h(ID_OP*||PW_OP*||β_k*) and A₃ = A₅$\oplus$h(ID_OP*$\oplus$PW_OP*$\oplus$β_k*).
• Step 2: Next, it generates random number R₃$\subseteq Z_r^{*}$ and secret key ${\mathrm{S}}_{{\mathrm{K}}_1}$ before computing security parameters B₁ = (R₃.ℙ), B₂ = h(B₁||ID_OP||ID_RA), B₃ = (A₂ℙ + B₁B₂), B₄ = ${\mathrm{E}}_{{\mathrm{P}\mathrm{U}\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$(A₂ + R₃B₂), B₅ = h(ID_OP||A₂||A₃||${\mathrm{S}}_{{\mathrm{K}}_1}$), C₁ = h(B₄||B₃||ID_RA), and C₂ = ${\mathrm{E}}_{{\mathrm{C}}_1}$(ID_OP||B₁||B₅||ID_UAV). Finally, the operator composes message M₁ = {B₃, C₂, ${\mathrm{S}}_{{\mathrm{K}}_1}$}, which it transmits to the RA over public channels.
• Step 3: Upon receiving message M₁ from the operator, the RA derives B₄ = PK_RAB₃ and C₁ = h(B₄||B₃||ID_RA). It then deploys the just computed C₁ to decipher C₂ and obtain parameter set {ID_OP, B₁, B₅, and ID_UAV}. Next, it retrieves the ID_SC and R₂ corresponding to the obtained ID_OP. Thereafter, it derives A₂ = h(ID_OP||SK_RA||R₂), A₃ = h(ID_SC||SK_RA), B₂ = h(B₁||ID_OP||ID_RA), B₅* = h(ID_OP||A₂||A₃||${\mathrm{S}}_{{\mathrm{K}}_1}$), and B₃* = (A₂.ℙ + B₁.B₂). It then checks if B₅* ≟ B₅ and B₃* ≟ B₃ such that it rejects the authentication request and terminates the session. Otherwise, it accepts the operator as a legitimate entity.
• Step 4: The RA generates random number R₄ $\subseteq Z_r^{*}$ and secret key ${\mathrm{S}}_{{\mathrm{K}}_2}$, followed by the computation of security parameters C₃ = (R₄.ℙ) and C₄ = (R₄.B₁) and session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$ = h(ID_OP||ID_RA||B₁||C₃||C₁||A₂||C₄), which its shares with the operator. Next, the RA retrieves the R₁ corresponding to this particular ID_UAV followed by the derivation of secret tokens A₁ = h(ID_UAV||SK_RA||R₁) and C₅ = h(ID_OP||ID_UAV||ID_RA||C₄||${\mathrm{S}}_{{\mathrm{K}}_2}$). Next, the RA computes D₁ = ${\mathrm{E}}_{{\mathrm{A}}_1}$(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{S}}_{{\mathrm{K}}_2}$) and D₂ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{S}}_{{\mathrm{K}}_2}$||A₁). Finally, it constructs message M₂ = {D₁, D₂}, which is then sent to the UAV over insecure channels.
• Step 5: After receiving message M₂ from the RA, the UAV decrypts security parameter D₁ using its secret key A₁. This is followed by the derivation of parameters D₂* = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{S}}_{{\mathrm{K}}_2}$||A₁). It then checks if D₂* ≟ D₂ such that the session is terminated when these two values are dissimilar. Otherwise, the UAV generates random number R₅$\subseteq Z_r^{*}$ before computing session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{U}\mathrm{A}\mathrm{V}}}$ = h(ID_UAV||ID_RA||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅||A₁), which it shares with the RA. Next, it derives session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{O}\mathrm{P}}}$ = h (ID_OP||ID_UAV|| ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{R}}_5$), which it shares with the operator. This is followed by the derivation of D₃ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_2}\left|\right|{\mathrm{R}}_5$||A₁) before constructing message M₃ = {R₅, D₃}, which is transmitted over to the RA.
• Step 6: Upon receiving message M₃, the RA derives D₃* = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_2}\left|\right|{\mathrm{R}}_5$||A₁), which it deploys to validate the UAV’s identity. As such, it checks if D₃* ≟ D₃ such that the session is terminated if the two parameters are not identical. Otherwise, it computes ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{U}\mathrm{A}\mathrm{V}}}$ = h(ID_UAV||ID_RA||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅||A₁), which is shared with the UAV. This is followed by the derivation of security parameter D₄ = h(ID_OP||ID_RA||C₃||C₁||A₂||C₄||${\mathrm{S}}_{{\mathrm{K}}_1}$||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅), which is utilized to validate its own identity on the UAV operator side. Finally, it constructs message M₄ = {C₃, D₄, ${\mathrm{S}}_{{\mathrm{K}}_2},{\mathrm{R}}_5$}, which it transmits over to the operator.
• Step 7: After receiving message M₄ from the RA, the operator computes C₄ = (R₃.C₃), D₄* = h(ID_OP||ID_RA||C₃||C₁||A₂||C₄||${\mathrm{S}}_{{\mathrm{K}}_1}$||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅) to validate the RA’s legitimacy. As such, it checks if D₄* ≟ D₄ and terminates the session when these two values are dissimilar. Otherwise, it derives security parameter C₅ = h(ID_OP||ID_UAV||ID_RA||C₄||${\mathrm{S}}_{{\mathrm{K}}_2}$); session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$ = h(ID_OP||ID_RA||B₁||C₃||C₁||A₂||C₄), which it shares with the RA; and session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{O}\mathrm{P}}}$ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{R}}_5)$.

3.4. Parameter Update Phase

The proposed protocol offers some mechanisms through which the UAV operator may update the deployed biometrics and password. This is crucial, especially if these security parameters are compromised by an adversary. This is a three-step process, as discussed below.

• Step 1: The operator inserts the smart card into the card reader and inputs security parameters {ID_OP*, PW_OP*, β*}. Afterwards, the SC computes β_k* = Fe(β_T, β*), V_F* = h(h(ID_OP*||PW_OP*||β_k*) mod C_P). Next, it checks whether V_F* ≟ V_F such that the session is terminated if the two values do not match. Otherwise, it derives A₂* = A₂$\oplus$h(ID_OP*||PW_OP*||β_k*) and A₃* = A₅$\oplus$h(ID_OP*$\oplus$PW_OP*$\oplus$β_k*).
• Step 2: The operator generates a new password PW_OP^New and inputs new biometrics β^New. Upon receiving updated parameters PW_OP^New and β^New, the smart card computes (β_k^New, β_T^New) = Gen(β^New), A₄^New = A₂$\oplus$h(ID_OP*||PW_OP^New||β_k^New), A₅^New = A₃$\oplus$h(ID_OP*$\oplus$ PW_OP^New$\oplus$β_k^New), and V_F^New = h(h(ID_OP*|| PW_OP^New||β_k^New) mod C_P).
• Step 3: The smart card substitutes security parameters {A₄, A₅, V_F, β_T} with their updated equivalents {A₄^New, A₅^New, V_F^New, β_T^New}.

3.5. Smart Card Revocation Phase

This phase is invoked whenever the UAV operator loses the smart card or the security tokens stored in it are compromised in any way.

• Step 1: The UAV operator generates new identity ID_OP** and pseudonym PID_OP**, which are then sent to the RA over secure channels.
• Step 2: Upon receiving these operator credentials, the RA validates their authenticity such that the revocation request is rejected if they are invalid. Otherwise, the RA generates random number R₂^New and derives parameters A₂ = h(ID_OP**||SK_RA||R₂^New) and A₃ = h(ID_SC^New||SK_RA). Next, the RA substitutes previous security parameter set {ID_OP, ID_SC, R₂, PID_OP} with updated parameter set {ID_OP**, ID_SC^New, R₂^New, PID_OP**}.
• Step 3: After the parameter updates in step 2 above, the operator executes the rest of the registration steps as detailed in the registration phase above.

4. Security Evaluation

In this section, a number of theorems are formulated and proved to demonstrate the resilience of the proposed protocol against attacks. A similar approach is followed to illustrate the many salient privacy and security features provided by our scheme.

Theorem 1.

The proposed protocol is robust against smart card loss and side-channeling attacks.

Proof. 

Suppose that an adversary wants to mount offline password guessing attacks against the proposed protocol. To achieve this, the security parameters {A₄, A₅, V_F, ℙ, PUK_RA, C_P, h(.),Gen(.), Fe(.)} stored in the smart card are extracted. Here, (β_k, β_T) = Gen(β) and V_F = h(h(ID_OP||PW_OP||β_k) mod C_P). As such, even if an adversary manages to compromise the smart card and operator biometrics, the operator identity ID_OP* and password PW_OP* still need to be correctly guessed. Obtaining these security parameters from the fuzzy verifier is difficult due to the one-way hashing operation. Consequently, any bogus identity ID_OP^bogus and password PW_OP^bogus will be detected when the operator checks if V_F* ≟ V_F, where V_F* = h(h(ID_OP^bogus||PW_OP^bogus ||β_k*) mod C_P). Suppose now that an attacker has captured message M₁ = {B₃, C₂, ${\mathrm{S}}_{{\mathrm{K}}_1}$} sent from the operator towards the RA. Here, A₄ = A₂$\oplus$h(ID_OP||PW_OP||β_k), A₅ = A₃$\oplus$h(ID_OP$\oplus$PW_OP$\oplus$β_k), B₃ = (A₂.ℙ + B₁.B₂), and C₂ = ${\mathrm{E}}_{{\mathrm{C}}_1}$(ID_OP||B₁||B₅||ID_UAV). Using parameters A₄ and A₅ extracted from the smart card, the attacker derives A₂* = A₄$\oplus$h(ID_OP*||PW_OP*||β_k*), A₃* = A₅$\oplus$h(ID_OP*$\oplus$PW_OP*$\oplus$β_k*), and B₅* = h(ID_OP*||A₂*||A₃*||${\mathrm{S}}_{{\mathrm{K}}_1}$). However, based on the elliptic curve computational Diffie–Hellman (ECCDH) difficulty, the attacker is unable to compute B₅ = h(ID_OP||A₂||A₃||${\mathrm{S}}_{{\mathrm{K}}_1}$) from C₂ = ${\mathrm{E}}_{{\mathrm{C}}_1}$(ID_OP||B₁||B₅||ID_UAV). As such, the adversary is unable to derive B₅, which is required to effectively authenticate ID_OP* and PW_OP*. □

Theorem 2.

Strong mutual authentication is executed in the proposed scheme.

Proof. 

To authenticate the operator, the RA verifies whether B₅* ≟ B₅ and B₃* ≟ B₃, where B₅ = h(ID_OP||A₂||A₃||${\mathrm{S}}_{{\mathrm{K}}_1}$) and B₃ = (A₂.ℙ + B₁.B₂). As such, an entity masquerading as the operator must derive a valid B₃ and B₅. However, an adversary is unable to derive these parameters without the operator identity ID_OP, password PW_OP, or parameters A₄ and A₅ stored in the smart card. On the other hand, the UAV authenticates the RA through the verification of whether D₂* ≟ D₂, where D₂ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{S}}_{{\mathrm{K}}_2}$||A₁). Since security parameter A₁ = h(ID_UAV||SK_RA||R₁) is only known to the UAV and RA, an attacker is unable to obtain authentication. Similarly, the RA authenticates the UAV by verifying whether D₃* ≟ D₃, where D₃ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_2}\left|\right|{\mathrm{R}}_5$||A₁), while the operator authenticates the RA by checking if D₄ = h(ID_OP||ID_RA||C₃||C₁||A₂||C₄||${\mathrm{S}}_{{\mathrm{K}}_1}$||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅). The derivation of a valid D₄ requires secrets SK_RA and A₂, among others. Similarly, secrets PK_RA and SK_RA, which are only known to the RA and the operator, are also required. □

Theorem 3.

The proposed protocol offers UAV operator untraceability.

Proof. 

Suppose that an adversary is interested in tracking a particular UAV operator. To achieve this, authentication messages exchanged in the channels must be intercepted. Thereafter, an attempt is made to associate the various communication sessions with the operator. During the authentication phase, messages M₁ = {B₃, C₂, ${\mathrm{S}}_{{\mathrm{K}}_1}$} and M₄ = {C₃, D₄,${\mathrm{S}}_{{\mathrm{K}}_2},{\mathrm{R}}_5$} both relate to the UAV operator. Here, B₃ = (A₂.ℙ + B₁.B₂), B₁ = (R₃.ℙ), C₂ = ${\mathrm{E}}_{{\mathrm{C}}_1}$(ID_OP||B₁||B₅||ID_UAV), C₃ = (R₄.ℙ), and D₄ = h(ID_OP||ID_RA||C₃||C₁||A₂||C₄||${\mathrm{S}}_{{\mathrm{K}}_1}$||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅). Evidently, random numbers R₃, R₄, and R₅ imply that these messages are stochastic and hence session-specific. As such, it is infeasible to associate any two or more sessions with a particular operator. □

Theorem 4.

Online password guessing attacks are curbed in the proposed protocol.

Proof. 

During the login phase, the UAV operator inputs password PW_OP*, identity ID_OP*, and biometrics β*. Afterwards, the fuzzy verifier is derived as V_F* = h(h(ID_OP*||PW_OP*||β_k*) mod C_P). The computed verifier is then validated against the fuzzy verifier V_F = h(h(ID_OP||PW_OP||β_k) mod C_P) stored in the smart card. As such, any adversarial password guesses are easily detected, and the session is immediately terminated. □

Theorem 5.

The proposed protocol facilitates the negotiation of session keys.

Proof. 

During the authentication process, the operator and RA establish a session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$ = h(ID_OP||ID_RA||B₁||C₃||C₁||A₂||C₄). Evidently, the derivation of this session key requires secrets C₁, C₄, and A₂, which are only known to the UAV operator and the RA. On the other hand, the session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{O}\mathrm{P}}}$ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{R}}_5$) is negotiated between the operator and the UAV. The derivation of this session key requires secret C₅, which is only known to the operator and the UAV. Similarly, session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{U}\mathrm{A}\mathrm{V}}}$ = h(ID_UAV||ID_RA||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅||A₁) is established between the UAV and the RA using secret A₁, which is only known to the UAV and the RA. □

Theorem 6.

UAV operator anonymity is upheld in the proposed protocol.

Proof. 

Suppose that an attacker is interested in deciphering the operator identity ID_OP. To attain this goal, all the messages exchanged between the operator and other entities are captured. For instance, in message M₁ = {B₃, C₂, ${\mathrm{S}}_{{\mathrm{K}}_1}$}, operator identity is masked and enciphered in C₂ = ${\mathrm{E}}_{{\mathrm{C}}_1}$(ID_OP||B₁||B₅||ID_UAV). As such, to obtain this identity ID_OP, an adversary must access secret key C₁ = h(B₄||B₃||ID_RA) to decrypt C₂. Another technique is to deploy the RA’s private key PK_RA to derive B₄ = PK_RAB₃. However, this is infeasible, since this private key is only known to the RA. Similarly, for the attacker to obtain identity ID_OP, secret values R₃ and A₂ must be obtained so as to derive B₄ = ${\mathrm{E}}_{{\mathrm{P}\mathrm{U}\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$(A₂ + R₃B₂). However, this presents a difficult ECCDH problem. In addition, security parameter A₂ is masked with password PW_OP and biometrics β in the smart card and hence is difficult to obtain. □

Theorem 7.

The proposed protocol offers easy recovery from smart card loss.

Proof. 

Suppose that the UAV operator’s smart card is stolen or lost, along with the credentials stored in it. However, the RA stores security parameters {ID_OP, ID_SC, R₂, PID_OP} in its database. As such, the operator only needs to invoke the smart card revocation phase of this protocol, at which point the value of ID_SC is updated without changing identity ID_OP. □

Theorem 8.

The security of the negotiated session key is upheld in this protocol.

Proof. 

During the generation of the session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$ = h(ID_OP||ID_RA||B₁||C₃||C₁||A₂||C₄) that is shared between the operator and the RA, session-specific parameters B₁ = (R₃.ℙ) and C₃ = (R₄.ℙ) are deployed. This is because these parameters are stochastically selected for each authentication session. As such, even if the session key is compromised by an adversary, secret values C₁ and A2 cannot be obtained due to the irreversibility of the one-way hashing operation. Consequently, an attacker is unable to derive the session key for the subsequent communication process. Similarly, an adversary is unable to derive C₅ in ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{O}\mathrm{P}}}$ = h(ID_OP||ID_UAV||ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{R}}_5$), and hence this session key also remains secure in other sessions even if the current key is under attack. □

Theorem 9.

UAV operator biometric privacy is preserved and impersonation prevented.

Proof. 

Once the operator imprints the biometric data β, the processing is carried out locally on the operator side such that the RA cannot access any information related to β. In addition, before storage in the smart card, a biometric encryption algorithm is executed to convert it into hash values as (β_k, β_T) = Gen(β), A₄ = A₂$\oplus$h(ID_OP||PW_OP||β_k), A₅ = A₃$\oplus$h(ID_OP$\oplus$PW_OP$\oplus$β_k), and fuzzy verifier V_F = h(h(ID_OP||PW_OP||β_k) mod C_P). As such, the operator biometrics appear as A₄, A₅, V_F, and β_T in the smart card. Consequently, even if the current biometric information in the smart card is leaked, an attacker is unable to derive β from the leaked information. Consequently, operator impersonation using β is thwarted. □

Theorem 10.

Privileged insider attack is prevented.

Proof. 

This attack normally happens when certain entities take advantage of their higher security clearance levels and attempt to compromise the communication process. During these compromises, security parameters such as unique identities and passwords may be recovered and misused. To curb this attack, the operator only transmits identity to the registration authority (RA) during the UAV operator registration phase. As such, the registration authority is never allowed to access any information that may facilitate the recovery of the operator password. □

Theorem 11.

The proposed protocol achieves forward key secrecy.

Proof. 

At any authentication and communication phase, the UAV operator maintains three long-term secret tokens, A₄, PW_OP, and β, where A₄ = A₂$\oplus$h(ID_OP||PW_OP||β_k). On the other hand, the registration authority (RA) maintains two long-term secret tokens, PK_RA and SK_RA. In addition, for the generation of the shared session keys ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$ = h(ID_OP||ID_RA||B₁||C₃||C₁||A₂||C₄), ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{U}\mathrm{A}\mathrm{V}}}$ = h(ID_UAV||ID_RA||${\mathrm{S}}_{{\mathrm{K}}_2}$||R₅||A₁), and ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{O}\mathrm{P}}}$ = h(ID_OP||ID_UAV|| ID_RA||C₅||${\mathrm{S}}_{{\mathrm{K}}_1}\left|\right|{\mathrm{R}}_5$), random parameters R₃, R₄, and R₅ have to be dynamically generated. Here, it is infeasible to compute C₄ = (R₄.B₁) with B₁ = (R₃.ℙ) due to the difficulty of solving the ECCDH problem. Consequently, the exposure of these long-term secrets cannot compromise the security of the negotiated session keys. □

Theorem 12.

Denial-of-service attacks are thwarted.

Proof. 

In the proposed protocol, the registration authority (RA) does not need to maintain a verifier table that will be searched for verification tokens during the authentication process. On the other hand, the RA only stores parameter set {ID_OP, ID_SC, R₂, PID_OP} in its database. Since none of these parameters are derived from the UAV operator passwords, there is no need for an exhaustive search for verification tokens in tables. Schemes using verifier tables are vulnerable to denial-of-service attacks when this table is compromised. □

Theorem 13.

Ephemeral leakage and MitM attacks are prevented.

Proof. 

The assumption made in this attack is that intermediary security parameter R₃ $\subseteq Z_r^{*}$ has been captured by an adversary. As such, the attacker may attempt to derive session key ${\mathrm{S}\mathrm{S}}_{{\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$ = h(ID_OP||ID_RA||B₁||C₃||C₁||A₂||C₄). However, the crucial parameter required for the derivation of this session key is C₁ = h(B₄||B₃||ID_RA), in which B₄ = ${\mathrm{E}}_{{\mathrm{P}\mathrm{U}\mathrm{K}}_{\mathrm{R}\mathrm{A}}}$(A₂ + R₃.B₂). Evidently, an attacker cannot compute B₄ without security parameter A₂, which is stored in the smart card and encapsulated in password PW_OP and UAV operator biometrics β. □

5. Performance Evaluation

Many authentication protocols have utilized various complexities to appraise their performance. The most common complexities include computation, communication, and storage. As such, this section presents the derivation as well as the comparative evaluation of the proposed protocol using these complexities. In addition, the supported security features and attack resilience are deployed towards the end of this section to appraise the proposed protocol.

5.1. Computation Complexity

During the mutual authentication and key negotiation phase, various cryptographic operations are executed at the RA, smart card reader, and UAV. Specifically, 10 elliptic curve multiplications, 2 elliptic curve additions, 4 symmetric encryptions/decryptions, and 25 one-way hashing operations are executed. Taking the duration of a single elliptic curve multiplication, elliptic curve addition, symmetric encryption/decryption, and one-way hashing operation as T_EM, T_EA, T_SED, and T_H, respectively, the total computation complexity of the proposed protocol is 25T_H + 10T_EM, 2T_EA + 4T_S.

Table 2. Implementation environment.

Feature	Description
Processor	Intel (R) core (TM) i5-4210U CPU
RAM	4 GB
Clock speed	2.4 GHz
Operating system	Ubuntu 22.04.2 LTS
Programming language	Python
Cryptographic library	PyCrypto
Symmetric encryption and decryption algorithm	Advanced Encryption Standard (AES)
Asymmetric encryption and decryption algorithm	Rivest–Shamir–Adleman (RSA)

presents the implementation environment for the proposed protocol.

Using the parameters in Table 2, above, the duration of each cryptographic operation is presented in

Table 3. Duration of cryptographic operations.

Cryptographic Operation	Time (ms)
One-way hashing (TH)	0.043
Modular squaring (TMS)	1.865
Square-root modular P (TSQ)	3.354
Symmetric encryption/decryption (TS)	0.485
Asymmetric encryption/decryption (TA)	8.736
Chebyshev polynomial computing (TCP)	5.284
Bilinear pairing operation (TBP)	12.263
Exponential operation (TE)	8.561
Map-to-point hash function operation (TMH)	6.782
Montgomery operation (TM)	0.285
Hashed message authentication code (THM)	0.193
Elliptic curve multiplication (TEM)	1.029
Elliptic curve addition (TEA)	0.016

below.

Based on the cryptographic durations in Table 3 above, the computation complexities for the proposed protocol as well as other related schemes were derived, as shown in

Table 4. Computation complexity comparisons.

Scheme	Operations	Time (ms)
Yang et al. [33]	12TH + 4TM + 2TSQ + 4TS + 10THM	12.234
Tan [39]	18TH + TMS + TSQ + 2TCP + TS	17.046
Shao et al. [51]	13TBP + 17TE + 2TMH + 3TA	344.728
Zhou et al. [57]	13TH + 6TMS + 8TSQ	38.581
Proposed	25TH + 10TEM + 2TEA + 4TS	13.625

below. The selection of the schemes in [33,39,51,57] was informed by the fact that these schemes deploy similar symmetric and asymmetric cryptographic operations. As such, it was feasible to carry out some comparative evaluations with the proposed protocol.

As shown in Table 4, the computation complexity of the proposed protocol was 13.625 ms. On the other hand, the schemes in [33,39,51,57] had computation complexities of 38.581 ms, 17.046 ms, 344.728 ms, and 12.234 ms, respectively. It is evident from Figure 4 that the protocol developed in [51] incurred the highest computation complexities.

This was followed by the protocols in [39,57], the proposed protocol, and the scheme in [33], respectively. The extensive computation complexities in [51] were attributed to the many bilinear pairing operations that had to be executed. Although the protocol in [33] yielded the lowest computation complexities, it failed to offer session key agreement and was susceptible to privileged insider, KSSTI, MitM, and packet replay attacks.

5.2. Communication Complexity

In the process of carrying out mutual authentication and key negotiation, four messages are exchanged in the proposed protocol. These messages include M₁ = {B₃, C₂, $S_{K_1}$}, M₂ = {D₁, D₂}, M₃ = {R₅, D₃} and M₄ = {C₃, D₄, $S_{K_2},R_5$}. Here, B₃ = (A₂ℙ + B₁B₂), C₂ = $E_{C_1}$ (ID_OP||B₁||B₅||ID_UAV), D₁ = $E_{A_1}$ (ID_OP||ID_UAV||ID_RA||C₅||$S_{K_1}\left|\right|S_{K_2}$), D₂ = h(ID_OP||ID_UAV||ID_RA||C₅||$S_{K_1}\left|\right|S_{K_2}$||A₁), D₃ = h(ID_OP||ID_UAV||ID_RA||C₅||$S_{K_2}\left|\right|R_5$||A₁), C₃ = (R₄.ℙ), and D₄ = h(ID_OP||ID_RA||C₃||C₁||A₂||C₄||$S_{K_1}$||$S_{K_2}$||R₅). Using the values in [18,59],

Table 5. Cryptographic output sizes.

Cryptographic Operation	Size (bits)
Random nonce	128
Hash output	160
Identity	32
Elliptic curve point	320
Modular exponentiation	1024
Timestamp	32
Symmetric encryption/decryption	128

presents the sizes of the various cryptographic outputs.

Based on the cryptographic output sizes in Table 5 above, the derivation of the communication complexity of the proposed protocol is illustrated in

Table 6. Communication complexity derivation.

Message	Size (bits)
M1 = {B3, ${\mathrm{C}}_2,{\mathrm{S}}_{{\mathrm{K}}_1}$} B3 = 320, C2 = ${\mathrm{S}}_{{\mathrm{K}}_1}$ = 128	576
M2 = {D1, D2} D1 = 128, D2 = 160	288
M3 = {R5, D3} R5 = 128, D3 = 160	288
${\mathrm{M}}_4=\{{\mathrm{C}}_3,{\mathrm{D}}_4,{\mathrm{S}}_{{\mathrm{K}}_2},{\mathrm{R}}_5$} ${\mathrm{C}}_3=320,{\mathrm{D}}_4=160,{\mathrm{S}}_{{\mathrm{K}}_2}$ = ${\mathrm{R}}_5$ = 128	736
Total	1888

below.

As shown in Table 6 above, the total communication complexity was 1888 bits.

Table 7. Communication complexity comparisons.

Scheme	No. of Exchanged Messages	Size (bits)
Yang et al. [33]	2	1120
Tan [39]	3	2294
Shao et al. [51]	2	3648
Zhou et al. [57]	5	4128
Proposed	4	1888

below offers a comparative evaluation of the obtained communication complexity with those of other related protocols.

As shown in Table 7, the schemes in [33,39,51,57] incurred communication complexities of 4128 bits, 2294 bits, 3648 bits, and 1120 bits, respectively. It is evident from Figure 5 that the protocol in [57] incurred the highest communication complexities and required the highest number of message exchanges. This was followed by the protocol in [51], even with its two message exchanges.

The protocol in [39] had the third highest communication complexity even though it required only three message exchanges. Although the scheme in [33] had the lowest communication complexity, it could not provide session key agreement. In addition, it was prone to attacks such as privileged insider, KSSTI, MitM, and packet replays. Figure 6 shows the comparative evaluation based on the number of message exchanges.

As shown in Figure 6, the protocol in [57] required five messages to be exchanged during the authentication and key negotiation phase. This was followed by the proposed protocol, with four message exchanges. On the other hand, the scheme in [39] required three message to be exchanged, while the protocols in [33,51] needed only two messages to be exchanged. This low number of message exchanges was attributed to the lack of mutual authentication in [51] and the lack of session key agreement in [33].

5.3. Storage Complexity

In our scheme, the RA stores parameter set {ID_UAV, R₁, ID_OP, ID_SC, R₂, PID_OP} in its database during the registration phase. On the other hand, the UAV stores parameter A₁ in its memory, while the smart card stores {A₂, A₃, ℙ, PUK_RA, C_P, h(.), Gen(.), Fe(.), ID_OP, PW_OP, β, A₄, A₅, V_F, β_T} during the registration phase. Here, A₁ = h(ID_UAV||SK_RA||R₁), A₂ = h(ID_OP||SK_RA||R₂), A₃ = h(ID_SC||SK_RA), PUK_RA = ℙ.PK_RA, A₄ = A₂$\oplus$h(ID_OP||PW_OP||β_k), A₅ = A₃$\oplus$h(ID_OP$\oplus$PW_OP$\oplus$β_k), and V_F = h(h(ID_OP||PW_OP||β_k) mod C_P). Using the values in [14,35], ID_UAV = ID_OP = ID_SC = PID_OP = PW_OP = β = β_T = C_P = Gen(.) = Fe(.) = 32 bits, R₁ = R₂ = 128 bits, A₁ = A₂ = A₃ = A₄ = A₅ = h(.) = V_F =160 bits, and ℙ = PUK_RA = 320 bits. As such, the storage complexities at the RA, UAV, and smart card are 384 bits, 160 bits, and 1824 bits, respectively. Therefore, the total storage complexity in our protocol is 2368 bits.

Table 8. Storage complexity comparison.

Scheme	Size (bits)
Yang et al. [33]	2608
Tan [39]	1920
Shao et al. [51]	2080
Zhou et al. [57]	2496
Proposed	2368

presents a comparative evaluation of the obtained storage complexity in relation to those of other protocols.

As shown in Table 8, the storage complexities of the schemes in [33,39,51,57] were 2496 bits, 1920 bits, 2080 bits, and 2608 bits, respectively. It is evident from Figure 7 that the protocol in [57] incurred the highest storage complexity. This was followed by the protocol in [33], the proposed scheme, and the protocols in [39,51], in that order.

Although the protocol in [39] incurred the least storage complexities, it was vulnerable to privileged insider, impersonation, and KSSTI attacks. Similarly, the scheme in [51] incurred relatively low storage complexities but was not robust against side-channeling, impersonation, and privileged insider attacks. In addition, it failed to provide mutual authentication and unlinkability.

5.4. Supported Security Features

In this sub-section, the security features supported by our protocol as well as the resilience it provides are compared to those of other related schemes.

Table 9. Security feature comparison.

	[57]	[39]	[51]	[33]	Proposed
Security features
Mutual authentication	√	√	×	√	√
Session key agreement	-	√	√	×	√
Untraceability	-	√	-	√	√
Anonymity	√	√	√	√	√
Forward key secrecy	√	√	√	√	√
Backward key secrecy	√	√	√	√	√
Biometric privacy	-	-	-	-	√
Attack Resilience
Smart card loss	√	-	-	-	√
Password guessing	-	√	-	-	√
Privileged insider	×	×	×	×	√
KSSTI	×	×		×	√
Side-channeling	-	-	×	-	√
Impersonation	√	×	×	√	√
Denial of service	-	-	-	√	√
MitM	×	√	×	×	√

Key √: supported; ×: not supported; -: not considered.

shows the results of this comparative evaluation.

As shown in Table 9, the schemes in [33,39,51,57] supported six, eight, four, and seven security and privacy features, respectively. On the other hand, the proposed protocol supported all 15 features. As such, using the eight supported features in [39] as a basis, the proposed protocol yielded a 87.5% improvement in privacy and security provision. Although our scheme incurred slightly higher computation, communication, and storage complexities, it was the most robust against attacks and supported the highest number of salient security features.

It was shown that the proposed protocol executed 10 elliptic curve multiplications, which led to slightly high computation complexities. Similarly, the 2368 bits storage requirements and four messages exchanged during the authentication and key agreement phase were slightly higher compared to the other related schemes. However, these high complexities led to the strong security of the proposed protocol, as shown in Table 9 above. Overall, the proposed protocol offers good trade-offs between security and performance.

6. Conclusions

Unmanned aerial vehicles exhibit characteristics such as low cost and flexible operations. This has made them popular for deployment in a myriad of application domains, such as intelligent transportation systems, the detection and collection of environmental data, emergency rescue, autonomous driving, and the creation of high-definition maps in real time as well as in military applications. Clearly, large amounts of sensitive data are collected and exchanged among several ubiquitous devices to realize these services. Unfortunately, message exchanges are accomplished over public channels. This exposes exchanged data to attacks such as impersonation, session key disclosure, message replay, MitM, tracking, and eavesdropping attacks. Although many protocols have been put forward to secure the UAV communication process, a number of them still suffer from security vulnerabilities or exhibit high complexities. The developed scheme was shown to offer features such as untraceability, anonymity, key secrecy, and biometric privacy. In addition, it was demonstrated to withstand numerous attacks, such as password guessing, KSSTI, and privileged insider attacks. The comparative performance evaluation carried out showed that the scheme has relatively lower computation, storage, and communication complexities.